Fonctionnement DNS, questions théoriques

Support Debian
#1

Bonjour à tous :slightly_smiling:

Lire un tuto c’est bien, le comprendre c’est mieux.
J’ai beau lire et faire des recherches sur le net, certaines questions restent pour moi sans réponse. :think:

C’est pourquoi je me permet de poster ici, et de solliciter vos lumières pour des questions qui ne sont pas du tout technique… mais plutôt théorique.
Je me dis aussi que mon post pourra servir aussi à d’autres personnes. :083
Avant toute chose sachez que j’ai bien lu attentivement la page DNS du wiki.

Pour situer les choses dans leur contexte :
Je possède un serveur dédié chez OVH sous Debian.
Je possède un nom de domaine (que j’appellerai ici exemple.fr) acheté chez OVH.
Aujourd’hui mon serveur bind fonctionne bien (depuis longtemps même, merci la stabilité Debian).

Mais j’avoue avoir configuré mon serveur sans trop vraiment comprendre certains aspects, notamment (surtout) les durées d’enregistrements.
Voici mes questions :

  • Question 1 -

Quand j’ai acheté mon domaine “exemple.fr”, que fait exactement OVH ? Il va inscrire sur le serveur qui gère la zone “.fr” l’entrée “exemple” ? Et qu’écrit il exactement ? Dit il : “exemple.fr” c’est géré par un de mes clients, donc viens demander chez moi ?
Puis lorsque depuis un client n’importe où dans le monde demande l’adresse ip de “www.exemple.fr” il va interroger le serveur DNS de son FAI (souvent) qui lui même va dire “ah je connais pas, je vais demander à celui qui gère la zone .fr”
Le serveur DNS ".fr va dire “Il faut aller voir chez OVH”. OVH dit “Oui je connais cette zone mais c’est sur CE serveur dédié qu’il faut aller” Puis là on tombe sur mon bind ?

Est ce que j’ai bien compris ou je dis des âneries ?

  • Question 2 -

Concernant les serveurs secondaires. OVH en propose un à indiquer : sdns1.ovh.net
Je comprend donc que le serveur DNS d’OVH peut répondre à une question sur la zone quand mon serveur dédié est down.
Mais si admettons que je choisisse de ne pas donner de serveur secondaire (est ce possible ?), que se passe t il si le serveur est down ?
Est ce que le serveur qui gère “.fr” garde une copie de la zone en cache ? Si son cache expire (expire t il ?), il se passe quoi ? Rideau, timeout, message d’erreur coté client ?

  • Question 3 -

Toujours sur les secondaires. Si je veux que mon serveur soit tout le temps sollicité et qu’il n’y ai pas de cache, je dois mettre le TTL (Time to live) à zéro
Mais…lequel ? le wiki parle du negative TTL plus bas dans la conf, mais à quoi sert le tout premier TTL tout en haut avec le dollar ?
Si je sais que je vais bientôt déménager de serveur dédié (et donc d’ip pour ma zone) est il pertinent de penser ainsi (cache à zéro pour éviter les mauvaises ip) ?
Ou bien est ce idiot car il y a toujours une propagation des DNS (cache du FAI) ?

  • Question 4 -

Encore sur les secondaires. Si je suis mal intentionné et que je veux malmener le serveur secondaire d’OVH : Est ce que je pourrai mettre un Rerefresh de 5 secondes ? Le DNS d’OVH v a t il réellement requêter mon serveur bind toute les 5 secondes pour voir si la zone à changer ? N’est ce pas un peu dangereux bien que faisable ?
C’est là que le serial entre en compte j’imagine mais il va bien falloir qu’il vérifie la valeur du serial non ? Il va donc demander le serial de la zone toutes les 5 secondes ? Y a t il des gardes-fous contre ce mécanisme ?

  • Question 5 -

Qui sont affectés par les réglages “Refresh, Retry, Expire” ? Uniquement les serveurs secondaires de la zone ? Ou bien tout les serveurs DNS qui font une requête et qui feront du cache par la suite ?

  • Question 6 -

Au début de la configuration de la zone on doit saisir un email pour l’administrateur. Il faut l’écrire en replaçant le @ par un point.
Mais à quel moment cet email est il “dévoilé” ? Un bot peut il le récupérer ? Est ce grave s’il l’on met n’importe quoi ?

Désolé pour toutes ces questions, je suis conscient que ça fait beaucoup de points évoqués, et que fournir une réponse demande du temps, mais je vous remercie par avance pour votre patience.

