Warum kann ein CNAME-Eintrag nicht am Apex (alias Root) einer Domain verwendet werden?

Dies ist eine kanonische Frage zu CNAMEs an den Spitzen (oder Wurzeln) von Zonen

Es ist relativ allgemein bekannt, dass CNAMEAufzeichnungen am Scheitelpunkt einer Domain tabu sind.

Beispiel: example.com. IN CNAME ithurts.example.net.

Im besten Fall verweigert die Nameserver-Software möglicherweise das Laden der Konfiguration, und im schlimmsten Fall akzeptiert sie diese Konfiguration und macht die Konfiguration für example.com ungültig.

Kürzlich ließ ich von einem Webhosting-Unternehmen Anweisungen an eine Geschäftseinheit weitergeben, die wir brauchten, um den Scheitelpunkt unserer Domain mit einem neuen Datensatz zu versehen. Da ich wusste, dass dies eine Selbstmord-Konfiguration sein würde, wenn sie an BIND weitergeleitet wurde, riet ich ihnen, dass wir nicht in der Lage sein würden, dies zu befolgen, und dass dies im Allgemeinen ein Ratschlag für Kojen war. Das Webhosting-Unternehmen vertrat die Ansicht, dass es durch standardmäßige Definition von RFCs nicht völlig verboten ist und dass ihre Software dies unterstützt. Wenn wir den Apex nicht CNAMEN könnten, war ihr Rat, überhaupt keinen Apex-Datensatz zu haben, und sie würden keinen umleitenden Webserver bereitstellen. ...Was?

Die meisten von uns wissen, dass RFC1912 darauf besteht A CNAME record is not allowed to coexist with any other data., aber seien wir ehrlich, dass RFC nur informativ ist. Das Wort, das meiner Kenntnis nach der Praxis am nächsten kommt und das diese Praxis verbietet, stammt aus RFC1034 :

Wenn ein CNAME RR an einem Knoten vorhanden ist, sollten keine anderen Daten vorhanden sein. Dadurch wird sichergestellt, dass die Daten für einen kanonischen Namen und seine Aliase nicht unterschiedlich sein können.

Leider war ich lange genug in der Branche, um zu wissen, dass "sollte nicht" nicht dasselbe ist wie "darf nicht", und das ist genug Seil, mit dem sich die meisten Software-Designer abhängen können. Da ich wusste, dass eine kurze Verknüpfung mit einem Slam Dunk eine Verschwendung meiner Zeit wäre, ließ ich das Unternehmen schimpfen, um Konfigurationen zu empfehlen, die häufig verwendete Software ohne ordnungsgemäße Offenlegung beschädigen könnten.

Dies bringt uns zu den Fragen und Antworten. Diesmal möchte ich, dass wir uns wirklich technisch mit dem Wahnsinn von Apex-CNAMEs auseinandersetzen und das Problem nicht so umgehen, wie wir es normalerweise tun, wenn jemand Beiträge zu diesem Thema verfasst. RFC1912 ist tabu , ebenso wie alle anderen hier anwendbaren Informations-RFCs, an die ich nicht gedacht habe. Lassen Sie uns dieses Baby herunterfahren.

CNAMEUrsprünglich wurden Datensätze erstellt, um zu ermöglichen, dass mehrere Namen, die dieselbe Ressource bereitstellen, zu einem einzigen "kanonischen Namen" für die Ressource zusammengefasst werden. Mit dem Aufkommen des namensbasierten virtuellen Hostings ist es mittlerweile üblich geworden, diese als generische Form des IP-Adress-Aliasing zu verwenden. Leider erwarten die meisten Leute, die aus einem Webhosting-Umfeld stammen, dass CNAMEAufzeichnungen eine Äquivalenz im DNS anzeigen , was nie beabsichtigt war. Der Apex enthält Datensatztypen, die eindeutig nicht für die Identifizierung einer kanonischen Host-Ressource ( NS, SOA) verwendet werden. Sie können nicht mit Alias ​​versehen werden, ohne den Standard auf einer fundamentalen Ebene zu brechen. (insbesondere in Bezug auf Zonenschnitte )

