it-swarm.com.de

Warum kann ein CNAME-Datensatz nicht am Scheitelpunkt (auch als Root bezeichnet) einer Domain verwendet werden?

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

Es ist relativ allgemein bekannt, dass CNAME Datensätze an der Spitze einer Domain eine Tabupraxis sind.

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

Im besten Fall weigert sich die Nameserver-Software möglicherweise, die Konfiguration zu laden, und im schlimmsten Fall akzeptiert sie diese Konfiguration und macht die Konfiguration für example.com ungültig.

Kürzlich ließ ich eine Webhosting-Firma Anweisungen an eine Geschäftseinheit weitergeben, die wir brauchten, um den Scheitelpunkt unserer Domain auf einen neuen Datensatz zu CNAME. Da ich wusste, dass dies eine Selbstmordkonfiguration sein würde, wenn ich an BIND verfüttert würde, riet ich ihnen, dass wir nicht in der Lage sein würden, dies zu tun, und dass dies im Allgemeinen ein Ratschlag für eine Koje war. Das Webhosting-Unternehmen vertrat die Auffassung, dass es durch standarddefinierte RFCs nicht völlig verboten ist und dass ihre Software dies unterstützt. Wenn wir den Apex nicht CNAME könnten, wäre 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, dass A CNAME record is not allowed to coexist with any other data., aber seien wir ehrlich zu uns selbst, dass RFC nur informativ ist. Das Wort, das der Praxis am nächsten kommt, ist RFC1034 :

Wenn an einem Knoten ein CNAME RR 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 bin 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 Softwareentwickler aufhängen können. Da ich wusste, dass alles andere als eine präzise Verknüpfung mit einem Slam Dunk eine Zeitverschwendung 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. Ausnahmsweise möchte ich, dass wir wirklich technisch über den Wahnsinn von Apex-CNAMEs informiert werden und das Problem nicht umgehen, wie wir es normalerweise tun, wenn jemand Beiträge veröffentlicht das Thema. RFC1912 ist verboten, ebenso wie alle anderen hier anwendbaren Informations-RFC, an die ich nicht gedacht habe. Lassen Sie uns dieses Baby abschalten.

129
Andrew B

CNAME Datensätze wurden rsprünglich erstellt, um zu ermöglichen, dass mehrere Namen, die dieselbe Ressource bereitstellen, auf einen einzelnen "kanonischen Namen" für die Ressource ausgerichtet werden. Mit dem Aufkommen des namenbasierten virtuellen Hostings ist es stattdessen üblich geworden, sie als generische Form des IP-Adress-Aliasing zu verwenden. Leider erwarten die meisten Leute, die aus einem Webhosting-Hintergrund stammen, dass CNAME Datensätze Äquivalenz im DNS anzeigen, was nie beabsichtigt war. Der Apex enthält Datensatztypen, die eindeutig nicht zur Identifizierung einer kanonischen Host-Ressource (NS, SOA) verwendet werden und die nicht ohne Unterbrechung der Standard auf einer fundamentalen Ebene. (insbesondere in Bezug auf Zonenschnitte )

Leider wurde der ursprüngliche DNS-Standard geschrieben, bevor die Normungsgremien erkannten, dass eine explizite Aussprache erforderlich war, um ein konsistentes Verhalten zu definieren ( RFC 2119 ). Es war notwendig, RFC 2181 zu erstellen, um mehrere Eckfälle aufgrund vager Formulierungen zu klären, und die aktualisierte Sprache macht klarer, dass ein CNAME nicht sein kann wird verwendet, um ein Apex-Aliasing zu erreichen, ohne den Standard zu brechen.

6.1. Zonenbehörde

Die autorisierenden Server für eine Zone werden in den Datensätzen NS für den Ursprung der Zone) aufgelistet, die zusammen mit einem SOA-Datensatz (Start of Authority) vorhanden sind die obligatorischen Datensätze in jeder Zone. Ein solcher Server ist für alle Ressourcendatensätze in einer Zone autorisierend, die sich nicht in einer anderen Zone befinden. Die NS Datensätze, die a angeben Zonenausschnitte sind die Eigenschaft der erstellten untergeordneten Zone, ebenso wie alle anderen Datensätze für den Ursprung dieser untergeordneten Zone oder Unterdomänen davon. Ein Server für eine Zone sollte keine autorisierenden Antworten auf Abfragen zurückgeben, die sich auf Namen in einer anderen Zone beziehen Dies schließt die NS- und möglicherweise A-Aufzeichnungen bei einem Zonenschnitt ein, es sei denn, es handelt sich zufällig auch um einen Server für die andere Zone.

