Zusammenfassung

  • RFC 2672 führte DNAME 1999 ein: Bei Nachfahren wird das Eigentümer-Suffix durch ein Ziel-Suffix ersetzt. Eine Regel kann damit eine noch offene Menge einzelner Aliasse abbilden.
  • DNAME leitet den Eigentümernamen selbst nicht um und delegiert keine Zone. Am Apex bleiben SOA und NS nötig; Delegation entsteht weiterhin durch ein NS-RRset der Elternzone am Zonenschnitt.
  • RFC 6672 zog Grenzen aus der Betriebserfahrung: synthetische CNAMEs, DNSSEC-Prüfung über den signierten DNAME, verdeckte Nachfahrendaten, kein Wildcard-DNAME, begrenzte Schleifen und YXDOMAIN bei einem zu langen Ergebnis.

Zwischen Einzelalias und Zonendelegation

Der DNS-Entwurf in RFC 1034 kannte zwei unterschiedliche Formen der Weiterleitung. CNAME bezeichnete einen bestimmten Namen als Alias eines kanonischen Namens. Ein NS-RRset an einem Zonenschnitt verwies den Resolver an die autoritativen Server einer Kindzone.

Das eine regelte die Identität eines Knotens, das andere die Verwaltungsgrenze. Was fehlte, war eine Operation, die bei beliebigen Nachfahren die linken Labels bewahrt und nur ein gemeinsames rechtes Suffix austauscht.

Bei einem Wechsel von alt.example zu neu.example half ein CNAME für www weder mail noch labor.mail oder künftigen Namen. Eine neue Delegation hätte dagegen die Antwortzuständigkeit verändert, obwohl vielleicht nur alte Namenspfade erhalten werden sollten.

DNAME füllte diese Lücke: größer als ein punktueller Alias, aber in seiner Bedeutung deutlich kleiner als die Übergabe einer Zone.

Eine Suffixregel statt einer Namensliste

RFC 2672 definierte im August 1999 den Typ 39. Endet ein nachgefragter Nachfahrenname auf den DNAME-Eigentümer, ersetzt die Auflösung dieses Suffix durch das Ziel. Verglichen werden vollständige DNS-Labels.

Ein DNAME von alt.example nach neu.example macht aus www.labor.alt.example den Namen www.labor.neu.example. www.labor bleibt erhalten. Die Quellzone kopiert keine Zieldaten und gewinnt auch keine Kontrolle über sie.

Die ursprüngliche Spezifikation nannte Netzrenummerierung, Reverse DNS und organisatorische Umbenennung als Motive. Das sind Entwurfsfälle, keine Nutzungsstatistik. Der gemeinsame Zweck war administrative Verdichtung: Ein Eintrag sollte bekannte, unbekannte und erst künftig entstehende Nachfahren erfassen.

Verdichtung konzentriert zugleich Risiko. Ein Fehler in einer Zeile kann die Suchrichtung eines ganzen Teilbaums ändern. Weniger Konfiguration bedeutet nicht weniger Wirkung.

Der Eigentümer blieb an seinem Ort

Die heutige Spezifikation RFC 6672 macht die wichtigste Ausnahme unmissverständlich: DNAME gilt für Namen unterhalb seines Eigentümers, nicht für den Eigentümer selbst.

www.alt.example kann also zum neuen Suffix gelangen, während alt.example am alten Apex beantwortet wird. Dort dürfen kompatible Datentypen liegen. Ist der Eigentümer der Zonen-Apex, bleiben SOA und NS vorgeschrieben.

DNAME kann daher keine vollständige Zone spiegeln. Bei einer Umbenennung muss ein MX am alten Apex möglicherweise wiederholt werden. Webdienst, Zertifikat und Mailpolitik müssen den alten Namen anerkennen. DNS kann zu einem Ziel führen, aber keine Anwendung zu einer Identitätsentscheidung zwingen.

Die Ausnahme beschreibt das ehrliche Versprechen: strukturelle Korrespondenz der Nachfahren, nicht vollständige Gleichheit zweier Domains.

Der konkrete CNAME entstand erst bei der Frage

Wendet ein Server die Substitution an, liefert er den DNAME und erzeugt für den exakten QNAME einen CNAME. Für www.labor.alt.example kann die Antwort einen CNAME zu www.labor.neu.example enthalten, obwohl er nie als einzelne Zeile in der Zone stand.