:023

#2

La règle est: une question par post.
Concernant la question 1, l’enregistrement chez le registar associe un nom (exemple.fr) avec une adresse IP (ou plusieurs si tu as un très gros domaine comme google). Il enregistre des informations sur le propriétaire, celles qu’on voit avec la commande whois.
Avoir son propre serveur DNS n’est utile qui si tu gères de nombreux postes, et que tu veux leur permettre d’accéder rapidement à l’adresse ip correspondant à une adresse (mise en cache).
Tu peux aussi t’en servir pour les orienter vers une fausse adresse IP …

#3
  1. Lorsque tu fais un whois, tu as le serveur de nom, mettons ns.toto.fr que tu vas chercher dans toto.fr puis si il n’y ait pas dans .fr (c’est le fameux glue record qui est un enregistrement qui dépasse le domaine auquel il appartient, ns.toto.fr est dans fr ainsi que toto.fr)
  2. Si tes serveurs DNS sont en rade, mis à part les serveurs DNS conservant un cache pendant quelque temps comme ceux des FAI, ton domaine devient inaccessible
  3. Le TTL est en secondes, son maximum est 86400 et son minimum 0, c’est toi qui choisit comme un grand. Quoi qu’il arrive les enregistrements dans les cache disparaissent au bout de ce temps. Si tu déménages, 24h avant tu mets le TTL à 0 et au bout de 24h les enregistrements dans les caches sont tous effacés.
  4. et 5) Je pense que les caches ne s’occupent que d’eux même et ne cherchent à renouveller un enregistrement qu’à la demande. Pour les secondaires, c’est leur boulot de se rafraichir à leur demande, je ne crois pas que tu puisses écrouler OVH avec ce genre de choses mais là je ne peux répondre en détail.
  5. Les emails sont ou ne sont pas rendus publics suivants tes choix MAIS tu dois avoir quoi qu’il arrive une adresse admin@tondomaine.fr qui répond (vérifie ce point, ça n’est qu’un souvenir lointain).

Un serveur DNS ne consomme rien et permet d’avoir une très grande souplesse sur le domaine que tu gères, l’activité machine et réseau correspondante est limitée. Je trouve que ça vaut le cout. Un intérêt consiste également en la notion de «view» qui te permet de limiter la connaissance de certaines machines à des machines spécifiques par exemple aux machines du domaine elles même. Les extérieurs ne voient que ns.tondomaine.fr et serveur.tondomaine.fr, par contre ceux d’un réseau donnée voient en plus machine.tondomaine.fr et secret.tondomaine.fr (note que c’est léger comme protection mais bon…)

#4

fran.b,
je ne partage pas ton optimisme sur l’intérêt d’avoir son propre serveur DNS.
Sur ce forum, très récement, un utilisateur avait sur service quasiment bloqué suite à un nombre très important d’accés à son serveur DNS.

#5

Ce serveur était-il bien configuré? En général cela arrive quand il autorise la récursion aux demandes externes. Je gère deux domaines sur deux DNS (secondaire l’un de l’autre) qui en outre servent de DNS au LAN local, et ce depuis plusieurs années. Mon petit serveur a certes eu des périodes chaudes mais systématiquement dues au serveur de courrier. Si on refuse la récursion à l’extérieur, les requêtes sont très rapides et peu couteuses.

Ainsi en trafic, sur 3 semaines, pour comparer:

NTP: 338M (je suis dans le pool NTP)
Web: 8G
DNS: 62M

Trafic total: 11,4G

Le DNS est vraiment minime. La charge CPU est négligeable.

#6

Nous sommes donc d’accord, le serveur DNS “privé” doit étre réservé aux demandes venant du LAN. Il ne doit pas être visible du WEB.
Pour un serveur chez OVF, pas d’intérêt autre que didactique.
Pour cet usage, il y a les DNS des FAI, de google, et d’autres société qui vivent grace à la publicité (à déconseillé!)

#7

Non tu n’as pas compris, le serveur répond aux requêtes extérieures sur le domaine qu’il gère mais refuse de répondre aux requêtes sur d’autres domaines venant de l’extérieur (il refuse la récursion). Du LAN il accepte tout.

En clair du LAN tu as tout sur l’extérieur et tout sur le domaine géré.

De l’extérieur tu n’as que la partie visible du domaine géré.

Si tu as un domaine et un serveur chez OVH, il peut être extrèmement intéressant de faire un DNS sur ce serveur et ce à faible cout.