Unglücklicherweise wurde der ursprüngliche DNS-Standard geschrieben, bevor die Normungsgremien erkannten, dass eine explizite Aussprache erforderlich ist, um ein konsistentes Verhalten zu definieren ( RFC 2119 ). Es war notwendig, RFC 2181 zu erstellen , um mehrere Eckfälle aufgrund einer vagen Formulierung zu klären, und die aktualisierte Formulierung verdeutlicht, dass ein CNAME nicht verwendet werden kann, um ein Apex-Aliasing zu erreichen, ohne den Standard zu brechen.

6.1. Zonenautorität

Die autorisierenden Server für eine Zone sind in den NS-Datensätzen für den Ursprung der Zone aufgelistet, die zusammen mit einem SOA-Datensatz (Start of Authority) die obligatorischen Datensätze in jeder Zone sind. Ein solcher Server ist für alle Ressourceneinträge in einer Zone maßgeblich, die sich nicht in einer anderen Zone befinden. Die NS-Datensätze, die einen Zonenausschnitt angeben, sind das Eigentum der erstellten untergeordneten Zone, ebenso wie alle anderen Datensätze für den Ursprung dieser untergeordneten Zone oder alle Unterdomänen davon. Ein Server für eine Zone sollte keine autorisierenden Antworten für Abfragen zurückgeben, die sich auf Namen in einer anderen Zone beziehen, einschließlich der NS- und möglicherweise A-Einträge bei einem Zonenausschnitt, es sei denn, es handelt sich zufällig auch um einen Server für die andere Zone.

Dies legt fest, dass SOAund NSAufzeichnungen obligatorisch sind, aber es sagt nichts über Aoder andere Arten, die hier erscheinen. Es mag überflüssig erscheinen, dass ich das dann zitiere, aber es wird in einem Moment relevanter.

RFC 1034 war etwas vage über die Probleme, die auftreten können, wenn a CNAMEneben anderen Datensatztypen vorhanden ist. RFC 2181 beseitigt die Mehrdeutigkeit und gibt explizit die Datensatztypen an, die neben ihnen existieren dürfen:

10.1. CNAME-Ressourceneinträge

Der DNS-CNAME-Eintrag ("Kanonischer Name") enthält den kanonischen Namen, der einem Aliasnamen zugeordnet ist. Es kann nur einen solchen kanonischen Namen für einen Alias ​​geben. Dieser Name sollte im Allgemeinen ein Name sein, der an anderer Stelle im DNS vorhanden ist, obwohl es einige seltene Anwendungen für Aliase gibt, bei denen der zugehörige kanonische Name im DNS nicht definiert ist. Ein Aliasname (Bezeichnung eines CNAME-Datensatzes) kann, wenn DNSSEC verwendet wird, über SIG-, NXT- und KEY-RRs verfügen, enthält jedoch möglicherweise keine anderen Daten. Dies bedeutet, dass für jedes Label im DNS (jeder Domainname) genau eines der folgenden Merkmale zutrifft:

• Ein CNAME-Datensatz ist vorhanden, optional zusammen mit SIG-, NXT- und KEY-RRs.
• ein oder mehrere Datensätze existieren, wobei keiner CNAME-Datensätze sind,
• Der Name existiert, hat aber keine zugehörigen RRs jeglichen Typs.
• Der Name existiert überhaupt nicht.

"Aliasname" bezieht sich in diesem Zusammenhang auf die linke Seite des CNAMEDatensatzes. Die Liste mit Aufzählungszeichen macht explizit deutlich, dass die Datensätze a SOA, NSund Aan einem Knoten, an dem CNAMEauch ein angezeigt wird, nicht sichtbar sind . Wenn wir dies mit Abschnitt 6.1 kombinieren, ist es unmöglich, dass a CNAMEam Scheitelpunkt existiert, da es neben obligatorischen SOAund NSAufzeichnungen leben müsste .

