Les sous-domaines intermédiaires doivent-ils exister?
Si j'ai les hôtes example.com et leaf.intermediate.example.com dans les enregistrements DNS pour example.com, mais ne possède aucun enregistrement pour intermediate.example.com en soi, cela pose-t-il un problème dans certaines situations ou est-ce du mauvais style ou de l'é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 me manque quelque chose.
TL; DR: oui, des sous-domaines intermédiaires doivent exister, au moins lorsqu'ils sont demandé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 RFC 802 (qui n'est qu'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: ce enregistrement de ressource n'existe pas), cela signifie que toute étiquette "en dessous" de cette ressource n'existe pas non plus.
Dans votre exemple, si une requête pour intermediate.example.com renvoie NXDOMAIN, puis tout serveur de noms récursif approprié répondra immédiatement NXDOMAIN pour leaf.intermediate.example.com car cet enregistrement ne peut pas exister si toutes les étiquettes qu'il contient n'existent pas en tant qu'enregistrements.
Cela a déjà été indiqué dans le passé dans le 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. Noeuds dans l'arborescence soit
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
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 www.teh.k12.ca.us.
Bien sûr, si vous recherchez ce nom, ou même teh.k12.ca.us vous pouvez récupérer A enregistrements. 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 pour k12.ca.us (Je n'en interroge pas le serveur de noms faisant autorité, mais cela ne change en fait pas le résultat):
$ 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 c'était autre chose et spécifiquement NXDOMAIN alors teh.k12.ca.us, ni www.teh.k12.ca.us pourrait exister.
Deuxièmement, la section REPONSE est vide. Il n'y a pas d'enregistrements A pour k12.ca.us. Ce n'est pas une erreur, ce type (A) n'existe pas pour cet enregistrement, mais peut-être que 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 RFC 7719 ), comme nous le savons déjà (mais normalement la résolution est de haut en bas, donc nous atteindrons cette étape avant de passer à une niveau inférieur et non l'inverse comme nous le faisons ici à des fins de démonstration).
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. Autrement dit, votre example.com zonefile 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.com renverra NOERROR avec 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 d'un cas répandu en fait 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.arpouip6.arpa, et plus particulièrement le dernier. Vous aurez des enregistrements comme1.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 enregistrements
SRV, comme_nicname._tcp.fr. 12h IN SRV 0 0 43 whois.nic.fr., un domaine peut avoir plusieurs_proto._tcp.example.comet_proto._udp.example.comSRVenregistrements parce que par conception ils doivent avoir ce formulaire, mais en même temps_tcp.example.comet_udp.example.comrestera non-terminal vide car jamais utilisé comme enregistrement - 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. Il en va de même pour les enregistrementsTLSAdans DANE (ex:_25._tcp.somehost.example.com. TLSA 3 1 1 BASE64==) ouURIenregistrements (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, tel que détaillé dans RFC 1034 section 4.3.2 en est la raison, prenons-le et résumons dans notre cas lors de l'interrogation du serveur de noms faisant autorité ci-dessus pour le nom intermediate.example.com (c'est le QNAME dans le protocole ci-dessous):
- 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.com comme ancêtre le plus proche de QNAME, nous pouvons donc passer à l'étape 3.
Nous avons maintenant ceci:
- Commencez à faire correspondre vers le bas, é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 NS RRs marquant les coupes le long du bas d'une zone. [..]
c. Si sur 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 vers le bas, étiquette par étiquette, dans la zone. Donc, même si nous avions une longue sub.sub.sub.sub.sub.sub.sub.sub.example.com nom, à 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 au 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 réponse et passez à l'étape 6.
Quel que soit le QTYPE que nous choisissons (A, AAAA, NS, etc.), nous n'avons pas de RR pour intermediate.example.com car il n'apparaît 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 renverront NOERROR mais aucune donnée non plus.
Maintenant, vous pouvez vous demander: "mais alors si j'utilise un nom, comme another.example.com puis par l'algorithme ci-dessus, je devrais obtenir la même réponse (pas d'erreur) ", mais les observations rapporteraient plutôt NXDOMAIN dans 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
+------+
Ainsi, en suivant l'algorithme, en haut, vous pouvez en effet trouver un chemin: com > example > intermediate (car le chemin com > example > intermediate > leaf existe) Mais pour another.example.com, après com > example vous ne trouvez pas l'étiquette another dans l'arborescence, en tant que nœud enfant de example. Par conséquent, nous tombons dans une partie du choix c d'en haut:
Si le libellé "*" 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.
Étiquette * n'existe pas, et nous n'avons pas suivi un CNAME, donc nous sommes dans le cas: set an authoritative name error in the response and exit, alias 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é en partie au début de ma réponse mais ici il est plus complet:
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 éléments non
terminaux sont explicitement reconnus et que les non-terminaux vides
"exister".La lecture pédante du paragraphe ci-dessus peut conduire à une
interprétation que tous les domaines possibles existent - jusqu'à la suggestion
limite de 255 octets pour un nom de domaine [RFC1035]. Par exemple,
www.exemple. peut avoir un A RR, et dans la mesure du possible
concerné, est une feuille de l'arborescence de domaine. Mais la définition peut être
signifie 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 NXDOMAIN signifie vraiment NXDOMAIN, c'est-à-dire si vous répondez NXDOMAIN pour intermediate.example.com, puis leaf.intermediate.example.com ne peut pas exister) a été mandaté en partie parce que divers fournisseurs DNS n'ont pas suivi cette interprétation et cela a 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 juste pour eux: cela ne met pas agressivement en cache NXDOMAIN parce que pour ces fournisseurs si vous obtenez NXDOMAIN sur un nœud, cela peut toujours signifier que vous obtenez autre chose que NXDOMAIN sur 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 cela vous intéresse, 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:
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 Dig ne provient pas ni n'est dirigée vers un serveur DNS faisant autorité pour teaparty.net ou 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 pouvoir faire cela Dig vous-même, et obtenir cette réponse - teaparty.net est un vrai domaine, sous mon contrôle, et contient vraiment cet enregistrement A. Vous pouvez vérifier qu'il n'y a aucun enregistrement pour aucune de ces zones entre very et teaparty.net, et qu'il 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. Interrogation de intermediate.example.com entraînera une erreur de NXDOMAIN.
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, com et `` (noeud racine), qui sont les noeuds de l'arborescence qui forment le chemin jusqu'à 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 existe des enregistrements pour foo.bar.example.com. et example.com. mais non bar.example.com.) ceux-ci sont simplement considérés comme des nœuds d'arbre vides. 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 réponse NODATA (NOERROR status + SOA dans la section d'autorité), indiquant que le type d'enregistrement demandé n'existait pas à ce nœud. Si vous interrogez plutôt un nom qui n'existe pas, vous obtiendrez une réponse NXDOMAIN, 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.