Frage Warum kann ein CNAME-Record nicht an der Apex (Root) einer Domain verwendet werden?


Das ist ein Kanonische Frage über CNAMEs an den Spitzen (oder Wurzeln) von Zonen

Es ist relativ allgemein bekannt, dass CNAME Datensätze am Scheitelpunkt einer Domain sind tabu.

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

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

Kürzlich hatte ich eine Webhosting-Firma, die Anweisungen an eine Geschäftseinheit weitergab, die wir brauchten, um den Gipfel unserer Domain zu einem neuen Rekord zu machen. Da ich wusste, dass dies eine Selbstmord-Konfiguration wäre, wenn ich sie an BIND verfütterte, riet ich ihnen, dass wir nicht in der Lage sein würden, dies zu erfüllen, und dass dies im Allgemeinen ein Etagen-Rat war. Die Webhosting-Firma vertrat die Ansicht, dass dies nicht durch Standarddefinition von RFCs verboten ist ihr Software unterstützt es. Wenn wir den Apex nicht CNAME erreichen könnten, war ihr Ratschlag, überhaupt keinen Apex-Datensatz zu haben, und sie würden keinen weiterleitenden Webserver bereitstellen. ...Was?

Die meisten von uns wissen das RFC1912 besteht darauf, dass A CNAME record is not allowed to coexist with any other data., aber seien wir ehrlich zu uns hier, dass RFC nur informativ ist. Das nächste, das ich zu Wortlauten weiß, verbietet die Praxis ist von RFC1034:

Wenn ein CNAME-RR an einem Knoten vorhanden ist, sollten keine anderen Daten vorhanden sein   vorhanden; Dies gewährleistet, dass die Daten für einen kanonischen Namen und seine Aliase   kann nicht anders sein.

Leider war ich lange genug in der Branche, um zu wissen, dass "sollte nicht" nicht das gleiche wie "muss nicht" ist, und das ist genug Seil für die meisten Software-Designer, um sich zu erhängen. Zu wissen, dass alles, was eine knappe Verbindung zu einem Slam Dunk hätte, eine Verschwendung meiner Zeit wäre, endete damit, dass ich die Firma mit einem Schimpfen weglassen musste, um Konfigurationen zu empfehlen, die häufig verwendete Software ohne angemessene Offenlegung zerstören könnten.

Dies bringt uns zu den Fragen und Antworten. Für einmal möchte ich, dass wir bekommen Ja wirklich technisch über den Wahnsinn der CNAM-Spitzen, und nicht um das Problem herum, wie wir es normalerweise tun, wenn jemand über das Thema schreibt. RFC1912 ist tabu, ebenso wie andere informative RFC, die hier anwendbar sind, an die ich nicht gedacht habe. Lass uns dieses Baby schließen.


107
2017-07-19 10:53


Ursprung


RFC 1034 ist RFC 2119 um einiges Zeit und Erfahrung voraus. - Michael Hampton♦


Antworten:


CNAME Aufzeichnungen waren ursprünglich erstellt, um mehrere Namen zuzulassen, die dieselbe Ressource als Alias ​​für einen einzelnen "kanonischen Namen" für die Ressource bereitstellen. Mit dem Aufkommen von namensbasiertem virtuellem Hosting ist es stattdessen üblich geworden, sie als eine generische Form von IP-Adressen-Aliasing zu verwenden. Leider erwarten die meisten Leute, die von einem Webhosting-Hintergrund kommen CNAME Datensätze zum Anzeigen Äquivalenz im DNSDas war nie die Absicht. Der Apex enthält Datensatztypen, die eindeutig sind nicht verwendet bei der Identifizierung einer kanonischen Hostressource (NS, SOA), die nicht aliasiert werden können, ohne den Standard auf einer fundamentalen Ebene zu brechen. (besonders in Bezug auf Zonenschnitte)

Leider wurde der ursprüngliche DNS-Standard geschrieben, bevor die Normungsgremien erkannten, dass explizites Ausdrücken notwendig war, um konsistentes Verhalten zu definieren (RFC 2119). Es war notwendig zu schaffen RFC 2181 einige vage Fälle aufgrund von vagen Formulierungen zu klären, und die aktualisierte Wortwahl macht es klarer, dass a CNAME  kann nicht verwendet werden, um das Apex-Aliasing zu erreichen, ohne den Standard zu überschreiten.

6.1. Zonenberechtigung

