YetI

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 » de old.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à pour old.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 et NS 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 et AAAA 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 :

1. Ne pas choisir dans l’enregistrement NS une machine dont l’adresse IP varie souvent : chaque changement entraîne une période d’indisponibilité !
2. 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 domaine old.dyn.example correspond l’adresse IP 203.0.113.90 :-)
• (PTR) À l’adresse IP 203.0.113.90 correspond le nom de domaine 90.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
…