Namensschema für Herpf-Gateways geändert + bump serial #22

Merged
Blackyfff merged 1 commits from :master into master 2020-12-07 21:07:30 +01:00
Owner

Ich glaube wir sollten uns mal auf ein Schema festlegen die Gateways zu benennen.
Das alte Schema war ja fff-gw-[..]
Darin ist dann fff doppelt in der Domain, das könnte man einsparen.
Auch das neuere Schema mit [..].gw.fff.community ist nicht so toll, weil es sich nicht dezentralisieren lässt.

Ich würde gwXX.<Hood>.fff.community vorschlagen.

Hoods die keinen eigenen DNS haben können es hier eintragen, die mit eigenem DNS können es dann delegieren.

Ich glaube wir sollten uns mal auf ein Schema festlegen die Gateways zu benennen. Das alte Schema war ja fff-gw-[..] Darin ist dann fff doppelt in der Domain, das könnte man einsparen. Auch das neuere Schema mit [..].gw.fff.community ist nicht so toll, weil es sich nicht dezentralisieren lässt. Ich würde gwXX.\<Hood>.fff.community vorschlagen. Hoods die keinen eigenen DNS haben können es hier eintragen, die mit eigenem DNS können es dann delegieren.
Owner

Das "neue" Schema ist eigentlich gar nicht neu, das war schon immer da. Es wurde nur nicht von allen verwendet.
Das fff-gw-[..]-Schema ist allein schon wegen der unnötigen Redundanz quatsch, wenn man mich fragt.

Das mit der besseren Möglichkeit zur Delegation (dezentral ist es ja leider nicht so richtig..) funktioniert halt kaum, da es zwischen Gatewayname-Level und fff.community-Level kaum noch Faktoren gibt, nach denen delegiert werden könnte.
Die Hood könnte man nehmen, so einen richtigen Vorteil sehe ich davon aber nicht.

Wo ich dieses Schema hingegen sehr viel verwende sind dezentrale Hoods, da ich dort häufig auch jede Menge Geräte drin habe. Beispielsweise für *.wuni.fff.community habe ich das so gemacht, wenn auch nicht ganz konesequent.

Das "neue" Schema ist eigentlich gar nicht neu, das war schon immer da. Es wurde nur nicht von allen verwendet. Das fff-gw-[..]-Schema ist allein schon wegen der unnötigen Redundanz quatsch, wenn man mich fragt. Das mit der besseren Möglichkeit zur Delegation (dezentral ist es ja leider nicht so richtig..) funktioniert halt kaum, da es zwischen Gatewayname-Level und fff.community-Level kaum noch Faktoren gibt, nach denen delegiert werden könnte. Die Hood könnte man nehmen, so einen richtigen Vorteil sehe ich davon aber nicht. Wo ich dieses Schema hingegen sehr viel verwende sind dezentrale Hoods, da ich dort häufig auch jede Menge Geräte drin habe. Beispielsweise für \*.wuni.fff.community habe ich das so gemacht, wenn auch nicht ganz konesequent.
Owner

Ich habe mich möglicherweise etwas unglücklich ausgedrückt: Das <hood>.fff.community Schema finde ich gut, das erzeugt aber für zentrale Hoods jede Menge Redundanz, weil diese Router/Gateways ja für gewöhnlich in mehreren Hoods hängen.

Ich habe mich möglicherweise etwas unglücklich ausgedrückt: Das \<hood\>.fff.community Schema finde ich gut, das erzeugt aber für zentrale Hoods jede Menge Redundanz, weil diese Router/Gateways ja für gewöhnlich in mehreren Hoods hängen.
Blackyfff merged commit 56b1101097 into master 2020-12-07 21:07:30 +01:00
Author
Owner

Als redundant würde ich es nicht bezeichnen, immerhin ist es ja pro Hood die Information welches das erste und evtl. zweite oder dritte gateway ist, außerdem würde ich dann meinem Verständnis nach dort die IPs eintragen, welche die Gateways in diesem Netz haben (dann funktioniert auch Reverse-lookup über den auto-generated PTR).
Dann kann man die 'externe' IP immernoch auf einen separaten <Name>.gw.fff.community Eintrag legen, oder nach belieben mit an die 'Haupt'-Hood hängen.

Als redundant würde ich es nicht bezeichnen, immerhin ist es ja pro Hood die Information welches das erste und evtl. zweite oder dritte gateway ist, außerdem würde ich dann meinem Verständnis nach dort die IPs eintragen, welche die Gateways in diesem Netz haben (dann funktioniert auch Reverse-lookup über den auto-generated PTR). Dann kann man die 'externe' IP immernoch auf einen separaten \<Name>.gw.fff.community Eintrag legen, oder nach belieben mit an die 'Haupt'-Hood hängen.
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: freifunk-franken/dns#22
No description provided.