Die autorisierenden Server für eine Zone werden in den NS-Sätzen aufgelistet      für den Ursprung der Zone, die zusammen mit einem Start der Autorität      (SOA) record sind die obligatorischen Datensätze in jeder Zone.  Solch ein Server      ist autorisierend für alle Ressourceneinträge in einer Zone, die nicht in      eine andere Zone. Die NS-Datensätze, die einen Zonenschnitt anzeigen, sind die      Eigenschaft der untergeordneten Zone erstellt, wie auch andere Datensätze für die      Ursprung dieser Kinderzone oder einer ihrer Subdomains. Ein Server für eine      Die Zone sollte keine autoritativen Antworten für verwandte Fragen liefern      Namen in einer anderen Zone, die die NS- und möglicherweise A-Datensätze enthält      in einer Zone schneiden, es sei denn, es ist auch ein Server für den anderen      Zone.

Das stellt dies fest SOA und NS Aufzeichnungen sind obligatorisch, aber es sagt nichts darüber aus A oder andere Arten, die hier erscheinen. Es mag überflüssig erscheinen, dass ich dies dann zitiere, aber es wird in einem Moment relevanter werden.

RFC 1034 war etwas vage über die Probleme, die auftreten können, wenn a CNAME existiert neben anderen Datensatztypen. RFC 2181 entfernt die Mehrdeutigkeit und gibt explizit die Datensatztypen an, die neben ihnen zulässig sind:

10.1. CNAME-Ressourceneinträge

Der DNS CNAME ("kanonischer Name") Datensatz existiert, um den      kanonischer Name, der einem Aliasnamen zugeordnet ist. Es kann nur einen geben      Dieser kanonische Name für einen beliebigen Alias. Dieser Name sollte allgemein sein      ein Name, der an anderer Stelle im DNS existiert, obwohl es einige selten gibt      Anwendungen für Aliase mit dem zugehörigen kanonischen Namen      undefiniert im DNS. Ein Aliasname (Label eines CNAME-Records) kann      Wenn DNSSEC verwendet wird, haben Sie SIG-, NXT- und KEY-RRs, aber möglicherweise keine      andere Daten.  Das heißt, für jedes Etikett im DNS (beliebiger Domänenname)      genau einer der folgenden ist wahr:

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

"Aliasname" bezieht sich in diesem Zusammenhang auf die linke Seite des CNAME Aufzeichnung. Die Aufzählung macht deutlich, dass a SOA, NS, und A Datensätze können nicht an einem Knoten angezeigt werden, an dem a CNAME erscheint auch. Wenn wir dies mit Abschnitt 6.1 kombinieren, ist es unmöglich für a CNAME an der Spitze zu existieren, da es neben der obligatorischen leben müsste SOA und NS Aufzeichnungen.

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


Aktualisieren:

Es scheint, dass die neuere Verwirrung von kommt Cloudflares jüngste Entscheidung um zu ermöglichen, dass ein ungültiger CNAME-Datensatz am Scheitelpunkt von Domänen definiert wird, für den sie A-Datensätze synthetisieren. "RFC-konform", wie in dem verlinkten Artikel beschrieben, bezieht sich auf die Tatsache, dass die von Cloudflare synthetisierten Datensätze gut mit DNS zusammenspielen. Dies ändert nichts an der Tatsache, dass es sich um ein vollständig benutzerdefiniertes Verhalten handelt.

Meiner Meinung nach ist dies für die größere DNS-Gemeinschaft ein Nachteil: Es ist in Wirklichkeit kein CNAME-Datensatz, und es verleitet die Leute zu der Annahme, dass andere Software nicht dafür geeignet ist, dies zuzulassen. (wie meine Frage zeigt)


85
2017-07-19 10:53



