Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Matériel Réseaux et Internet IP Bind9

Bind9

41 réponses
Avatar
JKB
Bonjour à tous,

J'ai dû modifier ma configuration de bind pour jouer avec les view
et je n'aurais pas dû.

Mon bind fonctionne sous Linux/Debian et sa configuration est la
suivante :

named.conf.options :
acl "trusted" {
127.0.0.1;
::1;
192.168.0.0/16;
2001:7a8:a8ed::/48;
};

acl "lans" {
192.168.0.0/16;
127.0.0.1;
};

acl "slaves" {
178.132.17.109;
194.79.134.46;
};

options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.

// query-source address * port 53;

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

forwarders {
// Nerim
195.5.209.150;
194.79.128.150;
2001:7a8:1:1::70;
2001:7a8:1:5::69;
};

auth-nxdomain no; # conform to RFC1035
allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };
listen-on-v6 { any; };
};

named.conf.local:
view "external" {
// match-clients { ! "lans"; };
match-clients { any; };
recursion yes;

zone "systella.fr" {
type master;
notify yes;
allow-transfer { "slaves"; };
allow-update { "lans"; };
file "/etc/bind/systella.fr.external";
};
};

Je n'ai pas de vue active car il y a un second problème que
j'évoquerai lorsque le premier sera réglé.

Je simplifie, bind sert plusieurs domaines et des reverses (j'ai une
délégation pour cela). Le fichier /etc/bind/systella.fr.external
est correct, il s'agissait du fichier que j'utilisais auparavant.

Il y a un slave sur noemie.nerim.net.

En local, tout fonctionne :
Root rayleigh:[/var/lib/iptables] > dig @127.0.0.1 rayleigh.systella.fr

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @127.0.0.1 rayleigh.systella.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33292
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d7e17772ca44a43b7b4ca9085d2b4a27dbdc4eca0fb5a4e1 (good)
;; QUESTION SECTION:
;rayleigh.systella.fr. IN A

;; ANSWER SECTION:
rayleigh.systella.fr. 86400 IN A 213.41.150.218

;; AUTHORITY SECTION:
systella.fr. 86400 IN NS newton.systella.fr.
systella.fr. 86400 IN NS rayleigh.systella.fr.
systella.fr. 86400 IN NS noemie.nerim.net.

;; ADDITIONAL SECTION:
newton.systella.fr. 86400 IN A 213.41.149.211
noemie.nerim.net. 86071 IN A 178.132.17.109

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: dim. juil. 14 17:28:39 CEST 2019
;; MSG SIZE rcvd: 190

À distance aussi :
legendre# dig @213.41.150.218 rayleigh.systella.fr

; <<>> DiG 9.10.5-P1 <<>> @213.41.150.218 rayleigh.systella.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10924
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rayleigh.systella.fr. IN A

;; ANSWER SECTION:
rayleigh.systella.fr. 86400 IN A 213.41.150.218

;; AUTHORITY SECTION:
systella.fr. 86400 IN NS newton.systella.fr.
systella.fr. 86400 IN NS rayleigh.systella.fr.
systella.fr. 86400 IN NS noemie.nerim.net.

;; ADDITIONAL SECTION:
newton.systella.fr. 86400 IN A 213.41.149.211

;; Query time: 31 msec
;; SERVER: 213.41.150.218#53(213.41.150.218)
;; WHEN: Sun Jul 14 17:29:17 CEST 2019
;; MSG SIZE rcvd: 146

Sauf que le slave ne récupère rien :
legendre# dig @noemie.nerim.net rayleigh.systella.fr

; <<>> DiG 9.10.5-P1 <<>> @noemie.nerim.net rayleigh.systella.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 62659
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rayleigh.systella.fr. IN A

;; Query time: 15 msec
;; SERVER: 178.132.17.109#53(178.132.17.109)
;; WHEN: Sun Jul 14 17:30:21 CEST 2019
;; MSG SIZE rcvd: 49

Je ne comprends pas d'où provient le "recursion requested but not
available". Un tcpdump semble envoyer la notifisation vers
noemie.nerim.net mais s'arrête là. Naturellement, j'ai incrémenté
le compteur, rien n'y fait, noemie ne prend pas la zone.

Je suis preneur de toute idée pour remettre la chose d'équerre.

Bien cordialement,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
JKB
Le Thu, 18 Jul 2019 09:50:55 +0200,
Pascal Hambourg écrivait :
Le 18/07/2019 à 09:11, JKB a écrit :
Le Wed, 17 Jul 2019 23:54:16 +0200,
Pascal Hambourg écrivait :
Le 17/07/2019 à 10:27, JKB a écrit :
Le Tue, 16 Jul 2019 23:50:07 +0200,
Pascal Hambourg écrivait :
("tout sauf x.x.x.x/30") parce que je ne voulais pas que BIND écoute sur
ce bloc d'adresses utilisées pour diverses choses temporaires.