(Dies scheint die Aufgabe zu erfüllen, aber wenn jemand einen kürzeren Weg zum Beweis hat, versuchen Sie es bitte.)

Aktualisieren:

Es scheint, dass die jüngste Verwirrung von Cloudflares jüngster Entscheidung herrührt, die Definition eines illegalen CNAME-Datensatzes am Scheitelpunkt von Domänen zuzulassen, für die sie A-Datensätze synthetisieren werden. "RFC-konform", wie im verlinkten Artikel beschrieben, bezieht sich auf die Tatsache, dass die von Cloudflare synthetisierten Datensätze gut mit DNS kompatibel sind. Dies ändert nichts an der Tatsache, dass es sich um ein vollständig benutzerdefiniertes Verhalten handelt.

Meiner Meinung nach ist dies ein Nachteil für die größere DNS-Community: Es handelt sich nicht um einen CNAME-Eintrag, und es führt die Leute in die Irre, zu glauben, dass andere Software nicht in der Lage ist, dies zuzulassen. (wie meine frage zeigt)

Das Internet Systems Consortium hat kürzlich einen Bericht über CNAME am Scheitelpunkt einer Zone veröffentlicht , in dem dargelegt wird , warum diese Einschränkung besteht, sowie eine Reihe von Alternativen. Es ist unwahrscheinlich, dass sich dies bald ändern wird.

Wir können die Verwendung des speziellen CNAME-Eintrags nicht ändern, ohne alle DNS-Serverimplementierungen der Welt gleichzeitig zu ändern. Dies liegt daran, dass seine Bedeutung und Interpretation im DNS-Protokoll streng definiert wurde. Alle aktuellen DNS-Client- und Serverimplementierungen halten sich an diese Spezifikation. Wenn Sie versuchen, die Verwendung von CNAME auf autorisierenden Servern zu "lockern", ohne gleichzeitig alle derzeit in Betrieb befindlichen DNS-Resolver zu ändern, wird die Namensauflösung unterbrochen (und Web- und E-Mail-Dienste sind für Organisationen, die "entspannte" autorisierende Serverlösungen implementieren, zeitweise nicht verfügbar.

Aber es gibt Hoffnung:

Eine andere mögliche Lösung, die derzeit diskutiert wird, würde einen neuen DNS-Ressourceneintragstyp hinzufügen, nach dem Browser suchen würden, der an der Spitze existieren könnte. Dies wäre ein anwendungsspezifischer Hostname für http-Anforderungen (ähnlich wie bei MX).

Vorteile: Dies stimmt vollständig mit dem DNS-Design überein.
Nachteile: Dies ist noch nicht verfügbar und erfordert ein Browser-Client-Update.

Wenn Sie eine gesamte Zone umleiten, sollten Sie DNAME verwenden. Laut RFC 6672 ,

Der DNAME RR und der CNAME RR [RFC1034] bewirken, dass bei einer Suche (möglicherweise) Daten zurückgegeben werden, die einem vom abgefragten Domänennamen abweichenden Domänennamen entsprechen. Der Unterschied zwischen den beiden Ressourceneinträgen besteht darin, dass der CNAME RR die Suche nach Daten bei seinem Besitzer zu einem anderen einzelnen Namen leitet, während ein DNAME RR die Suche nach Daten bei Nachkommen des Namens seines Besitzers zu entsprechenden Namen unter einem anderen (einzelnen) Knoten von leitet der Baum.

Durchsuchen Sie beispielsweise eine Zone (siehe RFC 1034 [RFC1034], Abschnitt 4.3.2, Schritt 3) nach dem Domänennamen "foo.example.com", und ein DNAME-Ressourceneintrag wird unter "example.com" angezeigt dass alle Anfragen unter "example.com" an "example.net" gerichtet werden. Der Suchvorgang kehrt mit dem neuen Abfragenamen "foo.example.net" zu Schritt 1 zurück. Wäre der Abfragename "www.foo.example.com", würde der neue Abfragename "www.foo.example.net" lauten.