Cet article est écrit en collaboration avec Axel Viala. Tout au long de l’article nous parlons de serveurs faisant autorité, les révolveurs n’ayant pas ce cas à gérer.
Sur un nom de domaine, on peut se retrouver avec des sous-domaines vides
mais ayant des enfants. Nous appelons cela un ENT (empty non terminal).
Ceci peut rentrer en conflit avec deux autres mécanismes du DNS : le
qname-minimisation et le wildcard.
Sur cet article nous allons partir d’une zone sans aucune fioriture,
puis en rajouter au fur et à mesure afin de voir comment un ENT peut
invalider un wildcard.
Prenons pour exemple une zone sans piège mais contenant un ENT :
$ORIGIN alarig.example.
@ 10800 IN SOA ns hostmaster 2023051900 14400 3600 604800 86400
@ 10800 IN NS ns
ns 10800 IN A 192.0.0.8
ns 10800 IN AAAA 2001:db8::35
www.ent 10800 IN AAAA 2001:db8::1bb
Ici nous avons un seul NS, son A/AAAA associé et un enregistrement pour le
serveur web du sous-domaine ent.
Pourquoi est-ce un ENT ? Car le domaine ent ne contient rien
en lui-même, et pourtant www.ent existe. Nous avons donc
affaire à un sous-domaine www d’un domaine vide
ent. Ceci est défini dans la section 2.2.2 de la RFC 4592. Les serveurs DNS
doivent alors répondre avec un status NOERROR et une section de réponse
vide (on appelle cela NODATA).
En soit ici, d’un point de vue de la compréhension de la zone, comprendre
le concept d’ENT n’est pas forcément essentiel. On voit assez bien où on
veut arriver ; tout ce qui est resolvable étant explicitement écrit dans
la zone, à l’inverse d’un wildcard qui permet implicitement une infinité
de labels.
Par contre maintenant, si je pars d’une zone avec un wildcard mais sans ENT, toutes les requêtes au niveau du wildcard auront une réponse correspondant à ce que j’ai défini :
$ORIGIN alarig.example.
@ 10800 IN SOA ns hostmaster 2023051901 14400 3600 604800 86400
@ 10800 IN NS ns
ns 10800 IN A 192.0.0.8
ns 10800 IN AAAA 2001:db8::35
* 10800 IN CNAME example.com.
Ici, une requête sur ent.alarig.example. répondra le CNAME
vers example.com.
Mais si je veux ajouter un sous-domaine par rapport au wildcard, je vais créer un ENT et je vais donc invalider le wildcard du domaine parent :
$ORIGIN alarig.example.
@ 10800 IN SOA ns hostmaster 2023051902 14400 3600 604800 86400
@ 10800 IN NS ns
ns 10800 IN A 192.0.0.8
ns 10800 IN AAAA 2001:db8::35
* 10800 IN CNAME example.com.
www.ent 10800 IN AAAA 2001:db8::1bb
Ici, une question sur ent.alarig.example. aura une réponse
vide, alors que c’était précédemment le contenu du CNAME.
Pourtant, un humain lisant la zone saurait trouver la réponse, car nous
sommes capables de lever l’ambigüité nous-mêmes. Mais ce n’est pas aussi
évidement pour un ordinateur. Pour quelle raison me direz-vous ? Car il
faut gérer une consistance. Lorsque l’on définit quelque chose déjà couvert
par un wildcard, il en prend la précédence, pour des questions de
cohérence. On peut appeler ça la règle du plus spécifique. Sans cela nous
ne pourrions pas garantir au sens du protocole un comportement prévisible
entre les différentes implémentations.
Concrètement, cela veut dire qu’un label à un niveau couvert par un
wildcard sera utilisé au lieu du wildcard. Donc ici, bien
qu’ent ne soit pas explicitement défini, il existe quand même
pour que www.ent puisse exister, mais il est vide ; ce qui
provoque une réponse vide pour les questions sur ce domaine.
Si on veut continuer à avoir les réponses que l’on avait avant, il faut le déclarer explicitement, ce qui donnera donc cette zone :
$ORIGIN alarig.example.
@ 10800 IN SOA ns hostmaster 2023051903 14400 3600 604800 86400
@ 10800 IN NS ns
ns 10800 IN A 192.0.0.8
ns 10800 IN AAAA 2001:db8::35
* 10800 IN CNAME example.com.
ent 10800 IN CNAME example.com.
www.ent 10800 IN AAAA 2001:db8::1bb
Dans cette version de la zone, le domaine ent n’est
finalement plus un ENT, nous avons un enregistrement directement dessus.
Ceci est nécessaire afin que le CNAME original soit toujours utilisable.