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


27

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.



2
Votre titre demande d' exister , le corps demande de ne pas avoir de dossier . Pour les distinctions fines, voir les commentaires ci
Hagen von Eitzen

Réponses:


38

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):

  1. 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:

  1. 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:


Excellente réponse. La synthèse des réponses pour les domaines intermédiaires est-elle mandatée par un RFC ou s'agit-il simplement d'une convention de facto?
Lassi

1
@Lassi voir ma réponse modifiée, en plus de la mettre en sections, j'ai ajouté une explication complète de l'algorithme du résolveur (donc non ce n'est pas une convention, mais vraiment quelque chose qui sort des RFC, même si la bible de DNS aka RFC 1034 et 1035 sont pleins d'imprécision et d'ambiguïtés, il fallait donc beaucoup d'autres RFC pour affiner le langage et les règles) et j'espère des liens utiles pour en savoir plus si vous êtes intéressé.
Patrick Mevzek

1
@Lassi J'ai ajouté plusieurs exemples d'ENT dans la nature dans les enregistrements d'infrastructure: PTR, SRV, TXT pour DKIM, TLSA, URI
Patrick Mevzek

Travail incroyablement approfondi. Merci beaucoup pour vos efforts!
Lassi

11

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.


1
Je commence à être hors de ma profondeur ici, mais d'après la réponse de Patrick, cela fonctionne probablement parce que vous avez tous teaparty.netles enregistrements de dans un seul fichier de zone, donc les enregistrements vides sont synthétisés pour les domaines intermédiaires. Quelqu'un peut-il expliquer ce qui se passerait s'il parents.teaparty.nets'agit d'une délégation et qu'elle very.deep.host.with.no.immediaten'a qu'un enregistrement dans le fichier de zone des délégués?
Lassi

@Lassi exactement la même chose que vous voyez ci-dessus, car c'est exactement le même cas : teaparty.netest un sous-domaine délégué de net; si le seul enregistrement A de son fichier de zone l'était, very.deep...cela n'aurait pas d'importance.
MadHatter prend en charge Monica

1
Les exemples de liens doivent utiliser les exemples de domaines conformes à RFC - méta-discussion ici: meta.stackexchange.com/questions/186529/…
HomoTechsual

1
Ce n'est pas un exemple de lien. Cela fonctionne réellement (avez-vous même pris la peine de l'essayer?) Qui est pertinent au point en question. Comme vous le verrez dans cette méta-discussion, il y a beaucoup de noms de domaine qui ne devraient pas être obscurcis, à la fois dans les questions et les réponses.
MadHatter prend en charge Monica

1
J'étais confus par cela aussi, mais j'ai essayé. Pendant un certain temps, j'étais sûr qu'il s'agissait d'une sorte de caractère générique ou autre ... Jusqu'à ce que je comprenne que vous êtes l'administrateur DNS de ce domaine, vous avez donc pu mettre le record! Ce qui n'est pas facile à obtenir en lisant simplement la réponse, donc en général je suis du côté de @HomoTechsual. Le problème étant que dans un avenir proche, vous pouvez supprimer l'enregistrement, ou le déplacement de domaine, etc., puis cette réponse ne fonctionnera plus ... (vous pouvez sûrement dire la même chose avec mes propres exemples sur les noms .US). Néanmoins, publier des adresses IP privées dans le DNS public n'est pas une bonne idée ;-)
Patrick Mevzek

2

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.


4
Il ne doit pas en résulter NXDOMAIN, il doit en résulter un NOERRORcode et une section Réponse vide.
Barmar

4
Je ne vois pas l'intérêt de cette réponse. Il n'y a aucune raison pour que quelqu'un doive demander intermediate.example.coms'il n'est utilisé pour rien. Donc, même s'il renvoie une erreur (ce n'est pas le cas), quelle différence cela fait-il?
Barmar

5
Vous n'obtiendrez pas NXDOMAIN, vous obtenez NOERROR. C'est la réponse pour un nœud qui existe dans la hiérarchie DNS, mais qui n'a aucun enregistrement du type demandé.
Barmar

3
Même si le domaine existe, vous obtiendrez cette réponse si vous demandez un type d'enregistrement différent de ceux qu'il possède; par exemple, s'il contient des NSenregistrements, mais que vous demandez des Aenregistrements, vous obtiendrez NOERRORune réponse vide.
Barmar

4
C'est faux. Par RFC 8020 si une autorité répond nameserver NXDOMAINpour intermediate.example.comcela signifie qu'il n'y a rien « ci - dessous » et leaf.intermediate.example.comne peut pas exister. Certains résolveurs récursifs agressifs peuvent même mettre cela en cache et déduire les choses par eux-mêmes.
Patrick Mevzek

1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.