TL; DR: Ja, Zwischendomänen müssen vorhanden sein, zumindest wenn sie gemäß der Definition des DNS abgefragt werden. Sie sind jedoch möglicherweise nicht in der Zonendatei vorhanden.
Eine mögliche Verwirrung zuerst zu beseitigen; Definition von "Empty Non-Terminal"
Sie können zwei Dinge verwirren, da andere Antworten ebenfalls zu tun scheinen. Was passiert, wenn Sie nach Namen fragen, und wie konfigurieren Sie Ihren Nameserver und den Inhalt des Zonefiles?
Das DNS ist hierarchisch. Damit ein Blattknoten existiert, MÜSSEN alle zu ihm führenden Komponenten existieren, in dem Sinne, dass der zuständige autorisierende Nameserver auf diese Komponenten ohne Fehler antworten muss, wenn sie abgefragt werden.
Wie in RFC 8020 erläutert (dies ist nur eine Wiederholung der Regel, aber nur einige DNS-Anbieter benötigten eine Erinnerung), antwortet ein autorisierender Nameserver bei jeder Abfrage auf NXDOMAIN (dh, dieser Ressourceneintrag ist nicht vorhanden). dann bedeutet dies, dass auch keine Bezeichnung "unterhalb" dieser Ressource vorhanden ist.
In Ihrem Beispiel, wenn eine Abfrage für intermediate.example.comErträge NXDOMAIN, dann ist jeder richtiger rekursiven Name - Server wird sofort antworten NXDOMAINfürleaf.intermediate.example.com , weil dieser Satz nicht existieren kann , wenn alle Etikett in es existieren nicht als Datensätze.
Dies wurde bereits in der Vergangenheit im RFC 4592 über Wildcards (die hier nicht zusammenhängen) angegeben:
Der Domain Name Space ist eine Baumstruktur. Knoten in der
Struktur besitzen entweder mindestens ein RRSet und / oder Nachkommen, die zusammen
mindestens ein RRSet besitzen. Ein Knoten kann nur dann ohne RRSets existieren, wenn er
Nachkommen hat, die dies tun. Dieser Knoten ist ein leerer Nicht-Terminal.
Ein Knoten ohne Nachkommen ist ein Blattknoten. Leere Blattknoten existieren nicht.
Ein praktisches Beispiel für .US-Domainnamen
Nehmen wir ein funktionierendes Beispiel von einer TLD mit vielen Labels, also historisch gesehen .US. Wenn Sie ein Beispiel online auswählen, verwenden wir eswww.teh.k12.ca.us .
Natürlich, wenn Sie nach diesem Namen fragen, oder sogar teh.k12.ca.usSie können ADatensätze zurückbekommen . Für unseren Zweck hier nichts Bestimmtes (es gibt sogar einen CNAME in der Mitte, aber das interessiert uns nicht):
$ dig www.teh.k12.ca.us A +short
CA02205882.schoolwires.net.
107.21.20.201
35.172.15.22
$ dig teh.k12.ca.us A +short
162.242.146.30
184.72.49.125
54.204.24.19
54.214.44.86
Fragen wir jetzt nach k12.ca.us(Ich frage nicht den autorisierenden Nameserver davon ab, aber das ändert nichts an dem tatsächlichen Ergebnis):
$ dig k12.ca.us A
; <<>> DiG 9.11.5-P1-1ubuntu2.5-Ubuntu <<>> k12.ca.us A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59101
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1480
;; QUESTION SECTION:
;k12.ca.us. IN A
;; AUTHORITY SECTION:
us. 3587 IN SOA a.cctld.us. hostmaster.neustar.biz. 2024847624 900 900 604800 86400
;; Query time: 115 msec
;; SERVER: 127.0.0.10#53(127.0.0.10)
;; WHEN: mer. juil. 03 01:13:20 EST 2019
;; MSG SIZE rcvd: 104
Was lernen wir aus dieser Antwort?
Erstens ist es ein Erfolg, weil der Status ist NOERROR. Wenn es irgendetwas war anders und speziell NXDOMAINdann teh.k12.ca.us, noch www.teh.k12.ca.usexistieren könnte.
Zweitens ist der Abschnitt ANTWORT leer. Es gibt keine AAufzeichnungen für k12.ca.us. Dies ist kein Fehler. Dieser Typ ( A) existiert nicht für diesen Datensatz. Möglicherweise gibt es jedoch andere Datensatztypen für diesen Datensatz. Oder dieser Datensatz ist eine HNO-Datei, auch bekannt als "Empty Non Terminal": Er ist leer, aber kein Blatt. Es gibt Dinge "darunter" (siehe Definition in RFC 7719) ), wie wir bereits wissen (aber normalerweise ist die Auflösung von oben nach unten, also werden wir diesen Schritt erreichen, bevor wir eine Ebene darunter gehen und nicht das Gegenteil, wie wir es hier zu Demonstrationszwecken tun Zweck).
Aus diesem Grund wird als Abkürzung der Statuscode folgendermaßen angegeben NODATA: Dies ist kein echter Statuscode, sondern bedeutet lediglich NOERROR+ leerer Abschnitt ANTWORT. Dies bedeutet, dass für diesen bestimmten Datensatztyp keine Daten vorhanden sind, für andere möglicherweise jedoch Daten.
Sie können dasselbe Experiment für dasselbe Ergebnis wiederholen, wenn Sie mit der nächsten Beschriftung "up" (d. H. Dem Namen) abfragen ca.us.
Ergebnisse von Abfragen im Vergleich zu Zonefile-Inhalten
Woher kann nun die Verwirrung kommen? Ich glaube, es könnte eine falsche Vorstellung sein, dass jeder Punkt in einem DNS-Namen bedeutet, dass es eine Delegation gibt. Das ist falsch. Anders gesagt, Ihr example.comZonefile kann so aussehen, und es ist absolut gültig und funktioniert:
example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....
leaf.intermediate.example.com IN A 192.0.2.37
Wenn Sie mit einem solchen Zonefile diesen Nameserver abfragen, erhalten Sie genau das oben beschriebene Verhalten: Eine Abfrage für intermediate.example.comgibt NOERROReine leere Antwort zurück. Sie müssen es nicht speziell in der Zonendatei erstellen (wenn Sie es aus anderen Gründen nicht benötigen), der autorisierende Nameserver kümmert sich um die Synthese der "Zwischen" -Antworten, da er feststellt, dass dieses leere Nicht-Terminal (und eines davon) benötigt wird andere "dazwischen", wenn es andere Bezeichnungen gegeben hätte), da sie den Blattnamen sehen leaf.intermediate.example.com.
Beachten Sie, dass dies in einigen Bereichen tatsächlich weit verbreitet ist, Sie es jedoch möglicherweise nicht sehen, da es auf mehr "Infrastruktur" -Datensätze abzielt, denen Personen nicht ausgesetzt sind:
- in umgekehrten Zonen wie
in-addr.arpoder ip6.arpaund speziell der letzten. Sie haben Aufzeichnungen wie 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.e.1.6.8.0.0.0.0.0.0.2.6.2.ip6.arpa. 1h IN PTR text-lb.eqiad.wikimedia.org.und es gibt offensichtlich keine Delegierung an jedem Punkt, noch Ressourcenaufzeichnungen, die an jedem Etikett angehängt sind
- In
SRVDatensätzen kann _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr.eine Domain viele _proto._tcp.example.comund _proto._udp.example.com SRVDatensätze haben, da sie von Entwurf her dieses Formular haben müssen, aber gleichzeitig _tcp.example.comund _udp.example.comleer bleiben, da sie nie als Datensätze verwendet werden
- Sie haben in der Tat viele andere Fälle der spezifischen Konstruktion von Namen, die auf "Unterstrich-Bezeichnungen" für verschiedene Protokolle wie DKIM basieren. DKIM fordert Sie dazu auf, DNS-Einträge wie diese zu haben
whatever._domainkey.example.com, diese werden jedoch offensichtlich _domainkey.example.comnie für sich genommen verwendet, sodass sie leer bleiben. Dies ist das gleiche für TLSAAufzeichnungen in DANE (ex: _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==) oder URIAufzeichnungen (zB: _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")
Nameserver Verhalten und Generierung von Zwischenantworten
Warum synthetisiert der Nameserver solche Zwischenantworten automatisch? Der Kernauflösungsalgorithmus für das DNS, wie in RFC 1034, Abschnitt 4.3.2 beschrieben, ist der Grund dafür. Nehmen wir ihn und fassen ihn in unserem Fall zusammen, wenn wir den oben genannten autorisierenden Nameserver nach dem Namen abfragen intermediate.example.com(dies ist das QNAMEunten stehende In-Protokoll):
- Durchsuchen Sie die verfügbaren Zonen nach der Zone, die QNAME am nächsten kommt. Wenn eine solche Zone gefunden wird, fahren Sie mit Schritt 3 fort, andernfalls mit Schritt 4.
Der Nameserver findet zone example.comals nächsten Vorfahren von QNAME, sodass wir mit Schritt 3 fortfahren können.
Wir haben jetzt folgendes:
- Beginnen Sie in der Zone mit der Suche nach unten, Etikett für Etikett. [..]
ein. Wenn der gesamte QNAME übereinstimmt, haben wir den Knoten gefunden. [..]
b. Wenn uns eine Übereinstimmung aus den maßgeblichen Daten bringen würde, liegt eine Überweisung vor. Dies geschieht, wenn wir auf einen Knoten mit NS-RRs stoßen, die Schnitte am unteren Rand einer Zone markieren. [..]
c. Wenn bei einem Label eine Übereinstimmung nicht möglich ist (dh das entsprechende Label existiert nicht), prüfen Sie, ob ein "*" - Label existiert. [..]
Wir können die Fälle b und c eliminieren, da unser Zonefile keine Delegierung hat (daher wird es nie eine Verweisung auf andere Nameserver geben, keinen Fall b), noch Platzhalter (also keinen Fall c).
Wir müssen uns hier nur mit Fall a befassen.
Wir fangen an, Label für Label in der Zone zu vergleichen. Selbst wenn wir einen langen sub.sub.sub.sub.sub.sub.sub.sub.example.comNamen hatten, kommen wir irgendwann zu Fall a: Wir haben weder eine Empfehlung noch einen Platzhalter gefunden, aber am Ende haben wir den endgültigen Namen gefunden, für den wir ein Ergebnis wollten.
Dann wenden wir den Rest des Inhalts von Fall a an:
Wenn die Daten am Knoten ein CNAME sind
Nicht unser Fall, das überspringen wir.
Kopieren Sie andernfalls alle RRs, die mit QTYPE übereinstimmen, in den Antwortbereich und fahren Sie mit Schritt 6 fort.
Was auch immer QTYPE wir wählen ( A, AAAA, NS, usw.) wir haben keine RRs für intermediate.example.comda es nicht in der Zonendatei erscheint. Die Kopie hier ist also leer. Jetzt beenden wir bei Schritt 6:
Versuchen Sie, nur lokale Daten zu verwenden, um andere RRs hinzuzufügen, die im zusätzlichen Abschnitt der Abfrage nützlich sein können. Ausgang.
Für uns hier nicht relevant, daher schließen wir mit Erfolg ab.
Dies erklärt genau das beobachtete Verhalten: Solche Abfragen werden zurückgegeben, NOERRORaber auch keine Daten.
Nun fragen Sie sich vielleicht: "Aber wenn ich dann irgendeinen Namen verwende, wie another.example.comdamals durch den obigen Algorithmus, sollte ich die gleiche Antwort bekommen (kein Fehler)", aber Beobachtungen würden NXDOMAINin diesem Fall stattdessen berichten .
Warum?
Da der gesamte Algorithmus wie erklärt mit folgendem beginnt:
Der folgende Algorithmus geht davon aus, dass die RRs in mehreren Baumstrukturen organisiert sind, eine für jede Zone und eine andere für den Cache
Dies bedeutet, dass die obige Zonendatei in diesen Baum umgewandelt wird:
+-----+
| com | (just to show the delegation, does not exist in this nameserver)
+-----+
|
|
|
+---------+
| example | SOA, NS records
+---------+
|
|
|
+--------------+
| intermediate | no records
+--------------+
|
|
|
+------+
| leaf | A record
+------+
Wenn Sie also dem Algorithmus von oben folgen, können Sie in der Tat einen Pfad finden: com > example > intermediate(weil der Pfad com > example > intermediate > leafexistiert) Aber another.example.comnachdem com > exampleSie die anotherBezeichnung im Baum nicht gefunden haben, als Kinderknoten von example. Daher fallen wir von oben in einen Teil von Wahl c:
Wenn die Bezeichnung "*" nicht vorhanden ist, überprüfen Sie, ob der gesuchte Name der ursprüngliche QNAME in der Abfrage oder ein Name ist, dem wir aufgrund eines CNAME gefolgt sind. Wenn der Name ursprünglich ist, legen Sie einen autorisierenden Namensfehler in der Antwort fest und beenden Sie das Programm. Ansonsten einfach raus.
Label *existiert nicht und wir sind keinem gefolgt CNAME, daher sind wir für den Fall set an authoritative name error in the response and exit:, aka NXDOMAIN.
Beachten Sie, dass all dies in der Vergangenheit zu Verwirrung geführt hat. Dies wird in einigen RFCs gesammelt. Sehen Sie sich zum Beispiel diesen unerwarteten Ort an (die Freude daran, dass DNS-Spezifikationen so undurchdringlich sind), der Platzhalter definiert: RFC 4592 "Die Rolle von Platzhaltern im Domain Name System" und insbesondere Abschnitt 2.2 "Existenzregeln", der ebenfalls teilweise am Anfang von zitiert wurde meine antwort aber hier ist es vollständiger:
Leere Nicht-Terminals [RFC2136, Abschnitt 7.16] sind Domänennamen, die keine Ressourceneinträge besitzen, jedoch über Subdomänen verfügen. In Abschnitt 2.2.1,
"_tcp.host1.example". ist ein Beispiel für einen leeren Nicht-Terminal-Namen.
Mit diesem Text werden leere Nicht-Terminals in Abschnitt 3.1 von RFC 1034 eingeführt:
# The domain name space is a tree structure. Each node and leaf on
# the tree corresponds to a resource set (which may be empty). The
# domain system makes no distinctions between the uses of the
# interior nodes and leaves, and this memo uses the term "node" to
# refer to both.
Die Klammer "die leer sein kann" gibt an, dass leere Nicht-
Terminals explizit erkannt werden und dass leere Nicht-Terminals
"existieren".
Das pedantische Lesen des obigen Abschnitts kann zu einer
Interpretation führen, dass alle möglichen Domänen existieren - bis zur vorgeschlagenen
Grenze von 255 Oktetten für einen Domänennamen [RFC1035]. Zum Beispiel
www.example. kann eine A RR haben und ist, soweit es praktisch
geht, ein Blatt des Domänenbaums. Unter der Definition kann jedoch
dieses Beispiel verstanden werden. existiert auch, wenn auch ohne Daten. Durch die Erweiterung existieren alle möglichen Domänen von der Wurzel an abwärts.
Da RFC 1034 in Abschnitt 4.3.1 auch "einen autorisierenden Namensfehler, der angibt, dass der Name nicht vorhanden ist" definiert, ist dies anscheinend nicht die Absicht der ursprünglichen Definition, was die Notwendigkeit einer aktualisierten Definition im nächsten Abschnitt rechtfertigt.
Und dann ist die Definition im nächsten Abschnitt der Absatz, den ich am Anfang zitiert habe.
Beachten Sie, dass RFC 8020 (auf NXDOMAINwirklich bedeutet NXDOMAIN, dass , wenn Sie antworten ist NXDOMAINfür intermediate.example.com, dann leaf.intermediate.example.comnicht existieren kann) teil beauftragt wurde , weil verschiedene DNS - Anbieter diese Interpretation nicht folgen hat und dass erstellt Chaos, oder sie waren nur Bugs, siehe zum Beispiel dieses 2013 in einem autorisierenden OpenSource-Nameserver-Code behoben: https://github.com/PowerDNS/pdns/issues/127
Die Leute mussten dann spezielle Gegenmaßnahmen nur für sie treffen: Das ist kein aggressives Caching, NXDOMAINdenn für diese Anbieter kann NXDOMAINes bedeuten, dass Sie NXDOMAINan einem bestimmten Knoten noch etwas anderes als an einem anderen Knoten darunter erhalten.
Dies machte es unmöglich, eine QNAME-Minimierung (RFC 7816) zu erhalten (weitere Informationen finden Sie unter https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf ). , während es die Privatsphäre erhöhen wollte. Das Vorhandensein leerer Nicht-Terminals im Falle von DNSSEC hat in der Vergangenheit ebenfalls Probleme hinsichtlich der Behandlung von Nicht-Existenz verursacht (siehe https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647) /AFNIC_OARC_Dallas.pdf wenn Sie interessiert sind, aber Sie brauchen wirklich ein gutes Verständnis von DNSSEC, bevor Sie).
Die folgenden zwei Meldungen geben ein Beispiel für Probleme, bei denen ein Anbieter in der Lage sein musste, diese Regel für leere Nicht-Terminals ordnungsgemäß durchzusetzen. Sie geben einen Überblick über die Probleme und warum wir dort waren: