Aujourd'hui, avec les mécanismes d'allocations d'adresses IP existants (cf. RFC 7020), il est relativement fréquent d'avoir à
changer son adresse IP. Quelles sont les précautions particulières
liées au DNS lors de
ce changement ?
Supposons donc qu'un utilisateur ait une
machine à lui chez Slicehost,
Gandi, OVH ou un autre. L'adresse
IP de cette machine est « fixe » au sens où elle ne change
pas toutes les 24 heures, mais rien ne garantit qu'elle ne changera
jamais. Une nouvelle configuration du réseau, un changement de
fournisseur (pour les hébergeurs qui n'ont pas leurs propres adresses
IP) et on doit changer. Il existe plusieurs précautions à prendre lors
d'un tel changement mais on ne parle ici que de celles liées au
DNS.
D'abord et avant tout, il faut penser que les informations
distribuées par le DNS sont gardées dans des mémoires (caches). La durée de vie maximale dans le
cache est gouvernée par un paramètre nommé le
TTL (RFC 1034, section 3.6), que l'administrateur de la zone fixe
lui-même. Il est recommandé de réduire ce TTL avant le changement.
dig peut afficher le TTL, ce qui permet de
vérifier la configuration serveur :
% dig @mon-serveur A www.venezvoirchezmoi.fr.
...
www.venezvoirchezmoi.fr. 86400 IN A 192.0.2.249
Le TTL indiqué par le
serveur faisant autorité est donc de 86 400 secondes. Sur un
serveur ne faisant pas autorité, le TTL diminue petit à
petit et indique donc combien de temps il reste avant le
renouvellement du cache :
% dig A www.venezvoirchezmoi.fr.
www.venezvoirchezmoi.fr. 33982 IN A 192.0.2.249
Cette deuxième requête a interrogé le
résolveur local, qui ne
fait pas
autorité, et a donné l'information à partir de son
cache. L'enregistrement était déjà dans ce cache depuis 86 400 - 33 982
= 52 418 secondes.
Cas le plus simple ; soit un bête enregistrement ordinaire qui stocke
une adresse IP d'un serveur Web (ici, en IPv6) :
www IN AAAA 2001:db8::dead:babe
Son TTL va être donné (si on utilise BIND ou NSD) par la directive
$TTL. Mais on peut la
changer pour chaque enregistrement :
www 300 IN AAAA 2001:db8::dead:babe ; Trois cents secondes, soit cinq minutes
Ainsi, lors du changement d'adresse, il n'y aura que cinq minutes de
problème au maximum.
On peut descendre le TTL à 60 si on est pressé, mais il vaut mieux
éviter de l'abaisser à zéro,
pas mal de FAI l'ignorent (car il y
a trop d'abus) et le forcent à une valeur plus élevée (ce qui,
formellement, viole le RFC).
Évidemment, il faut faire ce changement de durée de vie à l'avance (si le TTL
actuel est de 86 400 secondes, il faut faire le changement au moins
une journée avant).
À l'heure H, on peut alors changer l'enregistrement (ici le
AAAA, l'heure H est celle où on indique la nouvelle adresse IP). Il ne faut pas remonter le TTL tout de
suite, il faut tester d'abord que tout marche bien.
Le TTL ne gouverne que la durée de vie dans les caches des
résolveurs ne faisant pas autorité. Pour les serveurs faisant autorité
sur la zone (le maître, ou « primaire » et les esclaves,
ou « secondaires »), il faut aussi surveiller leur
synchronisation. Si, par exemple, les NOTIFY (messages DNS normalisés
dans le RFC 1996 et permettant de prévenir immédiatement les esclaves) sont ignorés (il peut y avoir
des tas de raisons pour cela), le temps de synchronisation va
s'ajouter au TTL. Les esclaves ayant raté le NOTIFY ne seront
synchronisés qu'au prochain test. Les tests sont effectués toutes les
Refresh secondes, avec réessai toutes les
Retry secondes en cas d'échec. Les paramètres
Refresh et Retry sont fixés
dans l'enregistrement SOA. On voit donc l'importance de tester la
synchronisation des serveurs de la zone avant
l'heure H.
Maintenant, cas compliqué, l'adresse IP peut se trouver à d'autres
endroits que la zone :
- règles d'un coupe-feu,
- documentations,
- chez le registre et/ou le registrar.
Un coup de grep dans
/etc/** est donc recommandé pour trouver toutes
les occurrences de l'ancienne adresse IP.
Pour le cas registre / registrar, ça dépend de leur réactivité
combinée. Là encore, il vaut mieux étudier avant. Il
est donc prudent de prévoir un recouvrement (ancien serveur qui marche
toujours) si on change la colle (enregistrements d'adresses qui sont
stockés dans la zone parente).
Cette question étant souvent celle qui pose le plus de problèmes,
il faut donc faire doublement attention lorsqu'on change l'adresse IP
d'une machine qui est serveur de noms, surtout lorsqu'elle a un nom
dans la zone servie (obligeant ainsi le registre à garder la
colle).
Prenons l'exemple de la machine 192.0.2.53,
qui est connue sous le nom de ns1.example.com et
qui est serveur de noms de la zone
example.com. Le fait qu'elle soit nommée dans la
zone qu'elle sert oblige le registre de
.com à distribuer la
colle, et donc à mémoriser l'adresse IP (certains registres gardent
l'adresse IP des serveurs même lorsqu'elle n'est pas nécessaire, ce
qui est mal vu, mais arrive). Son changement d'adresse va donc
nécessiter de vérifier l'information distribuée par le registre (et
mise à jour via le registrar puisque
.com impose le passage par
un intermédiaire). Voyons avec dig comment vérifier l'adresse
distribuée par le registre, en interrogeant les serveurs de noms de
Verisign :
% dig @a.gtld-servers.net A ns1.example.com.
ns1.example.com. 172800 IN A 192.0.2.3
(Notez que cette réponse ne fait pas autorité, le
flag aa sera donc absent.)
Le DNS ne reflète pas toujours l'état actuel de la base de données du
registre. Selon les cas, il peut être prudent de vérifier avec
whois :
% whois -h whois.internic.net ns1.example.com
Server Name: NS1.EXAMPLE.COM
IP Address: 192.0.2.3
Ces deux commandes permettent de voir si les changements ont
bien été transmis au registre, et exécutés.