Ich stimme diesem Beweis zu und ich glaube nicht, dass dieser zweistufige Beweisweg besonders lang oder kompliziert ist. (1. die Zone Apex ist garantiert, mindestens zu haben SOA + NS Aufzeichnungen, 2. CNAME Datensätze dürfen nicht mit anderen Daten koexistieren) - Håkan Lindqvist
Insgesamt denke ich, dass es eine sehr gute Erklärung ist. Wenn etwas hinzugefügt werden könnte, denke ich, würde es möglicherweise weiter erklären, was CNAME Aufzeichnung bedeutet eigentlich, da dies wahrscheinlich der am weitesten missverstandene Aufnahmetyp ist. Auch wenn das über den Punkt hinausgeht, denke ich, dass es sich bei einer FAQ um ein direktes Ergebnis handelt, von dem viele (die meisten?) Kein richtiges Verständnis haben CNAME. - Håkan Lindqvist
@Denis Das kann innerhalb eines Kommentars nicht umfassend beantwortet werden. Die kürzeste Antwort ist, dass Sie die RFCs lesen müssen (1034, 1035) und ein gutes Verständnis dafür haben, was Verweise sind, was die erforderlichen Verhaltensweisen für einen Verweis sind (AUTORITÄT, SOA-Präsenz usw.) und warum diese Art von Verweisen "Verweisloses" Aliasing verletzt viele Erwartungen von DNS-Servern auf der funktionalen Ebene. Und das ist nur zu Beginn. Diese Frage ist hier kein gutes Thema, da sie spekulativ ist und nicht auf einem Problem basiert, das Sie bei der Arbeit mit einem ordnungsgemäß entworfenen, standardkonformen DNS-Server bekommen könnten. - Andrew B
@DenisHowe in Kürze: Es gibt keine "Domain" ohne NS- und SOA-Datensätze. Das sind die nicht-optionalen Aufzeichnungen. - hakamadare
@Ekevoo Man kann argumentieren, die HTTP-Implementierungen hätten übernommen werden sollen SRV stattdessen hätte dies auch zu einem Nicht-Problem gemacht. Das Problem ist nicht auf das beschränkt, was hier diskutiert wird; CNAME ist, entgegen der landläufigen Meinung, nicht sehr gut für das, was benötigt wird. Am Ende, als CNAME funktioniert nicht wie Leute erwarten (!) und kann nicht rückwirkend neu gestaltet werden und wie HTTP-Implementierungen nicht verwenden SRV es scheint wahrscheinlicher, dass die "Alias" -Stil-Funktionalität häufiger wird, um HTTP zu bedienen (rekordtypspezifisches Aliasing, das hinter den Kulissen und nicht als ein sichtbarer Datensatztyp implementiert ist) - Håkan Lindqvist


Wenn Sie eine gesamte Zone umleiten, sollten Sie DNAME verwenden. Gemäß RFC 6672,

Die DNAME RR und die CNAME RR [RFC1034] verursachen eine Suche nach      (möglicherweise) gibt Daten, die einem anderen Domänennamen entsprechen, zurück      aus dem abgefragten Domain-Namen. Der Unterschied zwischen den beiden      Ressourceneinträge sind, dass der CNAME-RR die Suche nach Daten anordnet      seinen Besitzer zu einem anderen einzelnen Namen, während eine DNAME RR Suchvorgänge leitet      für Daten bei Nachkommen des Namens des Besitzers zu entsprechenden Namen      unter einem anderen (einzelnen) Knoten des Baumes.

Betrachten Sie zum Beispiel eine Zone durchsehen (siehe RFC 1034 [RFC1034],      Abschnitt 4.3.2, Schritt 3) für den Domänennamen "foo.example.com" und a      Der DNAME-Ressourceneintrag befindet sich unter "example.com" und gibt dies an      Anfragen unter "example.com" werden an "example.net" gerichtet. Das Nachschlagen      Der Prozess kehrt zu Schritt 1 mit dem neuen Abfragenamen von zurück      "foo.example.net". Wäre der Name der Suchanfrage "www.foo.example.com" gewesen,      Der neue Name der Suchanfrage wäre "www.foo.example.net".


0
2018-03-27 15:41



Dies ist eine falsche Interpretation. Siehe die zweite Zeile der Tabelle in RFC 6672 §2.2. Ein Scheitelpunkt-DNAME führt zu keiner Übereinstimmung mit anderen Abfragetypen als DNAME am Scheitelpunkt, d. H. Führt nicht zu einem tatsächlichen Aliasing eines Apex-A- oder AAAA-Datensatzes. - Andrew B
Ein Apex-DNAME führt zu Nein Umleitung für Abfragen des Apex-Namens. Es ist technisch nicht richtig zu sagen, dass es zu Nein führen wird Spiel. Sie erhalten trotzdem eine Übereinstimmung, wenn Sie nach NS-, SOA- oder anderen RR-Typen suchen, die tatsächlich vorhanden sind vorhanden für den Spitznamen. Von RFC 6672: "Wenn ein DNAME-Datensatz am Apex der Zone vorhanden ist, müssen auch dort die üblichen SOA- und NS-Ressourceneinträge vorhanden sein. Ein solcher DNAME kann nicht verwendet werden." Spiegel eine Zone komplett, wie es nicht ist Spiegel der Zonenscheitel. " - Quuxplusone