Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fonctionnement d'un DNS. Et pourquoi 2 NS ?

5 views
Skip to first unread message

Olivier Masson

unread,
Mar 17, 2008, 8:42:13 AM3/17/08
to
Bonjour,

J'ai quelques questions auxquelles je ne trouve pas de réponses claires.

Si je modifie les entrées DNS (je crée un CNAME, un A,...) de mon
serveur, comment indique-t-on à quels autres DNS sont transmis ces infos
en premier lieu (qui lui-même distribuera l'info) ?

Pourquoi me ferait-il confiance ?

Pourquoi faut-il toujours entrer au moins 2 NS ? Uniquement pour la
redondance ?

Donc dans mon cas, j'ai un seul serveur : est-ce que je peux mettre mon
IP en premier NS et un DNS de mon hébergeur en second ?

Merci.
PS : Nessus m'indique que "Remote DNS server is vulnerable to cache
snooping attacks". J'ai souvent obtenu des faux positifs dans la sécu
réseau avec cet outil, mais là, comme je ne comprends pas ce qu'il me
dit... est-ce grave et comment y remédier ?

nicolas vigier

unread,
Mar 17, 2008, 9:08:37 AM3/17/08
to
On 2008-03-17, Olivier Masson <sis...@laposte.net> wrote:
> Bonjour,
>
> J'ai quelques questions auxquelles je ne trouve pas de réponses claires.
>
> Si je modifie les entrées DNS (je crée un CNAME, un A,...) de mon
> serveur, comment indique-t-on à quels autres DNS sont transmis ces infos
> en premier lieu (qui lui-même distribuera l'info) ?

Dans la conf de ton serveur dns.

> Pourquoi me ferait-il confiance ?

Par ce qu'on le configure pour.

> Pourquoi faut-il toujours entrer au moins 2 NS ? Uniquement pour la
> redondance ?

Oui, pour la redondance.

> Donc dans mon cas, j'ai un seul serveur : est-ce que je peux mettre mon
> IP en premier NS et un DNS de mon hébergeur en second ?

Oui, si il y a des dns configurés correctement sur ces 2 machines.

Patrick Mevzek

unread,
Mar 17, 2008, 9:26:57 AM3/17/08
to
Le Mon, 17 Mar 2008 13:42:13 +0100, Olivier Masson a écrit:
> Si je modifie les entrées DNS (je crée un CNAME, un A,...) de mon
> serveur, comment indique-t-on à quels autres DNS sont transmis ces infos
> en premier lieu (qui lui-même distribuera l'info) ?

Les modifications doivent se faire sur le serveur DNS primaire (maître) et
il va alors notifier les autres serveurs DNS, tels que présents dans la
zone (ou si on le force à contacter d'autres serveurs).



> Pourquoi me ferait-il confiance ?

Vous parlez des DNS secondaires ? Il y a 20 ans, tout le monde faisait
confiance à tout le monde sur Internet et cela se passait très bien...
c'est le modèle encore qui reste ancré et on ajoute des couches au-dessus
pour « sécuriser » tout ca. Vous pouvez configurer les serveurs pour
n'autoriser les transfers de zone (AXFR/IXFR, le mécanisme utilisé pour la
synchronisation lorsque le primaire est modifié), que depuis/vers
certaines adresses IP, ou un cran au-dessus en utilisant une clef
cryptographique avec le mécanisme TSIG des DNS qui fera que seules les
machines ayant la clef auront le droit de récupérer la nouvelle zone sur
le primaire.

Mais sinon le problème général de la confiance est encore plus large que
cela : comment avoir confiance dans les résultats que me renvoient mon
résolveur local, est-ce bien le contenu de la zone questionnée ? D'où
l'invention de DNSSEC encore largement sous-déployé à la fois pour des
problèmes techniques résolus il n'y a pas très longtemps, et des problèmes
politiques (qui signe la racine ?)

> Pourquoi faut-il toujours entrer au moins 2 NS ? Uniquement pour la
> redondance ?

Oui, mais plus précisément c'est aussi de la répartition de charge,
contraitement à une bêtise colportée fréquemment, tous les serveurs de
noms d'une zone sont interrogés équitablement en permanence et se partage
donc à tout instant l'ensemble du trafic DNS pour la zone. Et les
résolveurs, s'ils n'obtiennent pas de réponse de l'un, vont en interroger
un autre, la redondance est là.

> Donc dans mon cas, j'ai un seul serveur : est-ce que je peux mettre mon
> IP en premier NS et un DNS de mon hébergeur en second ?

Si le serveur DNS de ce dernier est configuré correctement pour être
secondaire de votre zone et se synchroniser sur celle-ci, alors oui. Mais
il vaut mieux régler cela avant que de mettre le serveur DNS en question
dans votre zone. Voir aussi du côté du bureau d'enregistrement du nom de
domaine en question, beaucoup de bureaux proposent un service de DNS
secondaire.

> PS : Nessus m'indique que "Remote DNS server is vulnerable to cache
> snooping attacks".

C'est une ancienne version (de Bind je suppose) qu'il faudra mettre à
jour, j'imagine. Cela peut arriver aussi si vous avez la mauvaise idée
d'utiliser le même serveur DNS comme serveur autoritaire sur une zone et
résolveur local accessible publiquement.
Il faut :
- ne pas avoir le même DNS qui a deux rôles différents, aux
problématiques très différentes,
- ne pas avoir de résolveur local accessible publiquement, cela n'a pas de
sens (sauf « services » comme OpenDNS), c'est comme un serveur SMTP relai
ouvert, c'est potentiellement très dangereux.

--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>

Manuel Guesdon

unread,
Mar 17, 2008, 9:27:15 AM3/17/08
to
Bonjour,

On Mon, 17 Mar 2008 13:42:13 +0100, Olivier Masson wrote:
> J'ai quelques questions auxquelles je ne trouve pas de réponses claires.

Toutes les réponses sont probablement ici:
http://www.oreilly.fr/catalogue/2841771504.html


> Si je modifie les entrées DNS (je crée un CNAME, un A,...) de mon
> serveur, comment indique-t-on à quels autres DNS sont transmis ces infos
> en premier lieu

Si ma mémoire est bonne, via les entrées IN NS de la zone qui lui sert a
trouver les dns slaves


> (qui lui-même distribuera l'info) ?

Le dns master et les slaves ne redistribuerons pas: ils attendrons
gentiments les requetes.

> Pourquoi me ferait-il confiance ?

Le 'systeme' fait confiance aux serveurs dns indiqués comme ns de ton
domaine.

> Pourquoi faut-il toujours entrer au moins 2 NS ? Uniquement pour la
> redondance ?

Oui. Et sans doute pour satisfaire une rfc.


> Donc dans mon cas, j'ai un seul serveur : est-ce que je peux mettre mon
> IP en premier NS et un DNS de mon hébergeur en second ?

En gros oui, pourvu que le dns de ton hébergeur soit configuré pour géré
la zone.


> PS : Nessus m'indique que "Remote DNS server is vulnerable to cache
> snooping attacks". J'ai souvent obtenu des faux positifs dans la sécu
> réseau avec cet outil, mais là, comme je ne comprends pas ce qu'il me
> dit...

http://www.google.fr/search?q=Remote+DNS+server+is+vulnerable+to+cache%
0Asnooping+attacks

=> https://my.controlscan.com/threats/details.cgi?id=12217


> est-ce grave et comment y remédier ?

MAJ ?

Manuel

Olivier Masson

unread,
Mar 17, 2008, 11:24:16 AM3/17/08
to
Manuel Guesdon a écrit :

> Bonjour,
>
> On Mon, 17 Mar 2008 13:42:13 +0100, Olivier Masson wrote:
>> J'ai quelques questions auxquelles je ne trouve pas de réponses claires.
>
> Toutes les réponses sont probablement ici:
> http://www.oreilly.fr/catalogue/2841771504.html

Plutôt http://www.oreilly.fr/catalogue/2841774090 ;)

Olivier Masson

unread,
Mar 17, 2008, 11:35:36 AM3/17/08
to
Patrick Mevzek a écrit :

> Les modifications doivent se faire sur le serveur DNS primaire (maître) et
> il va alors notifier les autres serveurs DNS, tels que présents dans la
> zone (ou si on le force à contacter d'autres serveurs).
>

Ok.


> Vous parlez des DNS secondaires ? Il y a 20 ans, tout le monde faisait
> confiance à tout le monde sur Internet et cela se passait très bien...
> c'est le modèle encore qui reste ancré et on ajoute des couches au-dessus
> pour « sécuriser » tout ca. Vous pouvez configurer les serveurs pour
> n'autoriser les transfers de zone (AXFR/IXFR, le mécanisme utilisé pour la
> synchronisation lorsque le primaire est modifié), que depuis/vers
> certaines adresses IP, ou un cran au-dessus en utilisant une clef
> cryptographique avec le mécanisme TSIG des DNS qui fera que seules les
> machines ayant la clef auront le droit de récupérer la nouvelle zone sur
> le primaire.
>

Là, ça devient compliqué. Soit je m'achète le bouquin de O'Reilly, soit
je délègue tout à mon registrar (ce se sera plus laborieux mais plus sûr !)

>
>> Donc dans mon cas, j'ai un seul serveur : est-ce que je peux mettre mon
>> IP en premier NS et un DNS de mon hébergeur en second ?
>
> Si le serveur DNS de ce dernier est configuré correctement pour être
> secondaire de votre zone et se synchroniser sur celle-ci, alors oui. Mais
> il vaut mieux régler cela avant que de mettre le serveur DNS en question
> dans votre zone. Voir aussi du côté du bureau d'enregistrement du nom de
> domaine en question, beaucoup de bureaux proposent un service de DNS
> secondaire.

Et comment savoir si le DNS de mon registrar est bien "configuré
correctement pour être secondaire de [ma] zone" ?

>
>> PS : Nessus m'indique que "Remote DNS server is vulnerable to cache
>> snooping attacks".
>
> C'est une ancienne version (de Bind je suppose) qu'il faudra mettre à
> jour, j'imagine. Cela peut arriver aussi si vous avez la mauvaise idée
> d'utiliser le même serveur DNS comme serveur autoritaire sur une zone et
> résolveur local accessible publiquement.
> Il faut :
> - ne pas avoir le même DNS qui a deux rôles différents, aux
> problématiques très différentes,
> - ne pas avoir de résolveur local accessible publiquement, cela n'a pas de
> sens (sauf « services » comme OpenDNS), c'est comme un serveur SMTP relai
> ouvert, c'est potentiellement très dangereux.
>

Soit c'est un faux positif (car mon Bind est à jour), soit je rentre
dans un des cas que vous citez... mais sans le savoir :/

Comme toujours, merci pour vos explications (même si ça me déprime
toujours un peu).

Patrick Mevzek

unread,
Mar 17, 2008, 12:19:05 PM3/17/08
to
Le Mon, 17 Mar 2008 16:35:36 +0100, Olivier Masson a écrit:
> Là, ça devient compliqué. Soit je m'achète le bouquin de O'Reilly, soit
> je délègue tout à mon registrar (ce se sera plus laborieux mais plus sûr !)

La question « est-ce que mon serveur doit accepter les AXFR vers partout
» est source perpétuelle de débats politiques.

Si on reste sur les aspects techniques, pour une zone « pas trop
importante » (en terme d'importance économique pas de taille), ce genre de
réglage devrait être suffisant :

- sur le primaire :
allow-transfer { 127.0.0.1; };
en remplacant 127.0.0.1 par l'adresse IP du secondaire
Elle n'est pas obligatoire cette ligne : avec, votre serveur ne donnera le
contenu intégral de la zone (AXFR) ou les mises à jours incrémentielles
(IXFR) qu'au serveur à l'IP spécifié, le secondaire. Sans la ligne, tout
serveur demandant la zone l'aura, le secondaire aussi donc.
Il faudra penser à la mettre à jour si le secondaire bouge.
- sur le secondaire :
les options par défaut d'un BIND devrait faire l'affaire car c'est du «
pull », le secondaire se connecte au primaire pour récupérer les
informations de la zone (même si ce dernier peut avertir ses secondaires
afin d'accélérer la convergence), donc il se connecte automatiquement sur
la « bonne » IP.

Après bien sûr comme dit précédemment il y a des pistes pour sécuriser
l'ensemble.

>>> Donc dans mon cas, j'ai un seul serveur : est-ce que je peux mettre
>>> mon IP en premier NS et un DNS de mon hébergeur en second ?
>>
>> Si le serveur DNS de ce dernier est configuré correctement pour être
>> secondaire de votre zone et se synchroniser sur celle-ci, alors oui.
>> Mais il vaut mieux régler cela avant que de mettre le serveur DNS en
>> question dans votre zone. Voir aussi du côté du bureau d'enregistrement
>> du nom de domaine en question, beaucoup de bureaux proposent un service
>> de DNS secondaire.
>
> Et comment savoir si le DNS de mon registrar est bien "configuré
> correctement pour être secondaire de [ma] zone" ?

Cela dépend un peu du service offert... et de la configuration du
primaire.
Le problème se pose surtout pour une zone déjà existante, et que vous
voudriez éviter de casser.
Soit le prestataire ne demande comme configuration que le nom de domaine,
et son serveur DNS va en récupérer les enregistrements NS, regarder si son
propre serveur est référencé (donc service DNS secondaire à fournir),
demander au primaire la zone (AXFR/IXFR), et à partir de là tout
fonctionne.
Soit le prestataire va demander l'adresse IP (ou le nom) du serveur
primaire, le contacter pour récupérer la zone (qu'il soit dans les
enregistrements NS ou pas), et se configurer.

La première solution a l'avantage de ne rien coder en dur (en particulier
le nom/adresse IP du primaire, qui peut changer), mais l'inconvénient
qu'il peut y avoir un laps de temps entre le moment où vous ajoutez le
serveur du prestataire dans les NS et où ce dernier se configure, laps de
temps où un tiers peut contacter le serveur DNS du prestataire (puisqu'il
est dans les NS de la zone), et où ce dernier, non encore configuré/ne
disposant pas encore du contenu de la zone, pourra répondre : je ne
connais pas ce domaine, ce qui peut causer donc des erreurs, certes
temporaire.

La deuxième solution résout ce problème car le serveur DNS du prestataire
peut se configurer (synchroniser le contenu de la zone) même avant d'être
présent dans les enregistrements NS de la zone (l'ajout à la liste des NS
pourrait arriver donc dans un deuxième temps).

Dans la première solution, il n'y a pas vraiment moyen de tester avant de
faire le changement.
Dans la deuxième solution on peut tester à tout moment.

Pour les tests, je recommande dig en ligne de commande :
dig @NS example.com SOA
en remplacant NS par l'adresse IP (ou le nom) du serveur DNS que l'on veut
interroger (donc a priori celui du prestataire qui fournira le DNS
secondaire),
example.com par votre nom de domaine
et SOA qui ne renverra rien comme réponse si example.com n'est pas connu
sur le serveur en question et sinon l'en-tête SOA avec notamment dedans
le « serial » et en vérifiant qu'il y a bien « aa » dans la partie flags
(les toutes premières lignes de sortie, le aa signifiant que c'est une
réponse avec autorité c'est à dire un serveur du domaine et pas une
requête récursive)
ou utiliser NS à la place de SOA pour directement récupérer les
serveurs de noms (enregistrements NS) du domaine example.com *d'après* le
serveur dont on aura mis le nom/l'ip d'ailleurs le @

On peut aussi utiliser des outils plus « haut » niveau, comme
zonecheck/dnsdoctor (ligne de commande, ou interface web) ou d'autres, mais
je ne les recommande pas personnellement.


>>> PS : Nessus m'indique que "Remote DNS server is vulnerable to cache
>>> snooping attacks".
>>
>> C'est une ancienne version (de Bind je suppose) qu'il faudra mettre à
>> jour, j'imagine. Cela peut arriver aussi si vous avez la mauvaise idée
>> d'utiliser le même serveur DNS comme serveur autoritaire sur une zone
>> et résolveur local accessible publiquement. Il faut : - ne pas avoir le
>> même DNS qui a deux rôles différents, aux problématiques très
>> différentes,
>> - ne pas avoir de résolveur local accessible publiquement, cela n'a pas
>> de sens (sauf « services » comme OpenDNS), c'est comme un serveur SMTP
>> relai ouvert, c'est potentiellement très dangereux.
>>
>>
> Soit c'est un faux positif (car mon Bind est à jour), soit je rentre
> dans un des cas que vous citez... mais sans le savoir :/

Sur une autre machine que votre serveur, faites :
dig @votreserveur google.fr A
(en remplacant votreserveur par son nom ou IP)
si vous avez une réponse c'est a priori que votre serveur est serveur DNS
récursif ouvert, le cas à éviter (si on ne peut pas physiquement séparer
DNS autoritaire et DNS récursif sur la même machine, on peut au moins
configurer bind avec les « view » pour n'exposer la partie DNS récursif
qu'en local de la machine et pas à l'extérieur)

Ou donnez son petit nom ici on testera :-)

> Comme toujours, merci pour vos explications (même si ça me déprime
> toujours un peu).

Désolé (à la Denisot) mais bon courage.

Manuel Guesdon

unread,
Mar 17, 2008, 3:02:47 PM3/17/08
to
On Mon, 17 Mar 2008 16:35:36 +0100, Olivier Masson wrote:
> Là, ça devient compliqué. Soit je m'achète le bouquin de O'Reilly, soit
> je délègue tout à mon registrar (ce se sera plus laborieux mais plus sûr
> !)

C'est toujours la même problématique: soit je confie ma voiture au
garagiste, soit j'étudie "Réparer sa voiture pour les nuls" :-)

> Et comment savoir si le DNS de mon registrar est bien "configuré
> correctement pour être secondaire de [ma] zone" ?

Par defaut il a peu de chance de l'être. Mai peut etre qu'indiquer un ns
bien particulier indiqué par le registrar enclenchent les mécanismes qui
vont bien derriere... Bfre a verifier avec le registrar et/ou son
interface.

Manuel

Olivier Masson

unread,
Mar 19, 2008, 5:56:56 AM3/19/08
to
Patrick Mevzek a écrit :

> - sur le primaire :
> allow-transfer { 127.0.0.1; };
> en remplacant 127.0.0.1 par l'adresse IP du secondaire
> Elle n'est pas obligatoire cette ligne : avec, votre serveur ne donnera le
> contenu intégral de la zone (AXFR) ou les mises à jours incrémentielles
> (IXFR) qu'au serveur à l'IP spécifié, le secondaire. Sans la ligne, tout
> serveur demandant la zone l'aura, le secondaire aussi donc.
> Il faudra penser à la mettre à jour si le secondaire bouge.
> - sur le secondaire :
> les options par défaut d'un BIND devrait faire l'affaire car c'est du «
> pull », le secondaire se connecte au primaire pour récupérer les
> informations de la zone (même si ce dernier peut avertir ses secondaires
> afin d'accélérer la convergence), donc il se connecte automatiquement sur
> la « bonne » IP.
>

Bon, j'ai essayé de comprendre, action qui n'est pas toujours couronnée
de succès :)

Pour résumer mes modifs (mon but étant de faire passer les mises à jour
de mon DNS à ceux de Gandi) :

- dans resolv.conf, j'ai mis mon IP en premier et les deux IP des DNS
gandi (le bout de serveur est chez eux) en second ensuite. Je ne sais
pas si mon IP est utile puisque c'est résolu d'abord hosts mais je ne
sais pas s'il y a un lien avec dns primaire et secondaire (comme je le
lis un peu partout.)

- dans named.conf, j'ai :

acl dns_gandi { 217.70.184.225; 217.70.184.226; };

options {
pid-file "/var/run/bind/run/named.pid";
directory "/etc/bind";
auth-nxdomain no;

//forwarders { dns_gandi; }; # acl marche pas ici et je n'ai
pas tout compris à son utilité

allow-transfer { dns_gandi; };
allow-recursion { localhost; dns_gandi; };
};

view "externe" {
match-clients { any; };
recursion no;
};

view "interne" {
match-clients { localhost; };
recursion yes;
};
...

- dans named.conf (enfin, la syntaxe dans le script dynamique) :
<!-- BEGIN DYNAMIC BLOCK: named -->
zone "{DOMAIN}" {
type master;
notify yes;
file "pri.{DOMAIN}";
};
<!-- END DYNAMIC BLOCK: named -->

<!-- BEGIN DYNAMIC BLOCK: named_reverse -->
zone "{ZONE}.in-addr.arpa" {
type master;
file "pri.{ZONE}.in-addr.arpa";
};
<!-- END DYNAMIC BLOCK: named_reverse -->


Pour mes zones, mon panel génère ça :
$TTL 86400
@ IN SOA www.monserveur.net. admin.mondomaine1.net. (
2008031001
28800
7200
604800
86400 )

MX 10 www.mondomaine1.net.

mondomaine1.net. A 9x.2xx.xx.xx
www A 9x.2xx.xx.xx

mondomaine1.net. TXT "v=spf1 a mx ptr ~all"

Outre le TXT dont je ne comprend pas l'utilité, j'ai du mal avec
l'utilisation du @, le TTL à 86400, l'absence de IN.

> Après bien sûr comme dit précédemment il y a des pistes pour sécuriser
> l'ensemble.

J'ai vu que j'avais dnssec-keygen et -seczone, mais j'attendrai déjà
d'avoir bien configuré le reste...


> Cela dépend un peu du service offert... et de la configuration du
> primaire.
> Le problème se pose surtout pour une zone déjà existante, et que vous
> voudriez éviter de casser.
> Soit le prestataire ne demande comme configuration que le nom de domaine,
> et son serveur DNS va en récupérer les enregistrements NS, regarder si son
> propre serveur est référencé (donc service DNS secondaire à fournir),
> demander au primaire la zone (AXFR/IXFR), et à partir de là tout
> fonctionne.
> Soit le prestataire va demander l'adresse IP (ou le nom) du serveur
> primaire, le contacter pour récupérer la zone (qu'il soit dans les
> enregistrements NS ou pas), et se configurer.
>

Avec ma config (en supposant qu'elle soit bonne...), je suis dans quelle
situation ?


> Pour les tests, je recommande dig en ligne de commande :
> dig @NS example.com SOA
> en remplacant NS par l'adresse IP (ou le nom) du serveur DNS que l'on veut

Je me fais jeter partout pour cause de "recursion requested but not
available".

> On peut aussi utiliser des outils plus « haut » niveau, comme
> zonecheck/dnsdoctor (ligne de commande, ou interface web) ou d'autres, mais
> je ne les recommande pas personnellement.
>
>

J'ai testé dlint sur un domaine que j'héberge ailleurs, j'ai pris peur :
il m'a affiché 4 warnings et 6 errors...

> Sur une autre machine que votre serveur, faites :
> dig @votreserveur google.fr A

Ca c'est ok, même Nessus est content.

>
> Ou donnez son petit nom ici on testera :-)

Comme vous le disiez très justement, avant tout le monde se faisait
confiance sur le net. D'ailleurs, avant je postais sous mon vrai nom et
puis dejanews est arrivé, les script kiddies, ceux qui pensent avoir la
juste parole, etc.

Pour limiter les risques, est-il possible d'envoyer toutes les mises à
jour aux DNS Gandi, sans pouvoir être interrogé par qui que ce soit
d'autre (que les DNS Gandi) ?

Et puis merci, comme toujours (y'a pas de bouton Donate sur dotandco ;))

Olivier Masson

unread,
Mar 19, 2008, 9:47:09 AM3/19/08
to
Manuel Guesdon a écrit :

>
> C'est toujours la même problématique: soit je confie ma voiture au
> garagiste, soit j'étudie "Réparer sa voiture pour les nuls" :-)
>

On peut très bien la confier à son garagiste en ayant pris soin de lire
un bon bouquin sur la mécanique :)

Patrick Mevzek

unread,
Mar 19, 2008, 11:23:58 AM3/19/08
to
Le Wed, 19 Mar 2008 10:56:56 +0100, Olivier Masson a écrit:
> Pour résumer mes modifs (mon but étant de faire passer les mises à jour
> de mon DNS à ceux de Gandi) :
>
> - dans resolv.conf, j'ai mis mon IP en premier et les deux IP des DNS
> gandi (le bout de serveur est chez eux) en second ensuite.

A priori non. Votre resolv.conf indique juste à votre machine en local
quels sont les serveurs DNS (récursifs) qu'elle peut interroger. Si vous
avez un DNS récursif en local alors mettre l'IP locale/127.0.0.1 est une
bonne chose, mais après derrière c'est a priori les adresses IP des
serveurs DNS de votre FAI, qui ont le rôle de DNS récursif et répondront
aux requêtes de votre domaine. Je doute que les DNS de votre prestataire
soient récursifs (en tout cas j'espère que non, sinon bonjour le problème,
cf échanges précédents), donc il ne faudra(it) pas mettre leur IP ici.

> //forwarders { dns_gandi; }; # acl marche pas ici et je n'ai
> pas tout compris à son utilité

A priori vous n'avez pas besoin de cette directive. C'est si on veut «
forcer » la propagation dans un sens particulier, ce n'est pas nécessaire
pour une architecture simple primaire/secondaire



> allow-transfer { dns_gandi; };
> allow-recursion { localhost; dns_gandi; };

A priori seule votre machine locale a besoin de la récursion, personne
d'autre.

> Pour mes zones, mon panel génère ça :
> $TTL 86400
> @ IN SOA
> www.monserveur.net. admin.mondomaine1.net. (
> 2008031001
> 28800
> 7200
> 604800
> 86400 )
>
> MX 10 www.mondomaine1.net.
>
> mondomaine1.net. A 9x.2xx.xx.xx
> www A 9x.2xx.xx.xx
>
> mondomaine1.net. TXT "v=spf1 a mx ptr ~all"

Euh... il manque quand même les enregistrements NS là, sans ca va beaucoup
moins bien marcher.
D'après le SOA vous dites que www.monserveur.net est le primaire de votre
zone, il devra être dans un NS, ainsi que le ou les secondaires.

> Outre le TXT dont je ne comprend pas l'utilité,

C'est un peu un fourre-tout, là vous l'utilisez pour SPF, une technologie
s'appliquant au mail et visant, selon à qui vous demandez, à vérifier
l'authenticité de l'émetteur du mail ou à casser le relayage.
En résumé, si ce n'était pas votre intention spécifique, enlever le, vous
pourrez toujours vous plongez dans SPF plus tard, ca n'impacte que le mail
pas les DNS.

> j'ai du mal avec l'utilisation du @,

Le @ est un raccourci pour dire « la zone courante » c'est à dire celle
décrite par le fichier en question, donc mondomaine1.net dans votre cas.
C'est un raccourci qui permet d'utiliser le même « fichier de zone » pour
différentes zones.

> le TTL à 86400,

Chaque enregistrement peut avoir un TTL qui se met devant le IN.
S'il n'y en a pas c'est la valeur par défaut exprimée par le $TTL, en
secondes, donc 24h ici (à noter qu'on peut écrire $TTL 24H au lieu de $TTL
86400)

Cela n'a pas de traduction immédiate sur le temps de « propagation », car
un serveur récursif quelconque qui fait une demande à votre serveur (le
primaire ou un secondaire peut importe) récupère l'enregistrement qui
l'intéresse, plus le TTL, donc 86400 ici. Ce serveur DNS récursif tiers,
en théorie, garde donc dans sa mémoire la réponse recue pendant le délai
exprimé par le TTL, et n'interrogera pas de nouveau vos serveurs. Ainsi si
l'enregistrement en question, mettons que ce soit un A, change d'adresse
IP, le serveur tiers ne verra pas le changement tant que le délai du TTL
n'est pas passé. Cela peut être avant cependant s'il est redémarré (perte
du cache a priori), si le cache est plein (d'où destruction d'une partie
pour faire de la place), si on le force à la main à supprimer cet
enregistrement, s'il est configuré pour ne pas honorer les TTL recus
(certains FAIs semblent faire cela), etc.

Vous trouverez des recommandations quant à sa valeur et aux autres dans le
SOA par exemple ici en anglais : http://www.ripe.net/ripe/docs/dns-soa.html

> l'absence de IN.

Ah oui, ca c'est une erreur, même s'il est très rare d'utiliser
les DNS pour d'autres familles d'enregistrement.

>> Après bien sûr comme dit précédemment il y a des pistes pour sécuriser
>> l'ensemble.
>
> J'ai vu que j'avais dnssec-keygen et -seczone, mais j'attendrai déjà
> d'avoir bien configuré le reste...

Vous pouvez effectivement utiliser dnssec-keygen pour créer une clef à
utiliser par le mécanisme TSIG qui, en résumé, « sécurise » le transfert
de zone (entre primaire et secondaires) en authentifiant fortement
l'émetteur (le primaire). Cela remplace ou s'adjoint aux ACLs sur les
adresses IP.
Par contre pour dnssec-seczone, là c'est vraiment pour faire du DNSSEC, et
c'est encore tout un monde à part, pas simple.



>> Soit le prestataire ne demande comme configuration que le nom de
>> domaine, et son serveur DNS va en récupérer les enregistrements NS,
>> regarder si son propre serveur est référencé (donc service DNS
>> secondaire à fournir), demander au primaire la zone (AXFR/IXFR), et à
>> partir de là tout fonctionne.
>> Soit le prestataire va demander l'adresse IP (ou le nom) du serveur
>> primaire, le contacter pour récupérer la zone (qu'il soit dans les
>> enregistrements NS ou pas), et se configurer.
>>
> Avec ma config (en supposant qu'elle soit bonne...), je suis dans quelle
> situation ?

Honnêtement, je ne sais pas. Qu'en pense le support du prestataire ?
Dans son interface d'admin on vous demande un nom de domaine ou un serveur
de nom ?

>> Pour les tests, je recommande dig en ligne de commande : dig @NS
>> example.com SOA
>> en remplacant NS par l'adresse IP (ou le nom) du serveur DNS que l'on
>> veut
>
> Je me fais jeter partout pour cause de "recursion requested but not
> available".

> Pour limiter les risques, est-il possible d'envoyer toutes les mises à


> jour aux DNS Gandi, sans pouvoir être interrogé par qui que ce soit
> d'autre (que les DNS Gandi) ?

Je ne suis pas sûr de comprendre la question, mais si vous voulez que
votre serveur DNS ne soit pas « public » c'est à dire ne réponde
quasimment à personne, sauf à votre prestataire, en phase de tests, il
suffit de placer une directive du type :
allow-query { dns_gandi; };
dans votre fichier.



> Et puis merci, comme toujours (y'a pas de bouton Donate sur dotandco ;))

Dès que je mets les services en-ligne, y aura un bouton « Order », ce qui
devrait faire l'affaire :-)

Olivier Masson

unread,
Mar 27, 2008, 9:50:24 AM3/27/08
to
Patrick Mevzek a écrit :

>>> Après bien sûr comme dit précédemment il y a des pistes pour sécuriser
>>> l'ensemble.
>> J'ai vu que j'avais dnssec-keygen et -seczone, mais j'attendrai déjà
>> d'avoir bien configuré le reste...
>
> Vous pouvez effectivement utiliser dnssec-keygen pour créer une clef à
> utiliser par le mécanisme TSIG qui, en résumé, « sécurise » le transfert
> de zone (entre primaire et secondaires) en authentifiant fortement
> l'émetteur (le primaire). Cela remplace ou s'adjoint aux ACLs sur les
> adresses IP.

Mais il faut contrôler le secondaire pour pouvoir faire cela, sinon
comment signifier au secondaire qu'on utilise ce mécanisme, etc. ?

>
>> Pour limiter les risques, est-il possible d'envoyer toutes les mises à
>> jour aux DNS Gandi, sans pouvoir être interrogé par qui que ce soit
>> d'autre (que les DNS Gandi) ?
>
> Je ne suis pas sûr de comprendre la question, mais si vous voulez que
> votre serveur DNS ne soit pas « public » c'est à dire ne réponde
> quasimment à personne, sauf à votre prestataire, en phase de tests, il
> suffit de placer une directive du type :
> allow-query { dns_gandi; };
> dans votre fichier.
>

Je pense que la structure que je souhaite n'existe pas : informer les
DNS de mon registrar des modifications grâce à mon serveur DNS, sans que
ce dernier ne soit public (pour limiter les risques et décharger le
serveur).
Si j'utilise allow-query { dns_registrar } et que je me mets en DNS
primaire, les requêtes publiques seront donc toujours traitées par les
secondaires ce qui, je pense, n'est pas du tout "réglementaire" ?


> Dès que je mets les services en-ligne, y aura un bouton « Order », ce qui
> devrait faire l'affaire :-)
>

Quel type de service en ligne ?

Patrick Mevzek

unread,
Mar 27, 2008, 11:31:26 AM3/27/08
to
Le Thu, 27 Mar 2008 14:50:24 +0100, Olivier Masson a écrit:
>>>> Après bien sûr comme dit précédemment il y a des pistes pour sécuriser
>>>> l'ensemble.
>>> J'ai vu que j'avais dnssec-keygen et -seczone, mais j'attendrai déjà
>>> d'avoir bien configuré le reste...
>>
>> Vous pouvez effectivement utiliser dnssec-keygen pour créer une clef à
>> utiliser par le mécanisme TSIG qui, en résumé, « sécurise » le transfert
>> de zone (entre primaire et secondaires) en authentifiant fortement
>> l'émetteur (le primaire). Cela remplace ou s'adjoint aux ACLs sur les
>> adresses IP.
>
> Mais il faut contrôler le secondaire pour pouvoir faire cela, sinon
> comment signifier au secondaire qu'on utilise ce mécanisme, etc. ?

Pas forcément le contrôler, mais il doit être configuré en rapport, oui.
Certaines sociétés proposent cela, par exemple DNSPark (j'en suis juste un
client satisfait) qui propose des serveurs secondaires (qu'ils gèrent)
configurés pour des transferts avec TSIG : ils donnent la clef à utiliser
(à mettre dans la configuration du primaire)



>>> Pour limiter les risques, est-il possible d'envoyer toutes les mises à
>>> jour aux DNS Gandi, sans pouvoir être interrogé par qui que ce soit
>>> d'autre (que les DNS Gandi) ?
>>
>> Je ne suis pas sûr de comprendre la question, mais si vous voulez que
>> votre serveur DNS ne soit pas « public » c'est à dire ne réponde
>> quasimment à personne, sauf à votre prestataire, en phase de tests, il
>> suffit de placer une directive du type : allow-query { dns_gandi; };
>> dans votre fichier.
>>
>>
> Je pense que la structure que je souhaite n'existe pas : informer les
> DNS de mon registrar des modifications grâce à mon serveur DNS, sans que
> ce dernier ne soit public (pour limiter les risques et décharger le
> serveur).

Ca ressemble un peu à une configuration du type « hidden primary » : un
serveur DNS fait office de primaire, c'est là que les modifications (de
configuration, de zone) ont lieu, mais ce serveur n'est pas accessible
publiquement.
Les serveurs accessibles publiquement sont en fait tous des serveurs
secondaires liés au primaire « caché ».

Ce n'est pas en général une configuration « grand public » et je doute
qu'un prestataire « de base » fournisse cela.
Ce que vous cherchez n'est pas vraiment un service de DNS secondaire :
c'est plutôt un service de DNS « complet » où votre prestataire gère tous
les serveurs DNS de votre domaine, mais ces derniers récupèrent
l'information chez vous d'une façon ou d'une autre (cela pourrait aussi
être via l'interface web ou une interface RPC quelconque que vous utilisez
pour alimenter le contenu de votre zone stockée chez votre prestataire).

> Si j'utilise allow-query { dns_registrar } et que je me mets en DNS
> primaire, les requêtes publiques seront donc toujours traitées par les
> secondaires ce qui, je pense, n'est pas du tout "réglementaire" ?

Ce n'est pas une bonne idée effectivement. Si vous avez un tel
allow-query, il ne faut pas mettre le serveur en question dans les NS.

A noter, par rapport à que je disais avant, que le « vrai » primaire est
dans le SOA normalement, et que donc un prestataire de DNS secondaire peut
très bien aussi se baser sur ca. Encore une fois il faut voir les détails
des offres disponibles sur le marché (comme dit précédemment, récupération
des NS de la zone, ou spécification explicite de l'IP/du nom du primaire,
ou donc aussi recherche dans le SOA)

>> Dès que je mets les services en-ligne, y aura un bouton « Order », ce
>> qui devrait faire l'affaire :-)
>>
> Quel type de service en ligne ?

Autour des noms de domaine, si si :-)
Désolé je suis antibuzz, donc la politique c'est zéro communication
publique ou privée sur le sujet.
Mais merci pour l'intérêt porté.

Olivier Masson

unread,
Mar 27, 2008, 12:00:01 PM3/27/08
to
Patrick Mevzek a écrit :


> Ce n'est pas en général une configuration « grand public » et je doute
> qu'un prestataire « de base » fournisse cela.
> Ce que vous cherchez n'est pas vraiment un service de DNS secondaire :
> c'est plutôt un service de DNS « complet » où votre prestataire gère tous
> les serveurs DNS de votre domaine, mais ces derniers récupèrent
> l'information chez vous d'une façon ou d'une autre (cela pourrait aussi
> être via l'interface web ou une interface RPC quelconque que vous utilisez
> pour alimenter le contenu de votre zone stockée chez votre prestataire).
>

Bon bref, je vais devoir me farcir l'API de mon registrar.
Si je peux faire ça, j'ai la question bête suivante : quel intérêt
peut-on avoir - hormis, comme pour moi, la curiosité - de faire son
propre serveur DNS si notre registrar offre un tel service ?

Merci beaucoup pour toutes ces infos.

>
> Autour des noms de domaine, si si :-)
> Désolé je suis antibuzz, donc la politique c'est zéro communication
> publique ou privée sur le sujet.
> Mais merci pour l'intérêt porté.

Eh bien bonne chance dans cette mise en place et dans sa future
exploitation.

Patrick Mevzek

unread,
Mar 30, 2008, 6:52:55 PM3/30/08
to
Le Thu, 27 Mar 2008 17:00:01 +0100, Olivier Masson a écrit:
> Bon bref, je vais devoir me farcir l'API de mon registrar.
> Si je peux faire ça, j'ai la question bête suivante : quel intérêt
> peut-on avoir - hormis, comme pour moi, la curiosité - de faire son
> propre serveur DNS si notre registrar offre un tel service ?

À part la curiosité/l'apprentissage/démarrer un projet sans beaucoup de
fonds, effectivement installer un DNS derrière une connexion pas très
stable ou garantie (genre de l'ADSL courant) n'est pas très intéressant,
surtout qu'il risque de ne pas être forcément accessible avec un faible
délai (les resolveurs DNS, en tout cas bind, tiennent compte des temps de
réponse de NS, pour favoriser ceux qui répondent plus vites), et puis
qu'il y a toute la maintenance à faire et la gestion et quand on ne veut
pas se plonger dedans (ce qui est tout à fait compréhensible, chacun ces
centres d'intérêt et compétences), bah y a des risques.

Pascal Hambourg

unread,
Mar 31, 2008, 10:23:29 AM3/31/08
to
Salut,

Patrick Mevzek a écrit :


> Le Thu, 27 Mar 2008 14:50:24 +0100, Olivier Masson a écrit:
>
>>Je pense que la structure que je souhaite n'existe pas : informer les
>>DNS de mon registrar des modifications grâce à mon serveur DNS, sans que
>>ce dernier ne soit public (pour limiter les risques et décharger le
>>serveur).
>
> Ca ressemble un peu à une configuration du type « hidden primary »

Ça ne ressemble pas, c'est exactement cela, tel que décrit dans le
paragraphe "Stealth Servers" du manuel de référence de BIND 9.

> Ce n'est pas en général une configuration « grand public » et je doute
> qu'un prestataire « de base » fournisse cela.

Pourquoi ? Il suffirait que le prestataire permette l'utilisation de ses
serveurs DNS en tant que secondaires et n'exige pas que le primaire
spécifié figure dans les enregistrements NS de la zone, non ? Je n'ai
pas essayé, mais je pense que XName.org devrait le permettre.

Et l'avantage, c'est bien sûr de pouvoir manipuler sa zone sans devoir
passer par l'interface de gestion du prestataire.

Patrick Mevzek

unread,
Mar 31, 2008, 2:54:52 PM3/31/08
to
Le Mon, 31 Mar 2008 16:23:29 +0200, Pascal Hambourg a écrit:
>> Ce n'est pas en général une configuration « grand public » et je doute
>> qu'un prestataire « de base » fournisse cela.
>
> Pourquoi ? Il suffirait que le prestataire permette l'utilisation de ses
> serveurs DNS en tant que secondaires et n'exige pas que le primaire
> spécifié figure dans les enregistrements NS de la zone, non ?

Je n'ai pas dit que c'était infaisable :-), j'ai juste dit que ce n'était
pas standard/courant. Suffit de prendre les bureaux d'enregistrements qui
font les services de DNS primaires et/ou secondaires, je n'en connais pas
qui font du « hidden primary » (sans avoir cherché de manière exhaustive,
donc les contradicteurs rectifieront :-)).

Ce n'est pas un service grand public c'est tout, puisque le grand public
ne s'amuse pas à avoir son serveur DNS chez lui et le configurer à la main
avec amour. Il préfère que son prestataire gère tout, et donc
choisir préférentiellement le service de DNS primaire couplé à redirections
email/web, et dans une moindre mesure le service de DNS secondaire.

Je ne connais pas de stats de ce genre public, mais si on regarde :
http://web.archive.org/web/20041031231622/http://gandi.net/stats/serv_Redir.png
http://web.archive.org/web/20041101001328/http://gandi.net/stats/serv_Sec.png
http://web.archive.org/web/20041031225359/http://gandi.net/stats/serv_Custom.png

on a
~153 000 domaines utilisant le service de DNS primaire avec redirections
~30 000 domaines utilisant le service de DNS primaire personnalisé
~19 600 domaines utilisant le service de DNS secondaire

Donc c'est déjà un rapport 10 entre service primaire et secondaire, et je
pense que ca serait encore un rapport 10 entre secondaire et primaire
caché.

Mais c'est un service qui existe, oui forcément car cela répond à un
besoin bien précis. De nombreuses racines ccTLD/gTLD fonctionnent ainsi.

Olivier Masson

unread,
Apr 1, 2008, 3:26:50 AM4/1/08
to
Pascal Hambourg a écrit :

> Pourquoi ? Il suffirait que le prestataire permette l'utilisation de ses
> serveurs DNS en tant que secondaires et n'exige pas que le primaire
> spécifié figure dans les enregistrements NS de la zone, non ? Je n'ai
> pas essayé, mais je pense que XName.org devrait le permettre.
>

Bonjour,

C'est super ça xname.org !
J'ai tenté de mettre gandi en secondaire, mais ça ne passe pas.
Les dns qu'ils collent dans le resolv.conf de leurs dédiés virtuels ne
servent apparemment qu'à résoudre en local puisque je n'ai pas pu les
mettre sur un domaine.

> Et l'avantage, c'est bien sûr de pouvoir manipuler sa zone sans devoir
> passer par l'interface de gestion du prestataire.

Précisément. On peut faire la même chose, je pense, avec l'API Gandi et
probablement d'autres registrar mais le but était de passer par des
manip DNS uniquement.

Pascal Hambourg

unread,
Apr 1, 2008, 5:10:11 AM4/1/08
to
Olivier Masson a écrit :

> Pascal Hambourg a écrit :
>
>> Pourquoi ? Il suffirait que le prestataire permette l'utilisation de
>> ses serveurs DNS en tant que secondaires et n'exige pas que le
>> primaire spécifié figure dans les enregistrements NS de la zone, non ?
>> Je n'ai pas essayé, mais je pense que XName.org devrait le permettre.
>
> C'est super ça xname.org !

J'utilise leurs serveurs DNS comme secondaires pour la zone inverse de
mon bloc IPv6, le primaire étant chez moi. Certes ce n'était pas
indispensable ni pour l'aspect répartition de charge car le trafic de
cette zone est très faible ni pour l'aspect redondance car si ma
connexion tombe les reverses perdent de toute façon de leur utilité.
Reste le cas où mon primaire tombe sans que la connexion tombe, mais ça
arrive beaucoup moins souvent que l'inverse !

Bref, tout ça pour dire qu'a priori il me suffirait de supprimer mon
primaire de la liste des NS de la zone ainsi que dans la délégation pour
me retrouver en configuration "hidden primary".

> J'ai tenté de mettre gandi en secondaire, mais ça ne passe pas.

Mais encore ?

> Les dns qu'ils collent dans le resolv.conf de leurs dédiés virtuels ne
> servent apparemment qu'à résoudre en local puisque je n'ai pas pu les
> mettre sur un domaine.

Les DNS qu'on met dans resolv.conf sont des serveurs récursifs, pas des
serveurs autoritaires primaires ou secondaires servant des zones. Ils
n'ont pas le même rôle, c'est normal qu'on ne puisse pas les spécifier
comme NS d'une zone.

Olivier Masson

unread,
Apr 1, 2008, 6:21:08 AM4/1/08
to
Pascal Hambourg a ï¿œcrit :

>> J'ai tentᅵ de mettre gandi en secondaire, mais ᅵa ne passe pas.
>
> Mais encore ?
>

C'ᅵtait revenu ᅵ la config de base (les dns de gandi) mais il n'est pas
impossible que j'aie seulement essayᅵ avec les dns rᅵcursifs...


> Les DNS qu'on met dans resolv.conf sont des serveurs rï¿œcursifs, pas des

> serveurs autoritaires primaires ou secondaires servant des zones. Ils

> n'ont pas le mï¿œme rï¿œle, c'est normal qu'on ne puisse pas les spï¿œcifier

> comme NS d'une zone.

Ce qui explique certains problï¿œmes que j'ai eu, merci.

Patrick Mevzek

unread,
Apr 1, 2008, 12:35:14 PM4/1/08
to
Le Mon, 31 Mar 2008 16:23:29 +0200, Pascal Hambourg a écrit:
> Et l'avantage, c'est bien sûr de pouvoir manipuler sa zone sans devoir
> passer par l'interface de gestion du prestataire.

Personnellement j'ai toujours pensé que, sans avoir besoin de hidden
primary à gérer, les serveurs du prestataire pourraient être mis à jour à
distance... tout simplement via le protocole DNS et son mécanisme de mise
à jour (RFC2136) ! Cela permet un contrôle total à distance, c'est
sécurisable (TSIG + ACL sur les IPs si nécessaire), évolué (gestion de
pré-requis pour ne faire les modifications qu'à certaines conditions) et «
standard », pas besoin de développer un client spécifique à une interface
donnée, les sources de bind donnent l'exécutable nsupdate et cela suffit
bien (et avec des bibliothèque comme Net::DNS::Update en Perl on peut
aisément construire un client avec les fonctionnalités et les gimmicks de
son choix).

Je ne connais pas de prestataires qui permettent cela (beaucoup permettent
les modifications - pas forcément toutes - à distance, mais c'est en
général à la DynDNS.com, via un appel HTTP), peut-être existent-ils. Mais
c'est le même genre de service que le « primaire caché » donc pas grand
public.

En tout cas je trouve cela intéressant à la fois en tant que consommateur
et en tant que « producteur »... :-)

0 new messages