Dans le fil auquel tu fais référence, il s’agit visiblement d’un serveur DNS ouvert et qui permet éventuellement de servir de relais pour attaquer d’autres machines (cf http://www.bortzmeyer.org/fermer-les-recursifs-ouverts.html). Même dans ce cas (déconseillé, pour le coup je ne vois pas quel intérêt a-t-on de faire un DNS ouvert), on peut limiter le trafic, voir http://www.bortzmeyer.org/rate-limiting-dns-open-resolver.html pour cela par exemple.

Je te le répète, mon serveur gère 2 domaines et son trafic représente 1/6 du trafic généré par le NTP par exemple et 1/200000 du trafic total: une broutille!

#8

On peut voter pour ou contre une réponse ou bien pour ou contre un utilisateur sur debian-fr ? Car “piratebab” a enfilé une impressionnante série d’erreurs et d’énormités. Il faut absolument ignorer tout ce qu’il raconte.

OVH transmet au registre de .FR (l’AFNIC) la liste des serveurs de noms du domaine. Prenons un exemple réel, botnets.fr. La commande dig nous montre ce que connait l’AFNIC :

% dig @d.nic.fr NS botnets.fr
...
botnets.fr.             172800  IN      NS      ns20.ovh.net.
botnets.fr.             172800  IN      NS      dns20.ovh.net.

Le mécanisme de résolution est 1) On demande à la racine (qui renvoie vers l’AFNIC) 2) On demande à l’AFNIC (qui renvoie vers les serveurs indiqués dans sa base) 3) On demande à ces serveurs. OVH n’est pas forcément impliqué (si on a ses propres serveurs faisant autorité).

Le résultat de ces requêtes est gardé en mémoire par le serveur DNS récursif (le résolveur) pour éviter d’embêter la racine, l’AFNIC et les autres à chaque fois.

[Voir aussi la réponse (correcte) de fran.b.]

Non, les serveurs esclaves (secondaires) participent eux aussi à la résolution, que le maître soit down ou pas.

Les serveurs de l’AFNIC ne gardent pas la zone exemple.fr en cache et pour une excellente raison, ils ne la connaissent pas !

Non, on peut mettre des valeurs plus grandes (exemple : le TTL utilisé par l’AFNIC est de 172800 secondes).

Abaisser les TTL avant un changement est en effet La Bonne Pratique http://www.bortzmeyer.org/changement-adresse-et-dns.html

Et le terme de propagation est erroné http://www.bortzmeyer.org/dns-propagation.html

Normalement, oui, le serveur esclave reviendra toutes les cinq secondes. Maintenant, OVH, qui a beaucoup de clients dont une certaine proportion de maladroits ou de méchants, a peut-être mis une durée minimale à ces paramètres (ou bien ils le détectent et arrêtent le service de secondaire et vident le client à coup de pompes dans le cul ce que je ferais à leur place).

En effet, uniquement les serveurs faisant autorité (maître(s) et esclave(s)).

Oui, c’est récupérable, c’est du DNS, après tout.

% dig SOA botnets.fr
...
botnets.fr.             86400   IN      SOA     dns20.ovh.net. tech.ovh.net. 2012052701 86400 3600 3600000 86400

Je peux maintenant écrire à tech(at) ovh.net :slightly_smiling:

Si on écrit n’importe quoi, on ne sera pas contactable en cas de problème. Des tas de zones DNS sont ainsi défaillantes depuis des années parce que l’aministrateur a pris soin de ne pas se rendre contactable.

#9

Tu peux toujours l’ignorer si ce Schnauzer ne te plait pas :laughing:

#10

@bortzmeyer : pas utile de poster 36.000 messages à la file, tout dans un seul message aurait été aussi clair.

#11

Pas d’accord. La question originale était très riche et complexe, j’essaie d’aérer les résultats.

Je craignais surtout que des gens ne connaissant pas le DNS prennent ses messages pour agent comptant et repartent donc avec des idées fausses.

#12

C’est qu’il ne fait pas la différence entre messages & posts :laughing:

#13

Tu peux ne pas être d’accord, ça sera tout autant aéré en un seul message si tu prends la peine de mettre en forme. Mais vu que tu sembles vouloir continuer, poste autant que tu veux je t’en prie, c’est pas grave je repasserai derrière. :unamused:

Edit : fait.

#14