Dies stellt fest, dass SOA und NS Datensätze obligatorisch sind, sagt jedoch nichts über A oder andere hier erscheinende Typen aus. Es mag überflüssig erscheinen, dass ich dies dann zitiere, aber es wird in einem Moment relevanter.

RFC 1034 war etwas vage über die Probleme, die auftreten können, wenn ein CNAME neben anderen Datensatztypen existiert. RFC 2181 entfernt 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, deren zugehöriger kanonischer Name im DNS nicht definiert ist. Ein Aliasname (Bezeichnung eines CNAME-Eintrags) kann, wenn DNSSEC verwendet wird, SIG-, NXT- und KEY-RRs haben, aber möglicherweise keine anderen Daten. Das heißt, für jedes Label im DNS (einen beliebigen Domainnamen) gilt genau eines der folgenden:

  • es existiert ein CNAME-Datensatz, optional begleitet von SIG-, NXT- und KEY-RRs.
  • es gibt einen oder mehrere Datensätze, von denen keiner CNAME-Datensätze sind.
  • der Name existiert, hat aber keine zugeordneten RRs.
  • der Name existiert überhaupt nicht.

"Aliasname" bezieht sich in diesem Zusammenhang auf die linke Seite des Datensatzes CNAME. Die Liste mit Aufzählungszeichen macht ausdrücklich deutlich, dass die Datensätze SOA, NS und A an einem Knoten nicht angezeigt werden können, an dem auch ein CNAME angezeigt wird. Wenn wir dies mit Abschnitt 6.1 kombinieren, ist es unmöglich, dass ein CNAME an der Spitze existiert, da es neben den obligatorischen SOA und NS Datensätzen leben müsste.

(Dies scheint die Arbeit zu erledigen, aber wenn jemand einen kürzeren Weg zum Beweis hat, geben Sie bitte einen Riss.)


Aktualisieren:

Es scheint, dass die jüngste Verwirrung von der jüngsten Entscheidung von Cloudflare herrührt, einen illegalen CNAME-Datensatz an der Spitze von Domänen zu definieren, für die sie A-Datensätze synthetisieren. "RFC-konform", wie im verlinkten Artikel beschrieben, bezieht sich auf die Tatsache, dass die von Cloudflare synthetisierten Datensätze gut mit DNS funktionieren. Dies ändert nichts an der Tatsache, dass es sich um ein vollständig benutzerdefiniertes Verhalten handelt.

Meiner Meinung nach ist dies ein schlechter Dienst für die größere DNS-Community: Es handelt sich tatsächlich 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)

101
Andrew B

Das Internet Systems Consortium hat kürzlich einen Bericht über CNAME am Scheitelpunkt einer Zone veröffentlicht, warum diese Einschränkung besteht, und eine Reihe von Alternativen. Dies wird sich leider nicht so schnell ändern:

Wir können nicht ändern, wie der spezielle CNAME-Eintrag verwendet wird, 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 Server-Implementierungen entsprechen dieser Spezifikation. Der Versuch, die Verwendung von CNAME in autorisierenden Servern zu "lockern", ohne gleichzeitig alle derzeit in Betrieb befindlichen DNS-Resolver zu ändern, führt dazu, dass die Namensauflösung unterbrochen wird (und Web- und E-Mail-Dienste für Organisationen, die autorisierte "entspannte" Serverlösungen implementieren, zeitweise nicht mehr verfügbar sind.

Aber es gibt Hoffnung:

Eine andere mögliche Lösung, die derzeit diskutiert wird, würde einen neuen DNS-Ressourceneintragstyp hinzufügen, den Browser nachschlagen würden und der an der Spitze vorhanden sein 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 würde ein Browser-Client-Update erfordern.

3
Daniel Liuzzi

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

Die DNAME RR und die CNAME RR [RFC1034] bewirken eine Suche, um (möglicherweise) Daten zurückzugeben, die einem Domänennamen entsprechen, der sich vom abgefragten Domänennamen unterscheidet. Der Unterschied zwischen den beiden Ressourceneinträgen besteht darin, dass die CNAME-RR die Suche nach Daten bei ihrem Eigentümer an einen anderen einzelnen Namen weiterleitet, während eine DNAME-RR die Suche nach Daten bei Nachkommen des Namens ihres Eigentümers an entsprechende Namen unter einem anderen (einzelnen) Knoten von weiterleitet der Baum.

Suchen Sie beispielsweise in einer Zone (siehe RFC 1034 [RFC1034], Abschnitt 4.3.2, Schritt 3) nach dem Domänennamen "foo.example.com", und unter "example.com" finden Sie einen DNAME-Ressourceneintrag 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" gewesen, wäre der neue Abfragename "www.foo.example.net".

0
Brian Minton