DNAME ist die veröffentlichte allgemeine Regel. Der synthetisierte CNAME ist ihr Transaktionsergebnis. So können Clients folgen, die CNAME kennen, DNAME aber nicht vollständig verarbeiten. Auch rekursive Cache-Server müssen diese Synthese übernehmen können.

Die TTL-Regel änderte sich durch Betriebserfahrung. Die erste Fassung setzte den synthetischen CNAME auf null. RFC 6672 verwendet die DNAME-TTL, verlangt aber, dass Resolver beide Werte akzeptieren, weil alte Implementierungen weiterliefen.

Ein früher gedachtes EDNS-Signal für DNAME-Verständnis wurde nie spezifiziert. Interoperabilität entstand aus normalen Antworten und kompatiblem Verhalten, nicht aus einer nicht vorhandenen Aushandlung.

DNSSEC signierte die Ursache

Eine Zone kann nicht jeden denkbaren CNAME für künftige Nachfragen vorab signieren. DNSSEC signiert deshalb den DNAME. Der Validator prüft die Signatur, führt die Suffixersetzung selbst aus und kontrolliert den unsignierten CNAME als deterministische Ableitung.

Der Beweis besteht aus authentifizierter Regel und reproduzierbarer Berechnung. Der Server darf nicht beliebig synthetisieren: linke Labels bleiben erhalten, das Suffix muss an Labelgrenzen passen, und das Ziel stammt aus dem signierten Eintrag.

Eine gültige erste Umleitung beglaubigt dennoch nicht die gesamte Kette. Es können CNAME, weitere DNAME, eine unsignierte Zielzone oder ein Fehler folgen. RFC 6604 stellt klar, dass RCODE und Statusbits das Endergebnis der Umleitungskette beschreiben.

Ein authentischer Zeiger beweist, wer ihn gesetzt hat. Er beweist weder die institutionelle Identität noch die Sicherheit oder Verfügbarkeit des Zielservices.

Zeigen war nicht delegieren

RFC 9499 nennt einen Subdomain-Namen unter einem DNAME-Eigentümer einen Alias. Delegation ist dagegen die Erzeugung einer eigenen Zone durch ein NS-RRset der Elternzone am Ursprung des Kindes und damit am Zonenschnitt.

Eine NS-Referral ändert, welchen Servern der Resolver Autorität für den ursprünglichen Namen zuschreibt. DNAME ändert den Namen, den er weiterverfolgt. Der neue Name durchläuft danach die bereits bestehende Delegationshierarchie des Ziels.

Außerhalb eines Apex dürfen DNAME und ein delegierendes NS-RRset nicht denselben Eigentümer haben. Nutzt die Kindzone DNAME an ihrem Apex, liegt der Eintrag unter dem Schnitt in ihren autoritativen Daten, gemeinsam mit SOA und NS.

Der Quellbetreiber kontrolliert den Verweis. Eltern- und Kindbetreiber kontrollieren die Quelldelegation. Der Zielbetreiber kontrolliert die letztlich erreichten Daten. Eine nahtlose Antwort verschmilzt diese Befugnisse nicht.

Die Regel verdeckte untergeordnete Daten

In derselben Zone dürfen unterhalb eines DNAME-Eigentümers keine Resource Records liegen. Lädt ein Server sie dennoch, werden sie verdeckt: Die Suche trifft zuerst auf die Umleitung und verlässt den Quellteilbaum.

Das Hinzufügen einer Zeile kann somit viele Namen öffentlich unsichtbar machen, ohne ihre Zeilen zu löschen. Während einer Änderung können Caches alte Nachfahrendaten und einen neuen DNAME zugleich besitzen. RFC 6672 lässt Übergangsstrategien zu und verlässt sich auf den Ablauf alter TTLs.

Vor der Einführung ist deshalb der gesamte Teilbaum zu inventarisieren. Auch der Rückweg folgt verteilter Zeit: Das Löschen am autoritativen Server widerruft noch gültige Cachekopien nicht sofort.

Pro Eigentümer gibt es nur einen DNAME; CNAME darf dort nicht gleichzeitig stehen. Große Reichweite bedeutet nicht, dass konkurrierende Zielregeln am selben Punkt erlaubt wären.

Wildcards hätten die Regel selbst erzeugt