Bien vu. Encore un truc piégeux. Mais dans ce cas, pourquoi la bonne
vue est-elle sélectionnée alors que ça échoue sur un "WARNING:
recursion requested but not available" ?

La récursion est-elle autorisée dans la vue external ?


Donc le message est normal, non ?

Ben non, parce que la vue sélectionnée devrait être "internal".

D'après la ligne de log que tu as rapportée, l'adresse source de la
requête est 213.41.150.218 et ne correspond pas à l'ACL "lans".

Il y a méprise.
Avec les ACL suivantes pour la view external :
match-clients { ! { "lans"; }; };
cela ne fonctionne pas.
Preuve :
Root rayleigh:[/usr/bin] > dig @localhost rayleigh.systella.fr
...
;; ANSWER SECTION:
rayleigh.systella.fr. 86400 IN A 192.168.254.1
;; AUTHORITY SECTION:
systella.fr. 86400 IN NS dns.systella.fr.
;; ADDITIONAL SECTION:
dns.systella.fr. 86400 IN A 213.41.150.218
dns.systella.fr. 86400 IN A 213.41.149.211
...
Root rayleigh:[/usr/bin] > dig @213.41.149.211 rayleigh.systella.fr
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @213.41.149.211 rayleigh.systella.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 13740
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: c7ebbc5566d89c445038986f5d30304b0f524efd30c888e8 (good)
;; QUESTION SECTION:
;rayleigh.systella.fr. IN A
;; Query time: 40 msec
;; SERVER: 213.41.149.211#53(213.41.149.211)
;; WHEN: jeu. juil. 18 10:39:39 CEST 2019
;; MSG SIZE rcvd: 77
Dans les logs, j'ai :
Jul 18 10:39:57 rayleigh named[6724]: client @0x7f1d185115e0 213.41.150.218#38394 (rayleigh.systella.fr): view external local: query (cache) 'rayleigh.systella.fr/A/IN' denied
qui est spécifiée dans le fichier named.conf.default-zones et qui
contient :
view "external local" {
match-clients { any; };
zone "." {
type hint;
file "/usr/share/dns/root.hints";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
...
//ainsi que tous les reverses définis par défaut.
};
Ce qui me dérange un peu, c'est que l'ACL { ! { "lans"; }; };
ne suffit pas à sélectionner la vue "external" sachant que
lans est défini comme suit :
acl "lans" {
192.168.0.0/16;
127.0.0.1;
};
Remarque bien, j'ai essayé aussi
match-clients { ! 192.168.0.0/16; ! 127.0.0.1; };
sans succès. Seul
match-clients { any; };
fonctionne et j'aimerais bien savoir ce qui défrise bind dans cette
ACL.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
Le 18/07/2019 à 10:47, JKB a écrit :
Ce qui me dérange un peu, c'est que l'ACL { ! { "lans"; }; };
ne suffit pas à sélectionner la vue "external" sachant que
lans est défini comme suit :
acl "lans" {
192.168.0.0/16;
127.0.0.1;
};
Remarque bien, j'ai essayé aussi
match-clients { ! 192.168.0.0/16; ! 127.0.0.1; };
sans succès. Seul
match-clients { any; };
fonctionne et j'aimerais bien savoir ce qui défrise bind dans cette
ACL.

As-tu essayé ceci ("tout sauf lans") ?
match-clients { ! lans; any; };
Avatar
JKB
Le Thu, 18 Jul 2019 11:15:42 +0200,
Pascal Hambourg écrivait :
Le 18/07/2019 à 10:47, JKB a écrit :
Ce qui me dérange un peu, c'est que l'ACL { ! { "lans"; }; };
ne suffit pas à sélectionner la vue "external" sachant que
lans est défini comme suit :
acl "lans" {
192.168.0.0/16;
127.0.0.1;
};
Remarque bien, j'ai essayé aussi
match-clients { ! 192.168.0.0/16; ! 127.0.0.1; };
sans succès. Seul
match-clients { any; };
fonctionne et j'aimerais bien savoir ce qui défrise bind dans cette
ACL.

As-tu essayé ceci ("tout sauf lans") ?
match-clients { ! lans; any; };

Ceci fonctionne :
match-clients { ! { "lans"; }; any; };
Mais je ne vois pas en quoi cela signifie tout sauf lans... Je lis
cela comme suit : tout sauf lans et tous les clients.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
Le 18/07/2019 à 12:02, JKB a écrit :
Ceci fonctionne :
match-clients { ! { "lans"; }; any; };
Mais je ne vois pas en quoi cela signifie tout sauf lans... Je lis
cela comme suit : tout sauf lans et tous les clients.

Comme j'essayais de l'expliquer dans <qgieub$pij$,
une ACL n'est pas une expression combinatoire. La description du manuel
de BIND sera peut-être plus claire :
"When used as an access control list, a non-negated match allows access
and a negated match denies access. If there is no match, access is denied.
(...)
Order of insertion is significant. If more than one element in an ACL is
found to match a given IP address or prefix, preference will be given to
the one that came first in the ACL definition."
"! A" ne signifie pas que l'ACL est vraie si A est faux, mais que l'ACL
est fausse si A est vrai, et si A est faux l'élément suivant de l'ACL
est évalué. S'il n'y a pas d'autre élément, l'ACL est fausse.
Avatar
JKB
Le Thu, 18 Jul 2019 13:06:53 +0200,
Pascal Hambourg écrivait :
Le 18/07/2019 à 12:02, JKB a écrit :
Ceci fonctionne :
match-clients { ! { "lans"; }; any; };
Mais je ne vois pas en quoi cela signifie tout sauf lans... Je lis
cela comme suit : tout sauf lans et tous les clients.

Comme j'essayais de l'expliquer dans <qgieub$pij$,
une ACL n'est pas une expression combinatoire. La description du manuel
de BIND sera peut-être plus claire :
"When used as an access control list, a non-negated match allows access
and a negated match denies access. If there is no match, access is denied.
(...)
Order of insertion is significant. If more than one element in an ACL is
found to match a given IP address or prefix, preference will be given to
the one that came first in the ACL definition."
"! A" ne signifie pas que l'ACL est vraie si A est faux, mais que l'ACL
est fausse si A est vrai, et si A est faux l'élément suivant de l'ACL
est évalué. S'il n'y a pas d'autre élément, l'ACL est fausse.

Rhoh pétard, même en relisant, ça m'avait échappé. Je viens
d'ailleurs de vérifier dans la page man, l'information ne s'y trouve
pas !
Merci,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
Le 18/07/2019 à 09:41, Pascal Hambourg a écrit :
Le 18/07/2019 à 09:10, JKB a écrit :
Le Wed, 17 Jul 2019 23:53:37 +0200,
Pascal Hambourg écrivait :
Pourquoi : le contenu de la zone des serveurs de Nerim ne vient pas de
ton serveur maître (tu as écris toi-même qu'elle avait été récupérée sur
maridia).

    Je n'ai pas la main sur Maridia. J'ai eu le staff de Nérim qui m'a
    dit avoir récupéré la zone de rayleigh.systella.fr avec
    dig @ip systella.fr axfr
    Je suppose donc que la zone sur maridia comporte les nouveaux NS et
    serial.
    Je n'ai pas les moyens de mettre leur parole en doute...

Bien sûr que si, il suffit d'interroger maridia :
dig SOA systella.fr @maridia.nerim.net
et de comparer la réponse avec celle de rayleigh.

Du nouveau ? Ça n'a pas l'air de progresser ni chez Nerim ni chez le
registrar/l'AFNIC.
Avatar
JKB
Le Sat, 20 Jul 2019 10:14:07 +0200,
Pascal Hambourg écrivait :
Le 18/07/2019 à 09:41, Pascal Hambourg a écrit :
Le 18/07/2019 à 09:10, JKB a écrit :
Le Wed, 17 Jul 2019 23:53:37 +0200,
Pascal Hambourg écrivait :
Pourquoi : le contenu de la zone des serveurs de Nerim ne vient pas de
ton serveur maître (tu as écris toi-même qu'elle avait été récupérée sur
maridia).

    Je n'ai pas la main sur Maridia. J'ai eu le staff de Nérim qui m'a
    dit avoir récupéré la zone de rayleigh.systella.fr avec
    dig @ip systella.fr axfr
    Je suppose donc que la zone sur maridia comporte les nouveaux NS et
    serial.
    Je n'ai pas les moyens de mettre leur parole en doute...

Bien sûr que si, il suffit d'interroger maridia :
dig SOA systella.fr @maridia.nerim.net
et de comparer la réponse avec celle de rayleigh.

Du nouveau ? Ça n'a pas l'air de progresser ni chez Nerim ni chez le
registrar/l'AFNIC.

Je suis en train de pulvériser les gars d'Amen !
Il a fallu cinq jours pour que ces types corrigent une erreur de
leur système interne (lorsque tu changes les DNS, même si tu peux
enregistrer plus de deux DNS, leur fichu système ne tient compte que
des deux premiers !), et encore, parce que je leur ai soufflé dans
les bronches ! Tu envoies un mail au service technique, ils n'en ont
strictement rien à faire. Il faut les appeler derrière pour que les
informations dans le mail soient traitées !
Dernier contact avec eux, jeudi après-midi. Mail :
Nous revenons vers vous concernant la modification des DNS primaires associés
au domaine systella.fr.
Nos administrateurs viennent de nous avoir pu supprimer toutes vos tentatives
de modification DNS. Nous vous confirmons que nous venons de relancer les DNS
de votre choix:
- rayleigh.systella.fr 213.41.150.218
- noemie.nerim.net 178.132.17.109
- newton.systella.fr 213.41.149.211
Veuillez toutefois, patienter le délai de propagation, soit 24h afin que les
DNS s'activent définitivement.
Les fautes de Français sont certifiées d'origine !
Déjà, il n'y a eu _qu'une_ modification de ma part et non plusieurs,
mais c'est du détail. Et effectivement, rien ne progresse. Je leur
laisse 48 heures donc jusqu'à cet après-midi pour râler un bon coup.
Aujourd'hui, ça faut une semaine que le truc traîne et je commence à
perdre patience.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
Le 20/07/2019 à 10:26, JKB a écrit :
Déjà, il n'y a eu _qu'une_ modification de ma part et non plusieurs,
mais c'est du détail. Et effectivement, rien ne progresse. Je leur
laisse 48 heures donc jusqu'à cet après-midi pour râler un bon coup.

À mon avis il faudrait aussi faire en sorte que noemie se synchronise
sur ton NS primaire et serve la même version de la zone. D'une part au
cas où l'incohérence entre les NS bloquerait l'enregistrement des
nouveaux NS par l'AFNIC, et d'autre part car même dans le cas contraire
noemie ne servira pas les bonnes informations.
Le serial de la zone sur noemie (2019071502) est supérieur à celui sur
tes NS (2019071405), ce qui n'incite pas noemie à se mettre à jour même
s'il est configuré en esclave de ton NS primaire. Tu pourrais
incrémenter le serial sur ton NS primaire et voir si noemie répond
positivement au NOTIFY et se synchronise. Si ça n'a rien changé au bout
du délai de refresh (6h), il faudrait recontacter Nerim.
Idéalement il faudrait aussi que maridia ne fasse plus autorité pour la
zone au cas où quelqu'un l'utiliserait encore comme DNS récursif.
Avatar
JKB
Le Sat, 20 Jul 2019 11:59:05 +0200,
Pascal Hambourg écrivait :
Le 20/07/2019 à 10:26, JKB a écrit :
Déjà, il n'y a eu _qu'une_ modification de ma part et non plusieurs,
mais c'est du détail. Et effectivement, rien ne progresse. Je leur
laisse 48 heures donc jusqu'à cet après-midi pour râler un bon coup.

À mon avis il faudrait aussi faire en sorte que noemie se synchronise
sur ton NS primaire et serve la même version de la zone. D'une part au
cas où l'incohérence entre les NS bloquerait l'enregistrement des
nouveaux NS par l'AFNIC, et d'autre part car même dans le cas contraire
noemie ne servira pas les bonnes informations.

Bien vu. À force de jouer...
Le serial de la zone sur noemie (2019071502) est supérieur à celui sur
tes NS (2019071405), ce qui n'incite pas noemie à se mettre à jour même
s'il est configuré en esclave de ton NS primaire. Tu pourrais
incrémenter le serial sur ton NS primaire et voir si noemie répond
positivement au NOTIFY et se synchronise. Si ça n'a rien changé au bout
du délai de refresh (6h), il faudrait recontacter Nerim.

Le serial sur *.nerim.net a été mis en place par Nerim. Je viens de
mettre mon DNS au même niveau. Mais noemie pique actuellement ses
informations sur maridia et non chez moi (solution d'urgence mise en
place en début de semaine...).
Idéalement il faudrait aussi que maridia ne fasse plus autorité pour la
zone au cas où quelqu'un l'utiliserait encore comme DNS récursif.

Maridia doit dégager dès que les NS seront mis en place
correctement...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Avatar
Pascal Hambourg
Le 20/07/2019 à 13:17, JKB a écrit :
Le Sat, 20 Jul 2019 11:59:05 +0200,
Pascal Hambourg écrivait :
Le serial de la zone sur noemie (2019071502) est supérieur à celui sur
tes NS (2019071405), ce qui n'incite pas noemie à se mettre à jour même
s'il est configuré en esclave de ton NS primaire. Tu pourrais
incrémenter le serial sur ton NS primaire et voir si noemie répond
positivement au NOTIFY et se synchronise. Si ça n'a rien changé au bout
du délai de refresh (6h), il faudrait recontacter Nerim.

Le serial sur *.nerim.net a été mis en place par Nerim. Je viens de
mettre mon DNS au même niveau.

Ça ne suffit pas. Pour déclencher une synchronisation il faut que le
serial du NS primaire soit supérieur à celui du NS secondaire.
Mais noemie pique actuellement ses
informations sur maridia et non chez moi

Dans ce cas il faut faire corriger cela au plus vite.
1 2 3 4 5