Pour simplifier la discussion, appelons « new.example
» le domaine acheté et « old.dyn.example
» le domaine dynamique gratuit précédemment utilisé.
Que puis-je faire ?
Théoriquement, il y a deux façons de faire correspondre new.example
à mon adresse IP :
- soit je paramètre
new.example
pour être un « alias » deold.dyn.example
: dans ce cas, lorsqu’on demande l’adresse IP associée ànew.example
, le serveur DNS demande en fait l’adresse IP associée àold.dyn.example
, qui est dynamiquement configuré pour pointer vers la bonne adresse IP (celle dont je dispose à cet instant) ; - soit je change directement le paramétrage DNS associé à
new.example
avec la bonne adresse IP, à chaque fois que cette adresse change (comme je le fais déjà pourold.dyn.example
), de telle sorte que lorsqu’on demande l’adresse IP associée ànew.example
, on obtienne directement la bonne réponse.
En pratique, la première option est impossible, comme me l’a expliqué jercos sur IRC (édité pour plus de clarté) :
< jercos> The problem at hand is that a CNAME record is not allowed to
coexist with any other records, and your second-level domain
needs, at very least, an SOA record
< jercos> (and the NS records to point at its hosting nameservers).
< jercos> Now, if you managed .example, you could place a CNAME record
for new.example without ever making an NS or SOA record
< jercos> but if you own the second level domain, you *must* have an
SOA record there, and if you host it yourself rather than on
the .example nameservers, you must have NS records there.
< jercos> The NS data sits on .example nameservers and is mirrored on
your own, and the SOA record is published by your
nameservers. Given that you can't control .example
nameservers, you are forced to have records for new.example
other than a CNAME, and thus cannot have a CNAME.
En résumé, l’enregistrement CNAME
(nom technique de l’alias) ne peut coexister avec aucun autre enregistrement. Une petite nuance toutefois, apportée par lunaphyte sur IRC ; ça n’a pas de lien direct avec le sujet de cet article mais ça évitera de diffuser de fausses informations :
< rjsalts> Correct, CNAMEs cannot coexist with any other RR type
< lunaphyte> [dnssec records being an exception]
< rjsalts> lunaphyte, even DNSKEY? or KEY records?
< lunaphyte> rjsalts: sig, nxt, and key
Voilà, c’est dit. La petite nuance, c’est que CNAME
peut exceptionnellement coexister avec quelques autres enregistrements, liés à DNSSEC (Le DNS sécurisé qui peine à décoller). Mais ça n’avance pas mon sujet :-)
Bref, une seule option finalement : laisser tomber old.dyn.example
et mettre à jour dynamiquement les enregistrements DNS associé à new.example
. Mais… l’organisme auprès duquel je vais acheter mon nom de domaine le permettra-t-il ? Direction Ixquick (ou Google si vous préférez)… pour un résultat mitigé.
Il s’avère que la plupart des fournisseurs de noms de domaines ne proposent pas de pouvoir mettre à jour les enregistrement DNS de manière dynamique (via un programme automatique et non via l’interface web).
Mais OVH au moins permet et documente cette fonctionnalité. Là, je constate que la fonctionnalité n’est proposée que pour un sous-domaine et non pour le domaine principal ; autrement dit, il me serait possible de paramétrer www.new.example
ou mail.new.example
en mode dynamique, mais pas new.example
directement. Étant donné qu’auparavant j’avais lu dans la documentation pour Debian et Ubuntu des textes qui semblaient aller dans le même sens (je sais maintenant que non : c’est parce que ces instructions veulent utiliser CNAME
), j’ai cru que le protocole DNS lui-même allait m’obliger à déclarer des sous-domaines ! C’est ce que j’ai voulu vérifier immédiatement sur IRC (#dns @ freenode.net) :
< rjsalts> You should be able to update the .example domain if you are
the registrant.
< rjsalts> If your dynamic dns provider can't handle it, find a better
one.
< ME> I'm not sure I understand. I will be the registrant of, say,
"new.example". But I assume I will have absolutely no control
over the DNS records of "example".
< rjsalts> If you're the registrant of new.example then you should be
able to delegate that domain to your provider, and your
provider should be able to publish A/AAA/TXT/... records at
new.example of your desire.
OK. Donc il n’est a priori par nécessaire de déclarer des sous-domaines ; il suffit de trouver un fournisseur de nom de domaine adapté à mon besoin. J’ai pu lire la confirmation de ceci dans les news du protocole DNS, dans un message de Barry du MIT, rien de moins !
There's no DNS-based reason why they shouldn't allow dynamic updates
of the A record on the zone apex. This is a restriction your DNS
provider is adding on their own.
Bien. Le problème, maintenant, c’est qu’aucun fournisseur de nom de domaine ne semble correspondre à mon besoin :-(
Heureusement, jercos est venu une fois de plus à mon secours sur IRC :
< ME> jercos: OK. So I now have to find the registrar that will allow
me to update my "A" record whenever my IP is changing.
< jercos> The registrar is related, but not tied. The registrar
handles taking your money and giving you a domain, and often
registrars will provide free DNS hosting with your continued
payment on a domain name...
< jercos> However almost all registrars will let you put in another
DNS host's nameservers and attach your domain to them.
< jercos> So you can give money to one group, and manage your records
with another :D
< jercos> As far as I know, for example, dns.he.net doesn't provide a
registrar service at all, only the DNS hosting portion.
< jercos> So really, buy your domain from whoever's the cheapest, and
have them set the nameserver records to point to whoever
provides the features you want, in this case dynamic DNS.
Sauvé ! En résumé, je vais donc pouvoir acheter mon nom de domaine où je veux (pas forcément le moins cher d’ailleurs ; par exemple, je pourrais choisir un « registrar » pour le soutenir dans ses actions) puis gérer ce domaine sur un serveur différent.
Comment bien faire ?
Je vais donc m’inscrire auprès d’un hébergeur de DNS, qui me proposera un espace pour gérer les enregistrements DNS de new.example
et permettra également à mon serveur de mettre à jour des enregistrements DNS lui-même. Oui, mais quels enregistrements ?
À première vue, là encore, deux options :
- soit je demande à mon serveur de gérer lui-même son propre DNS, auquel
cas je dois mettre à jour chez l’hébergeur DNS les enregistrements
A
,AAAA
etNS
lorsque mon adresse IP change ; - soit je laisse gérer mon domaine principal par l’hébergeur DNS et dois donc mettre à jour les enregistrements
A
etAAAA
lorsque mon adresse IP change (les sous-domaines, s’il y en a, sont alors également gérés chez l’hébergeur DNS).
Et une fois de plus, la première option tombe à l’eau, comme me l’explique rjsalts sur IRC (#dns @ freenode.net) :
< ME> So in short, it's just up to me to choose a DNS provider that
will allow me to update the "A" record whenever it is necessary,
or buy my domain name at a place that will allow me to update
the "NS" record whenever it is necessary (and then manage my own
DNS). Do I understand correctly?
< rjsalts> The first option will work. Updating your dns servers will
probably cause problems in resolution at times, so you'd
want to leave them on the same ips as much as possible.
< ME> rjsalts: I see. updating the NS records would have propagation
delays, I assume... So only one solution: find a DNS provider
that will allow me to update "A" for new.example.
Ce qui mène à deux leçons :
- Ne pas choisir dans l’enregistrement
NS
une machine dont l’adresse IP varie souvent : chaque changement entraîne une période d’indisponibilité ! - rjsalts et lunaphyte m’ont ensuite expliqué que le « délai de propagation » était en fait un problème du passé : la propagation en elle-même est maintenant quasi-instantanée. Le problème qui mène à la leçon nº1 est en fait un problème de cache : tout comme les navigateurs web, les serveurs DNS intermédiaires gardent en mémoire les informations déjà connues pendant un délai (appelé TTL, « Time To Live ») non négligeable pouvant aller jusqu’à 24 heures.
Mes enregistrements DNS seront donc gérés chez l’hébergeur DNS.
Et le reverse-DNS (enregistrement PTR
) ?
En particulier quand on gère son propre serveur de messagerie, il est préférable que l’enregistrement A
(traduction du nom de domaine vers l’adresse IP) et l’enregistrement PTR
(traduction de l’adresse IP vers le nom de domaine) soient en cohérence. Supposons que mon adresse IP soit 203.0.113.90
. Actuellement, quand j’interroge les serveurs DNS, on me répond que :
- (
A
) Au nom de domaineold.dyn.example
correspond l’adresse IP203.0.113.90
:-) - (
PTR
) À l’adresse IP203.0.113.90
correspond le nom de domaine90.113.0.203.rev.sfr.net
:-(
Vous l’aurez compris, mon FAI (fournisseur d’accès à Internet) est dans cet exemple SFR et c’est le FAI qui gère l’enregistrement PTR
; j’ai trouvé une confirmation de cela sur le site de FreeDNS.
La seule solution semble donc de demander à son FAI s’il lui est possible de faire correspondre l’enregistrement PTR
au nom de domaine voulu (en ajustant cet enregistrement lors des changements d’adresse IP). Peut-être même le FAI acceptera-t-il d’être hébergeur DNS… Je laisse le mot de la fin à hawk et Anonissimus sur IRC (#dns @ freenode.net) :
< ME> I was wondering: Is there any way I can register my own domain
name, and have the A and PTR records in sync, given that the IP
for my A record will be my home server's, and my home PTR is
currently managed by my Internet Service Provider?
< hawk> You'd have to ask your ISP, I guess.
< hawk> And if you are talking about your regular consumer-oriented
ISP and you ask to have the PTR for the IP they assigned to
you changed, the answer is almost certainly "no".
< Anonissimus> or do an nsupdate
…