Zusammenfassung

  • RFC 5855 gab den Reverse-Zonen für IPv4 und IPv6 eigene Nameserver-Namensräume und ergänzte Glue-Daten in der übergeordneten Zone. Damit konnten die Zonen von getrennten Servergruppen betrieben werden.
  • Eine Trennung ist im RFC nicht vorgeschrieben. Die Betreiberwahl liegt bei einer IANA-Funktion; verschiedene Namen belegen weder unabhängige Routen noch getrennte Fehlerdomänen.

Bei einer DNS-Rückwärtssuche steht zwar eine IP-Adresse am Anfang. Bevor der Resolver den zugehörigen PTR-Eintrag abfragen kann, muss er jedoch die autoritativen Server der Reverse-Zone erreichen. Schon diese Suche nach den Servern hat eigene Abhängigkeiten. Lässt sich die Adresse eines Nameservers nicht ermitteln, endet die Anfrage, bevor der PTR-Eintrag überhaupt eine Rolle spielt.

Diesen Weg nahm RFC 5855, Nameservers for IPv4 and IPv6 Reverse Zones, in den Blick. Das im Mai 2010 als Best Current Practice veröffentlichte Dokument stammt gemeinsam von Joe Abley und Terry Manderson. Es hält den damaligen Zustand fest: Ein Teil der Root-Server bediente IN-ADDR.ARPA; IP6.ARPA wurde von Systemen versorgt, die APNIC, ARIN, ICANN, LACNIC und RIPE NCC betrieben.

Der Vorschlag schuf für jeden der beiden Reverse-Bäume einen stabilen Namensraum. IPv4-Server sollten unter IN-ADDR-SERVERS.ARPA liegen, IPv6-Server unter IP6-SERVERS.ARPA. Die übergeordnete ARPA-Zone sollte die nötigen IPv4- und IPv6-Glue-Adressen enthalten. So kann die Delegation dem Resolver gleich den nächsten Zielpunkt nennen. Eine zusätzliche rekursive Suche, um erst die Adresse eines IP6.ARPA-Servers herauszufinden, wird dadurch vermieden.

Die Anfragebeispiele im RFC zeigen, weshalb dieser Schritt zählt. Eine frühere IP6.ARPA-Referenz konnte ohne Glue im Additional-Abschnitt eintreffen. Dann musste der Resolver zunächst einen der aufgeführten Servernamen auflösen, bevor er die Reverse-Zone abfragen konnte. RFC 5855 verankert diese Abhängigkeit in der Delegation selbst: Eigene Namen und Adressen in der ARPA-Elternzone machen den Pfad deutlicher und leichter überprüfbar. Die Änderung wirkt klein, liegt aber vor jeder Rückwärtssuche.

Auch den Platzbedarf der kodierten NS-Namen vergleicht das Dokument. Im historischen IPv6-Beispiel belegen sie 74 Byte, im vorgeschlagenen Satz unter IP6-SERVERS.ARPA 39 Byte. Das ist ein Vergleich der DNS-Kodierung, keine Messung von Laufzeit oder Ausfällen. Er veranschaulicht, wie sich gemeinsame Namenssuffixe in einer häufig übertragenen Delegation komprimieren lassen und wie der nächste Weg zu den Serveradressen klarer wird.

Die getrennten Namensräume sollten auch eine weitergehende Trennung des Betriebs ermöglichen. Laut RFC können die Reverse-Zonen für IPv4 und IPv6 an unterschiedliche Nameservergruppen delegiert werden, damit ein Fehler in einer Familie die Abfragen der anderen weniger leicht beeinträchtigt. Vorgeschrieben wird das nicht. Der RFC verlangt weder unterschiedliche Unternehmen noch Standorte, Transitprovider oder Routen. Innerhalb einer Familie können der Namensraum der Server und die zugehörige Reverse-Zone zudem dasselbe Schicksal teilen.

Die Namensgrenze schafft eine Möglichkeit, liefert aber keinen Nachweis für physische oder netztechnische Unabhängigkeit.

Wer die verbleibende Entscheidung trifft, benennt das Dokument ausdrücklich. Der IANA-Abschnitt führt die Delegationen und Glue-Einträge auf, erklärt die Betreiberwahl aber für außerhalb des RFC-Umfangs und ordnet sie einer IANA-Funktion nach dem Memorandum of Understanding zwischen IETF und ICANN zu. RFC 5855 beschreibt damit eine technische Schnittstelle und die anschließende Übergabe der Verantwortung. Er bestätigt weder die heutige Zuständigkeit für einzelne Server noch die Unabhängigkeit der Servergruppen.

Mandersons Laufbahn ist auf beiden Seiten dieser Grenze dokumentiert. Er ist Mitautor des RFC; der IETF Datatracker führt ihn unter seinen RFCs. Eine spätere RSSAC-Chronik vermerkt, dass er 2013 die Leitung der DNS Operations Department von ICANN übernahm. 2014 wechselte das Team zu ICANN IT und erhielt den Namen DNS Engineering. Ein ICANN-Interview bezeichnet ihn zu dieser Zeit als Direktor. Diese Quellen belegen Betriebserfahrung. Sie belegen nicht, dass Manderson allein die im RFC genannten Betreiber entworfen, ausgewählt oder eingesetzt hätte.

Gerade diese Grenze macht den RFC als Beleg nützlich. Er trennt, was ein Protokoll benennen kann, von dem, was eine Betreibervereinbarung entscheiden muss. Ob IPv4- und IPv6-Reverse-DNS tatsächlich unabhängig ausfallen, lässt sich erst anhand der laufenden NS-Sätze, Glue-Daten, Hosting-Standorte, Routen und Antworten beurteilen. Zwei verschiedene Suffixe in einem Standard beantworten diese Frage nicht.

Quellen