Hum, tu as une personne particulièrement compétente qui vient de répondre. Laisse tomber l’histoire de la forme, ça n’est pas bien grave. Si Stéphane Bortzmeyer fréquente le forum, alors les questions sur les DNS et tout plein d’autres choses (dont la politique des listes noires, les explications sur les RFC, etc) auront des réponses claires et précises.

Bienvenu donc Stéphane.

#15

Désolé de ne pas connaître ce monsieur, quand je vois 10 messages postés à la file en quelques minutes dans un même sujet j’ai le réflexe de nettoyer, c’est tout. :wink:

#16

Regarde les liens que j’ai donné et parcourt le blog, tu verras tout plein d’articles. Je crois que c’est lui qui m’avait fourni à l’époque les documents suivants:
http://boisson.homeip.net/Blacklists_Resultats.pdf et http://boisson.homeip.net/Blacklists_FAQ.pdf. Il me semble aussi que c’est sur son blog que j’ai découvert l’existence des «view».

#17

Bienvenue Stéphane, je vais pouvoir me reposer maintenant concernant les questions DNS.
(Non, mes messages ne sont pas tous utiles)

#18

Merci à tous pour vos réponses !
Et particulièrement à Stéphane Bortzmeyer qui me fait le privilège de me répondre (sacré surprise).
Et aussi à PascalHambourg qui a l’habitude répondre sur ce sujet, j’avoue que j’attendais aussi son intervention. :wink:

Bref, je vais digérer toutes ces réponses histoire de bien les comprendre et les assimiler et (si vous le voulez bien) je reviendrai à la charge dans ce topic (j’ose espérer qu’il ne faut pas ouvrir un nouveau thread pour ça :shifty: ).

Après relecture rapide, voici :

Question 1 : OK, j’ai bien pigé.

Question 2 : Là un truc m’échappe.
Vous dites :

Et juste après :

Mais le TTL c’est pas du cache ?

Question 3 : Je ne comprend toujours pas la différence entre le TTL avec un dollar au début et celui plus bas…
Laissez moi deviner : Celui avec le dollar c’est pour les récursifs, et celui plus bas pour les secondaires ?

Ok pour dire que la propagation est un abus de langage, mais alors : lorsque mon dédié va changer d’IP même avec un TTL à 0 il y aura toujours le problème de : “il faut maintenant attendre la réjuvénation” ou pas ? Sachant que les DNS des FAI vont sans doute pas “rejuvéner” tout seul…non ?

Question 4 5 6: OK je m’en doutais. Merci de me confirmer. :slightly_smiling:

Merci vraiment à tous pour vos réponses. C’est sincère. :bow-yellow:

#19

Salut,

[quote=“fran.b”]Hum, tu as une personne particulièrement compétente qui vient de répondre. Laisse tomber l’histoire de la forme, ça n’est pas bien grave. Si Stéphane Bortzmeyer fréquente le forum, alors les questions sur les DNS et tout plein d’autres choses (dont la politique des listes noires, les explications sur les RFC, etc) auront des réponses claires et précises.

Bienvenu donc Stéphane.[/quote]

C’est un blog que j’ai grand plaisir à suivre, (depuis 2 ans environ) j’y apprend énormément, certes je ne saisi pas “toujours” toutes les subtilités et le côté sombre du réseau … :083

Pascal est passé par là d’ailleurs, je ne sais plus quel était l’article …

Une pointure de plus sur debian-fr … ?

Bienvenu Stéphane! :wink:

#20

Je suppose que Stéphane parlait du TTL initial des enregistrements de la zone “fr” gérée par les serveurs DNS de l’Afnic qui est de 172800 secondes (soit 2 jours) comme on peut le constater avec quelques requêtes. Le TTL sert aux serveurs caches pour l’expiration des enregistrements reçus. Une fois stocké dans un cache, le TTL décroît et lorsqu’il atteint zéro l’enregistrement est effacé (il expire).

Question 3 :
Non, rien à voir. Dans un fichier de zone, on peut spécifier un TTL pour tout enregistrement. S’il est omis, alors le TTL par défaut défini par $TTL est appliqué à l’enregistrement.

Comme l’a écrit Stéphane les enregistrements DNS ne se propagent pas, ils expirent des caches lorsque leur TTL atteint zéro. Et quand un client demande un enregistrement qui a expiré à un serveur cache récursif, ce dernier le demande à nouveau (à un serveur faisant autorité ou un autre serveur récursif) et recevra la nouvelle valeur si celle-ci a changé entretemps.