Question bonus (vraiment parce que je vous aime bien !)
Lorsque je me rends sur xname, dans la gestion de ma zone quagga.fr, j’ai ceci :
[quote]Zone serveur de noms n° de série voir statut quagga.fr (S) Évènements I ns0.xname.org. non disponible contenu de la zone ns1.xname.org. non disponible contenu de la zone
88...* non disponible contenu de la zone[/quote]
Si j’affiche le contenu de la zone ns1.xname.org., j’obtiens quelque chose du genre :
Pareil pour l’autre zone xname.
Et pour mon serveur primaire, j’obtiens ceci :
[quote]Contenu de la zone quagga.fr sur le serveur 88...*
; <<>> DiG 9.3.4-P1.1 <<>> axfr quagga.fr@88...*
; (1 server found)
;; global options: printcmd
; Transfer failed.
[/quote]
Ce transfer failed m’inquiète, de quoi s’agit-t-il ?
Merci d’avance !
ps : c’est fatiguant de modifier systématiquement son nom de domaine en quagga.fr, et son @ip avec des *, et le reverse de la dedibox aussi ^^
[quote=“quagga”]
ps : c’est fatiguant de modifier systématiquement son nom de domaine en quagga.fr, et son @ip avec des *, et le reverse de la dedibox aussi ^^[/quote]
Pourquoi le fais tu?
Quelle redirection DNS ? Si tu veux parler de la délégation de la zone à ton serveur primaire et aux secondaires de Xname, ce n’est pas une redirection.
Uniquement en cas de modification du contenu de la zone. La comparaison des numéros de série permet à un serveur esclave de savoir si sa copie d’une zone est plus ancienne que celle du serveur maître. Dans ce cas, il demande un transfert de zone au serveur maître pour mettre sa copie à jour.
Le plus simple à manipuler : un enregistrement MX individuel pour chaque sous-domaine de courrier, qui désigne le nom du serveur SMTP qui va le gérer. Exemple si le courrier pour samba.quagga.fr est géré par le serveur SMTP mail.quagga.fr :
Si tous les sous-domaines possibles sont gérés par un même serveur, on peut utiliser un wildcard :
Le CNAME est plus délicat à manier. Il indique une équivalence entre deux noms de domaines. Par exemple :
signifie que le nom de domaine samba.quagga.fr est considéré comme équivalent au nom de domaine quagga.fr, avec la même adresse IP, le même serveur de courrier.
Mais en tout état de cause, un nom de domaine défini à droite d’un enregistrement MX (ou NS, d’ailleurs) ne doit pas figurer à gauche d’un enregistrement CNAME mais d’un ou plusieurs enregistrements d’adresse A (IPv4) ou AAAA (IPv6). Donc ceci est à proscrire :
samba.quagga.fr. IN MX 10 mx.quagga.fr.
mx.quagga.fr. IN CNAME mail.quagga.fr.
Je ne sais pas. J’ai la même chose avec mes zones pour lesquelles Xname est NS secondaire, donc c’est peut-être normal. Peut-être parce que quand Xname sert de secondaire, son système d’information ne gère pas les numéros de série des zones.
[quote=“quagga”]Contenu de la zone quagga.fr sur le serveur 88...*
; <<>> DiG 9.3.4-P1.1 <<>> axfr quagga.fr@88...*
; (1 server found)
;; global options: printcmd
; Transfer failed.[/quote]
Probablement parce que tu n’as pas autorisé ton propre serveur à demander des transferts de la zone. En ajoutant “localhost” dans l’option allow-transfer de la zone ça devrait marcher mieux.
Rappel : “localhost” dans les ACL de BIND ne signifie pas 127.0.0.1 mais toutes les adresses locales de la machine donc 127.0.0.1, 88...*, ::1 (adresse de loopback IPv6)…
Même chose, il faut autoriser les requêtes de transferts de zone provenant de cette adresse ainsi que d’autres appartenant à Xname et pas seulement celles des NS, comme indiqué dans la FAQ de Xname <https://www.xname.org/faq.php?language=fr#item4>.
EDIT : 92.243.14.172 est l’adresse du serveur web xname.org, qui envoie une demande de transfert de zone quand on clique sur “contenu de la zone”.
EDIT 2 : L’option transfer-source n’a rien à voir là-dedans. Elle spécifie l’adresse source de ton BIND lorsqu’il fait une demande de transfert de zone, et donc qu’il est esclave pour cette zone. D’autre part il faut y mettre une adresse appartenant à la machine.
Moi j’ai défini une ACL pour les adresses d’Xname dans mon named.conf :
acl xname { // DNS xname.org
195.234.42.0/24; // inclut ns0.xname.org [195.234.42.1]
193.218.105.144/28;
87.98.164.164; // ns1.xname.org
88.191.64.64; // ns2.xname.org
92.243.14.172; // site web
};
Et j’inclus “xname” dans l’option allow-transfer des zones pour lesquelles Xname est secondaire :
Un énorme merci, pour cette réponse très détaillées, et qui répond à pas mal d’interrogations !!
J’effectuerai les modifications, en espérant pouvoir bientôt mettre le sujet en ‘résolu’ !
Me voila de nouveau !
Après un petit weekend de trois jours à attendre impatiemment de pouvoir faire un ping de quagga.fr… Ben rien !
Le test de l’afnic est concluant (il n’affiche aucun message d’erreur et aucun avertissement, si ce n’est la présence d’un joker pour l’enregistrement MX).
Donc de ce point de vu là tout semble normal.
Je vous joins mes points de config, et mes fichiers de zones en espérant que vous trouverez la petite (ou la grosse) erreur qui m’empêche d’aller plus loin.
$TTL 86400
@ IN SOA sd-*****.dedibox.fr. root.quagga.fr. (
2009043006
10800
3600
604800
38400 )
@ IN NS sd-12590.quagga.fr.
@ IN NS ns0.xname.org.
@ IN NS ns1.xname.org.
@ IN MX 10 mail.quagga.fr.
*.quagga.fr. IN MX 10 mail.quagga.fr.
@ IN A 88.XX.XX.XX
www IN A 88.XX.XX.XX
mail IN A 88.XX.XX.XX
ns IN A 88.XX.XX.XX
named-checkconf -z
zone localhost.localdomain/IN: loaded serial 0
zone localhost/IN: loaded serial 0
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: NS '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa' has no address records (A or AAAA)
zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
zone 1.0.0.127.in-addr.arpa/IN: NS '1.0.0.127.in-addr.arpa' has no address records (A or AAAA)
zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
zone 0.in-addr.arpa/IN: NS '0.in-addr.arpa' has no address records (A or AAAA)
zone 0.in-addr.arpa/IN: loaded serial 0
zone quagga.fr/IN: loaded serial 2009043006
Enfin, je terminerai par une source possible d’erreur.
Mon registar est rapidomaine, voici ma configuration (il suffit logiquement de déclarer les serveurs ayant autorités) :
dans ta conf je ne vois pas de forwarders. cad quand la zone dns n’est pas gérée par ton serveur bind, à quel serveur de plus haut niveau il doit demander.
j’ai l’impression que tu demande dans resolv.conf a interoger plusieurs dns. mais à partir du moment ou un serveur repond, que ce soit oui ou non, il ne demandera pas aux autres. de plus ce fichier n,'est utilisé que par les services reseau de la machine mais pas par bind lui même.
Je n’ai pas de fichier /etc/named.conf.options
Mais je crois que vous pointez le problème, je n’ai jamais déclaré de forwarders…
Dans quel fichier dois-je le déclarer ? Et quelles adresses ? FAI ou registar ou les deux ou autres ?
Observations sur les fichiers de configuration et de zone :
Il vaut mieux mettre l’option allow-transfer dans chaque zone plutôt que dans les options globales car Xname n’a pas besoin de lire tes zones pour lesquelles il n’est pas secondaire.
Tu as défini une acl “xname”, c’est pour t’en servir dans l’option allow-transfer de la zone plutôt que de répéter les adresses (et il manque localhost).
Le nom de ton serveur défini comme NS dans ton fichier de zone appartient à la zone mais n’a pas d’enregistrement A défini, et ne correspond pas au nom déclaré au registrar ou dans le SOA. Coquille ?
Ta zone contient un enregistrement A pour ns.quagga.fr qui ne sert à rien apparemment.
Le passage du zonecheck de l’Afnic ne suffit pas. Il faut vérifier que les serveurs de l’Afnic ont bien enregistré la liste de tes serveurs transmise via le registrar. Par exemple :
Si ce n’est pas le cas, il faut éventuellement essayer de redéclarer tes serveurs auprès du registrar. Même si ce dernier les avait acceptés, l’Afnic ne crée la délégation que si la zone et ses serveurs sont correctement configurés.
Les messages de log cités ont trait à la fonction récursive de BIND (quand un processus local demande une résolution DNS) et non à sa fonction autoritaire. Ils sont causés par des zones, délégations ou serveurs DNS mal configurés.
Thomas :
La liste que tu cites est la liste des serveurs faisant autorité pour son domaine donnée au registrar, rien à voir avec un resolv.conf. D’autre part l’option “forwarders” ne sert que pour la fonction récursive/cache, et n’est de toute façon pas nécessaire : en son absence, BIND fait les résolutions récursivement à partir de la racine tout seule comme un grand, indépendamment des DNS du FAI/hébergeur.
EDIT : il ne faut surtout pas mettre les adresses des DNS du registrar comme forwarders ! Ce sont des serveurs autoritaires, pas des serveurs récursifs.
Ben non, justement. Dans ton message précédent je lis :
Je soupçonne une coquille quand tu as maquillé le fichier.
[quote=“quagga”]Cet enregistrement n’est pas suffisant ??
Aucun rapport. Il définit une adresse pour @ (quagga.fr) et non sd-*****.quagga.fr.
[quote=“quagga”]Il s’agit de cette ligne qui ne sert a rien ?
A priori oui. A moins que ns.quagga.fr te serve par ailleurs. En tout cas il ne sert pas pour la gestion technique de la zone quagge.fr puisqu’il n’est pas défini en tant que NS.
Si je comprends bien, la seule modification a apporter (outre la modification des allow transfers déjà effectuée et la suppression de l’enregistrement A pour ns), c’est de déclarer un enregistrement A pour mon serveur dns primaire :
sd-*****.dedibox.fr. IN A 88.XX.XX.XX
?
Ne joue pas le même rôle ?
Merci !
Question subsidiaire soulevée par Thomas :
Ne dois-je pas déclarer quelque part que mon nom de domaine viens de tel registar ?
EDIT :
Au passage, voici le résultat d’un tail /var/log/messages après un rndc reload
Que signifient les erreurs ?
Quelle différence existe-t-il entre service named restart et rndc reload ?
[quote=“quagga”]Si je comprends bien, la seule modification a apporter (outre la modification des allow transfers déjà effectuée et la suppression de l’enregistrement A pour ns), c’est de déclarer un enregistrement A pour mon serveur dns primaire :
Non, car le nom sd-*****.dedibox.fr. ne fait pas partie de la zone quagga.fr. Son adresse est définie par un enregistrement A qui se trouve dans la zone dedibox.fr.
Les choses auraient été différentes si tu avais défini par exemple ns.quagga.fr comme NS pour ta zone. Dans ce cas il aurait fallu lui créer un enregistrement A non seulement dans la zone mais aussi dans la zone parente “fr.” comme pour les NS de la délégation, car sinon il y aurait un problème de poule et d’oeuf : la zone quagga.fr est servie par ns.quagga.fr mais pour connaître l’adresse de ce dernier je dois accéder à la zone, et pour accéder à la zone je dois connaître l’adresse du serveur… Cet enregistrement A accompagnant un enregistrement NS dans la zone parente est appelé “glue record”.
[quote=“quagga”]@ IN SOA sd-*****.dedibox.fr.
Ne joue pas le même rôle ?[/quote]
Non. Le nom du serveur primaire dans le SOA est une information plus administrative que technique, et n’est pas utilisée lors de processus de résolution de noms, ni à ma connaissance dans le processus de réplication de la zone entre maître et esclaves.
Non. Le bureau d’enregistrement se déclare lui-même dans les informations whois de ton domaine qu’il publie. Au niveau DNS il n’a aucun rôle dans ton cas : c’est l’Afnic qui crée la délégation, c’est ton serveur et ceux de Xname qui servent la zone.
[quote=“quagga”]Au passage, voici le résultat d’un tail /var/log/messages après un rndc reload […]
Que signifient les erreurs ?
Quelle différence existe-t-il entre service named restart et rndc reload ?[/quote]
Je ne connais pas ces messages, mais AMA il s’agit plus d’avertissements que d’erreurs, sinon named ne se rechargerait pas.
Je suppose que tu veux dire “service bind9 restart” ? Il n’y a pas vraiment de différence. Tu peux voir dans le script de démarrage /etc/init.d/bind9 que la section qui traite la commande “restart” exécute “rndc reload” essentiellement. Heh, “service” c’est un machin qui vient de RedHat ! Avec Debian il y a invoke-rc.d.
Cet enregistrement ne me sert donc pas, je l’enlèverai. Au final, le seul paramètre qui gênait le bon fonctionnement du DNS était cet enregistrement :
[quote]
ns IN A 88.XX.XX.XX[/quote]
En fait j’utilise trois distributions de Linux : Debian, Fedora, et Suse.
Mais je dois reconnaitre, sans fausseté, que l’énorme avantage de Debian est sa communauté (comme en témoigne ce forum).
).
En effet…