Fonctionnement d'un DNS. Et pourquoi 2 NS ?

On 2008-03-17, Olivier Masson <sisemen@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.

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/>

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?id217

est-ce grave et comment y remédier ?

MAJ ?

Manuel

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 ;)

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).

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.

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

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

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 :-)

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

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é.

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

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.

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