Ein normaler DNAME ist eine feste autoritative Regel, aus der konkrete CNAMEs entstehen. Bei einem Wildcard-DNAME würde die Wildcard zuerst den Eigentümer der Regel synthetisieren; diese temporäre Regel würde danach die Umleitung erzeugen.

RFC 4592 sah darin Nichtdeterminismus und eine Gefahr für die Cache-Kohärenz. RFC 6672 rät davon ab und erlaubt Warnung, Update-Ablehnung oder Zurückweisung der Zone.

Die Grenze schützt Nachvollziehbarkeit. Ein Ergebnis aus einem festen autoritativen Fakt ist prüfbar. Wird auch der Fakt erzeugt, der die Umleitungsbefugnis verleiht, verschwimmen Ursprung und Geltungsbereich.

Das DNS muss beliebig viele Fragen annehmen können. Es muss deshalb nicht beliebig viele Kontrollregeln während der Antwort erfinden.

Schleifen und Länge begrenzten die Abstraktion

DNAMEs können untereinander oder mit CNAMEs Schleifen bilden. Eine Substitution kann einen Namen erneut in den Bereich derselben Regel führen. Resolver und Server müssen Ressourcen begrenzen, obwohl manche längeren Ketten gültig sind.

Erzeugt die Suffixersetzung einen Namen über dem DNS-Limit, antwortet der autoritative Server mit YXDOMAIN und legt DNAME sowie gegebenenfalls dessen Signatur bei. Das ist nicht NXDOMAIN: Nicht der Ausgangsname fehlt, sondern das berechnete Ergebnis ist nicht darstellbar.

Zielnamen in NS, MX, PTR und SRV müssen außerdem kanonische Hostnamen sein. Ihre Adressauflösung darf nicht von CNAME- oder DNAME-Ketten abhängen. Die Infrastruktur, die Autorität und Dienste auffindbar macht, soll nicht selbst hinter der Abkürzung verschwinden.

Der Quelladministrator vermeidet Kreise und Überlänge, der Server meldet präzise Fehler, der Resolver verweigert unbegrenzte Arbeit. Konfigurationsersparnis ist keine Erlaubnis, unbeschränkte Kosten zu verteilen.

Technische Erreichbarkeit ist kein Eigentumsnachweis

DNAME kann alte Nachfahren während einer Übergangsphase erreichbar halten. Es erhält Syntax und Suchpfad, nicht automatisch Eigentum, Verträge, Schlüssel, Zertifikate, Verfügbarkeit oder Anwendungsakzeptanz.

Eine belastbare Migration hält deshalb getrennt fest, wer die Quellregel ändern kann, wer die Zieldaten betreibt und wer im Dienst alte und neue Identitäten akzeptiert. Je reibungsloser DNS antwortet, desto weniger darf institutionelle Kontinuität bloß angenommen werden.

DNAME konnte eine Suche durch den Namensbaum bewegen. Es konnte die Autorität hinter diesem Baum nicht mitnehmen. Genau diese Unfähigkeit machte eine teilbaumweite Umleitung prüfbar.

Quellen und Evidenzgrenzen

Die ursprüngliche CNAME-, Zonen- und Delegationsarchitektur steht in RFC 1034: https://www.rfc-editor.org/rfc/rfc1034.html

Die erste DNAME-Spezifikation steht in RFC 2672: https://www.rfc-editor.org/rfc/rfc2672.html

Das Wildcard-DNAME-Problem steht in RFC 4592: https://www.rfc-editor.org/rfc/rfc4592.html

Der Endstatus von Umleitungsketten wird in RFC 6604 geklärt: https://www.rfc-editor.org/rfc/rfc6604.html

Die heutigen Regeln für Substitution, Synthese, DNSSEC und Fehler stehen in RFC 6672: https://www.rfc-editor.org/rfc/rfc6672.html

Die aktuellen Alias- und Delegationsbegriffe stehen in RFC 9499: https://www.rfc-editor.org/rfc/rfc9499.html

Die Quellen liefern keine aktuelle weltweite Einsatzquote und keinen universellen Nutzenwert. Renummerierung und Umbenennung sind Entwurfsbeispiele. Erfolgreiche DNAME-Auflösung beweist weder gemeinsamen Eigentümer noch Anwendungsakzeptanz, Zertifikatsgültigkeit oder Autoritätsübergang.