Les sous-domaines intermédiaires doivent-ils exister?

Si j'ai les hôtes example.comet les leaf.intermediate.example.comenregistrements DNS pour example.com, mais que je n'ai pas d'enregistrements pour intermediate.example.comlui-même, cela pose-t-il un problème dans certaines situations ou est-ce un mauvais style ou une mauvaise étiquette pour une raison quelconque? J'ai des serveurs Web configurés comme ça et tout semble bien fonctionner, mais je voulais juste vérifier s'il y avait quelque chose qui me manquait.

TL; DR: oui, des sous-domaines intermédiaires doivent exister, au moins lorsqu'ils sont interrogés, par définition du DNS; ils peuvent cependant ne pas exister dans le fichier de zone.

Une confusion possible à éliminer en premier; Définition de «non-terminal vide»

Vous pouvez confondre deux choses, comme d'autres réponses semblent également le faire. À savoir, ce qui se passe lors de la recherche de noms par rapport à la façon dont vous configurez votre serveur de noms et le contenu du fichier de zone.

Le DNS est hiérarchique. Pour qu'un nœud terminal existe, tous les composants qui y mènent DOIVENT exister, dans le sens où s'ils sont interrogés, le serveur de noms faisant autorité doit répondre pour eux sans erreur.

Comme expliqué dans la RFC 8020 (qui est juste une répétition de ce qui a toujours été la règle, mais seulement certains fournisseurs DNS avaient besoin d'un rappel), si pour toute requête, un serveur de noms faisant autorité répond NXDOMAIN (c'est-à-dire que cet enregistrement de ressource n'existe pas), cela signifie alors que toute étiquette "en dessous" de cette ressource n'existe pas non plus.

Dans votre exemple, si une requête pour les intermediate.example.comretours NXDOMAIN, toute nameserver récursive appropriée répondra immédiatement NXDOMAINpour leaf.intermediate.example.comque ce disque ne peut exister que si toutes les étiquettes , il n'existent pas sous forme d' enregistrements.

Cela a déjà été déclaré dans le passé dans la RFC 4592 sur les caractères génériques (qui ne sont pas liés ici):

L'espace de nom de domaine est une structure arborescente. Les nœuds de l'arborescence
possèdent au moins un RRSet et / ou ont des descendants qui possèdent collectivement
au moins un RRSet. Un nœud peut exister sans RRSets uniquement s'il a des
descendants qui le font; ce nœud est un non-terminal vide.

Un nœud sans descendance est un nœud feuille. Les nœuds feuilles vides n'existent pas.

Un exemple pratique avec les noms de domaine .US

Prenons un exemple de travail d'un TLD avec beaucoup d'étiquettes historiquement, c'est-à-dire .US. En choisissant n'importe quel exemple en ligne, utilisons-le www.teh.k12.ca.us.

Bien sûr, si vous recherchez ce nom, ou même teh.k12.ca.usvous pouvez récupérer des Aenregistrements. Rien de concluant ici pour notre propos (il y a même un CNAME au milieu, mais on s'en fout):

$ 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

Interrogons maintenant k12.ca.us(je n'en interroge pas le serveur de noms faisant autorité, mais cela ne change pas le résultat en fait):

$ 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

Qu'apprenons-nous de cette réponse?

Tout d'abord, c'est un succès car le statut est NOERROR. Si cela avait été autre chose et spécifiquement NXDOMAINalors teh.k12.ca.us, cela www.teh.k12.ca.usn'aurait pas pu exister.

Deuxièmement, la section REPONSE est vide. Il n'y a aucun Adocument pour k12.ca.us. Ce n'est pas une erreur, ce type ( A) n'existe pas pour cet enregistrement, mais peut-être d'autres types d'enregistrement existent pour cet enregistrement ou cet enregistrement est un ENT, alias "Empty Non Terminal": il est vide, mais ce n'est pas une feuille, il y a des choses "en dessous" (voir la définition dans la RFC 7719 ), comme nous le savons déjà (mais normalement la résolution est de haut en bas, donc nous atteindrons cette étape avant d'aller un niveau en dessous et non l'inverse comme nous le faisons ici pour la démonstration) objectif).

C'est pourquoi en fait, comme raccourci, nous disons que le code d'état est NODATA: ce n'est pas un vrai code d'état, cela signifie simplement NOERROR+ une section ANSWER vide, ce qui signifie qu'il n'y a pas de données pour ce type d'enregistrement spécifique mais il peut y en avoir pour d'autres.

Vous pouvez répéter la même expérience pour le même résultat si vous interrogez avec la prochaine étiquette "up", c'est-à-dire le nom ca.us.

Résultats des requêtes vs contenu du fichier de zone

D'où peut venir la confusion? Je crois que cela peut provenir d'une fausse idée que tout point dans un nom DNS signifie qu'il y a une délégation. C'est faux. example.comAutrement dit, votre fichier de zone peut être comme ça, et il est totalement valide et fonctionne:

example.com. IN SOA ....
example.com. IN NS ....
example.com. IN NS ....

leaf.intermediate.example.com IN A 192.0.2.37

Avec un tel fichier de zone, en interrogeant ce serveur de noms, vous obtiendrez exactement le comportement observé ci-dessus: une requête pour intermediate.example.comretournera NOERRORavec une réponse vide. Vous n'avez pas besoin de le créer spécifiquement dans le fichier de zone (si vous n'en avez pas besoin pour d'autres raisons), le serveur de noms faisant autorité se chargera de synthétiser les réponses "intermédiaires", car il voit qu'il a besoin de ce non-terminal vide (et de tout d'autres "entre-deux" s'il y avait eu d'autres étiquettes) car il voit le nom de la feuille leaf.intermediate.example.com.

Notez qu'il s'agit en fait d'un cas répandu dans certaines régions, mais vous ne le verrez peut-être pas car il cible davantage d'enregistrements "d'infrastructure" auxquels les gens ne sont pas exposés:

• dans les zones inverses comme in-addr.arpou ip6.arpa, et plus particulièrement la dernière. Vous aurez des enregistrements comme 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.et il n'y a évidemment pas de délégation à chaque point, ni d'enregistrements de ressources attachés à chaque étiquette
• dans les SRVenregistrements, par exemple _nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., un domaine peut avoir plusieurs enregistrements _proto._tcp.example.comet _proto._udp.example.com SRV, car par conception, ils doivent avoir ce formulaire, mais en même temps _tcp.example.com, _udp.example.comils resteront des non-terminaux vides car ils ne sont jamais utilisés comme enregistrements.
• vous avez en fait de nombreux autres cas de construction spécifique de noms basés sur des "labels de soulignement" pour divers protocoles tels que DKIM. DKIM vous oblige à avoir des enregistrements DNS comme whatever._domainkey.example.com, mais évidemment, _domainkey.example.comen soi, ne sera jamais utilisé, il restera donc un non-terminal vide. Ceci est le même pour les TLSAenregistrements dans DANE (ex: _25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==), ou des URIdocuments (ex: _ftp._tcp IN URI 10 1 "ftp://ftp1.example.com/public")

Comportement du serveur de noms et génération de réponses intermédiaires

Pourquoi le serveur de noms synthétise-t-il automatiquement ces réponses intermédiaires? L'algorithme de résolution de base pour le DNS, comme détaillé dans la section 4.3.2 de la RFC 1034 en est la raison, prenons-le et résumons dans notre cas lorsque nous interrogeons le serveur de noms faisant autorité ci-dessus pour le nom intermediate.example.com(c'est le QNAMEprotocole ci-dessous):

2. Recherchez les zones disponibles pour la zone qui est l'ancêtre le plus proche de QNAME. Si une telle zone est trouvée, passez à l'étape 3, sinon l'étape 4.

Le serveur de noms trouve la zone example.comcomme l'ancêtre le plus proche de QNAME, nous pouvons donc passer à l'étape 3.

Nous avons maintenant ceci:

3. Commencez à faire correspondre, étiquette par étiquette, dans la zone. [..]

une. Si l'ensemble de QNAME correspond, nous avons trouvé le nœud. [..]

b. Si une correspondance nous retirait des données faisant autorité, nous avons une référence. Cela se produit lorsque nous rencontrons un nœud avec des RR NS marquant les coupes le long du bas d'une zone. [..]

c. Si au niveau d'une étiquette, une correspondance est impossible (c'est-à-dire que l'étiquette correspondante n'existe pas), regardez si une étiquette "*" existe. [..]

Nous pouvons éliminer les cas b et c, car notre fichier de zone n'a pas de délégation (donc il n'y aura jamais de renvoi vers d'autres serveurs de noms, pas de cas b), ni de caractères génériques (donc pas de cas c).

Nous n'avons qu'à traiter ici du cas a.

Nous commençons à faire correspondre, étiquette par étiquette, dans la zone. Donc, même si nous avions un sub.sub.sub.sub.sub.sub.sub.sub.example.comnom long , à un moment donné, nous arrivons au cas a: nous n'avons pas trouvé de référence, ni de caractère générique, mais nous nous sommes retrouvés avec le nom final pour lequel nous voulions un résultat.

Ensuite, nous appliquons le reste du contenu du cas a:

Si les données au nœud sont un CNAME

Pas notre cas, nous sautons cela.

Sinon, copiez tous les RR qui correspondent à QTYPE dans la section des réponses et passez à l'étape 6.

Quelle que soit qtype nous choisissons ( A, AAAA, NS, etc.) nous n'avons pas pour RRs intermediate.example.comcar il ne figure pas dans le fichier de zone. La copie ici est donc vide. Nous terminons maintenant à l'étape 6:

En utilisant uniquement des données locales, essayez d'ajouter d'autres RR qui peuvent être utiles à la section supplémentaire de la requête. Sortie.

Pas pertinent pour nous ici, donc nous finissons avec succès.

Cela explique exactement le comportement observé: de telles requêtes retourneront NOERRORmais aucune donnée non plus.

Maintenant, vous pouvez vous demander: "mais alors si j'utilise un nom, comme another.example.comalors par l'algorithme ci-dessus, je devrais obtenir la même réponse (pas d'erreur)", mais les observations rapporteraient plutôt NXDOMAINdans ce cas.

Pourquoi?

Parce que tout l'algorithme comme expliqué, commence par ceci:

L'algorithme suivant suppose que les RR sont organisés en plusieurs structures arborescentes, une pour chaque zone et une autre pour le cache

Cela signifie que le fichier de zone ci-dessus est transformé en cet arbre:

+-----+
| com |  (just to show the delegation, does not exist in this nameserver)
+-----+
   |
   |
   |
+---------+
| example | SOA, NS records
+---------+
   |
   |
   |
+--------------+
| intermediate | no records
+--------------+
   |
   |
   |
+------+
| leaf | A record
+------+

Donc, en suivant l'algorithme, du haut, vous pouvez en effet trouver un chemin: com > example > intermediate(car le chemin com > example > intermediate > leafexiste) Mais pour another.example.com, après com > examplevous ne trouvez pas l' anotherétiquette dans l'arbre, en tant que nœud enfant de example. Par conséquent, nous tombons dans une partie du choix c d'en haut:

Si l'étiquette "*" n'existe pas, vérifiez si le nom que nous recherchons est le QNAME d'origine dans la requête ou un nom que nous avons suivi en raison d'un CNAME. Si le nom est d'origine, définissez une erreur de nom faisant autorité dans la réponse et quittez. Sinon, quittez simplement.

Le label *n'existe pas, et nous n'avons pas suivi a CNAME, donc nous sommes dans le cas set an authoritative name error in the response and exit:, aka NXDOMAIN.

Notez que tout ce qui précède a créé de la confusion dans le passé. Ceci est collecté dans certains RFC. Voir par exemple cet endroit inattendu (la joie des spécifications DNS étant si impénétrable) définissant les caractères génériques: RFC 4592 "Le rôle des caractères génériques dans le système de noms de domaine" et notamment sa section 2.2 "Règles d'existence", également citée en partie au début de ma réponse mais ici elle est plus complète:

Les non-terminaux vides [RFC2136, section 7.16] sont des noms de domaine qui ne possèdent aucun enregistrement de ressource mais qui en ont un. Dans la section 2.2.1,
«_tcp.host1.example». est un exemple de nom non terminal vide.
Les non-terminaux vides sont introduits par ce texte dans la section 3.1 de la RFC 1034:

# 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.

La parenthèse "qui peut être vide" spécifie que les non-
terminaux vides sont explicitement reconnus et que les non-terminaux vides
"existent".

La lecture pédante du paragraphe ci-dessus peut conduire à une
interprétation que tous les domaines possibles existent - jusqu'à la
limite suggérée de 255 octets pour un nom de domaine [RFC1035]. Par exemple,
www.example. peut avoir un RR A et, pour ce qui est pratiquement
concerné, est une feuille de l'arborescence de domaine. Mais la définition peut être
interprétée comme signifiant ce sous-exemple. existe également, mais sans données. Par extension, tous les domaines possibles existent, de la racine vers le bas.

Comme la RFC 1034 définit également "une erreur de nom faisant autorité indiquant que le nom n'existe pas" dans la section 4.3.1, ce n'est apparemment pas l'intention de la définition d'origine, justifiant la nécessité d'une définition mise à jour dans la section suivante.

Et puis la définition dans la section suivante est le paragraphe que j'ai cité au début.

Notez que RFC 8020 (sur NXDOMAINvraiment le sens NXDOMAIN, c'est-à-dire si vous répondez NXDOMAINpour intermediate.example.com, alors leaf.intermediate.example.comne peut pas exister) a été mandaté en partie parce que divers fournisseurs DNS n'ont pas suivi cette interprétation et qui ont créé des ravages, ou ils n'étaient que des bugs, voir par exemple celui-ci corrigé en 2013 dans un code de serveur de noms faisant autorité en open source: https://github.com/PowerDNS/pdns/issues/127

Les gens devaient alors mettre des contre-mesures spécifiques pour eux: ce n'est pas une mise en cache agressive NXDOMAINcar pour ces fournisseurs, si vous atteignez NXDOMAINun nœud, cela peut toujours signifier que vous obtenez autre chose que NXDOMAINsur un autre nœud en dessous.

Et cela rendait la minimisation de QNAME (RFC 7816) impossible à obtenir (voir https://indico.dns-oarc.net/event/21/contributions/298/attachments/267/487/qname-min.pdf pour plus de détails) , alors que l'on voulait augmenter la confidentialité. L'existence de non-terminaux vides en cas de DNSSEC a également créé des problèmes dans le passé, concernant la gestion de la non-existence (voir https://indico.dns-oarc.net/event/25/contributions/403/attachments/378/647 /AFNIC_OARC_Dallas.pdf si vous êtes intéressé, mais vous avez vraiment besoin d'une bonne compréhension de DNSSEC avant).

Les deux messages suivants donnent un exemple de problèmes qu'un fournisseur a dû être en mesure d'appliquer correctement cette règle sur les non-terminaux vides, il donne une certaine perspective des problèmes et pourquoi nous y étions:

• https://mailarchive.ietf.org/arch/msg/dnsop/XIX16DCe2ln3ZnZai723v32ZIjE
• https://lists.dns-oarc.net/pipermail/dns-operations/2019-April/018640.html

Il est possible que je comprenne mal la réponse de Khaled, mais le manque d'enregistrements intermédiaires ne devrait en aucun cas être un problème avec la résolution du nom sous-zoné. Notez que cette sortie de fouille ne provient pas ni n'est dirigée vers un serveur DNS faisant autorité pour teaparty.netou l'une de ses sous-zones:

[me@nand ~]$ dig very.deep.host.with.no.immediate.parents.teaparty.net
[...]
;; ANSWER SECTION:
very.deep.host.with.no.immediate.parents.teaparty.net. 3600 IN A 198.51.100.200

En effet, vous devriez être en mesure de le faire digvous - même et d'obtenir cette réponse - teaparty.netest un véritable domaine, sous mon contrôle, et contient vraiment cet Aenregistrement. Vous pouvez vérifier qu'il n'y a aucun enregistrement pour aucune de ces zones entre veryet teaparty.netet que cela n'a aucun impact sur votre résolution du nom d'hôte ci-dessus.

Si vous interrogez directement le serveur DNS faisant autorité, vous obtiendrez des réponses sans problème.

Cependant, vous n'obtiendrez pas de réponse valide si vous interrogez via un autre serveur DNS qui n'a pas de cache valide. La requête intermediate.example.comentraînera une NXDOMAINerreur.

Pour répondre directement à la question, non, vous n'avez pas besoin d'ajouter des enregistrements pour les noms intermédiaires que vous n'utilisez pas réellement, mais cela ne signifie pas que ces noms n'existent pas.

Quant à savoir si ces noms existent ou non, c'est en fait une question entièrement distincte pour laquelle j'espère apporter une réponse brève et plutôt intuitive.

Tout se résume à ce que DNS est une structure arborescente, où chaque étiquette dans un nom de domaine est un nœud d'arborescence. Par exemple , www.example.com.a les étiquettes www, example, comet `` (noeud racine), qui sont les noeuds de l' arbre qui forment le chemin tout le chemin vers la racine.

Ce qui rend peut-être cette nature fondamentale du DNS non évidente, c'est que presque toujours lors de la gestion des données DNS, il n'y a pas d'arbre à voir et nous ne travaillons généralement pas directement avec les nœuds d'arbre eux-mêmes, au lieu de cela, nous avons généralement une liste aplatie de quel enregistrement les données qui devraient exister dans différents noms de domaine (en fait, les chemins d'arborescence, comme ci-dessus).

Ce qui se passe lorsque cette liste aplatie est utilisée, c'est que le logiciel du serveur DNS construit l'arborescence sur la base des enregistrements existants, et s'il y a des écarts entre les nœuds qui ont des enregistrements (par exemple, il y a des enregistrements pour foo.bar.example.com.et example.com.mais pas bar.example.com.), ceux-ci sont simplement considérés comme des arbres vides. nœuds. Autrement dit, ce sont des noms de domaine / nœuds qui existent en fait, l'arborescence n'est pas cassée, ces nœuds n'ont tout simplement aucune donnée qui leur est associée.

Par conséquent, si vous interrogez l'un de ces nœuds vides, vous obtiendrez une NODATAréponse ( NOERRORétat + SOAdans la section d'autorité), indiquant que le type d'enregistrement demandé n'existait pas sur ce nœud. Si vous interrogez un nom qui n'existe pas, vous obtiendrez une NXDOMAINréponse, indiquant que le nom de domaine demandé n'existe pas dans l'arborescence.

Maintenant, si vous voulez les moindres détails, lisez la réponse très complète de Patrick Mevzek.