// 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.
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
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
Et les DNS qui ne se propagent toujours pas, ce qui me permettrait d'avoir au moins les deux masters actuels ! Qu'est-ce qu'ils foutent, chez Amen ?! Dans l'interface, j'ai les bons DNS, mais rien ne se passe.
Je me demande si le fait que les NS de la zone ne soient pas cohérents n'y serait pas pour quelque chose.
Possible. Quoi qu'il en soit, cela fait 72 heures que j'attends la modification de l'AFNIC et ça comment à être long. Entre temps, j'ai eu le support de Nérim qui a récupéré la zone à la main depuis maridia et qui a repris le DNS primaire le temps que cette modification des DNS autoritaires soit effective !...
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Le 16/07/2019 à 09:05, JKB a écrit :
Et les DNS qui ne se propagent toujours pas, ce qui me permettrait
d'avoir au moins les deux masters actuels ! Qu'est-ce qu'ils
foutent, chez Amen ?! Dans l'interface, j'ai les bons DNS, mais rien
ne se passe.
Je me demande si le fait que les NS de la zone ne soient pas cohérents
n'y serait pas pour quelque chose.
Possible. Quoi qu'il en soit, cela fait 72 heures que j'attends la
modification de l'AFNIC et ça comment à être long. Entre temps, j'ai
eu le support de Nérim qui a récupéré la zone à la main depuis
maridia et qui a repris le DNS primaire le temps que cette
modification des DNS autoritaires soit effective !...
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne
correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique
son zonecheck aux demandes de modification de NS, ça ne risque pas de
changer...
Et les DNS qui ne se propagent toujours pas, ce qui me permettrait d'avoir au moins les deux masters actuels ! Qu'est-ce qu'ils foutent, chez Amen ?! Dans l'interface, j'ai les bons DNS, mais rien ne se passe.
Je me demande si le fait que les NS de la zone ne soient pas cohérents n'y serait pas pour quelque chose.
Possible. Quoi qu'il en soit, cela fait 72 heures que j'attends la modification de l'AFNIC et ça comment à être long. Entre temps, j'ai eu le support de Nérim qui a récupéré la zone à la main depuis maridia et qui a repris le DNS primaire le temps que cette modification des DNS autoritaires soit effective !...
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Tiens, Pascal. Comme tu parles de vues. Il y a un truc que je ne pige pas. J'ai déclaré : acl "lans" { 192.168.0.0/16; 127.0.0.1; }; Dans les vues, j'ai donc une vue : view "internal" { match-clients { "lans"; }; ... }; et j'ai voulu écrire : view "external" { match-client { ! "lans"; }; ... }; Ça ne fonctionne pas. Je me prends un : 15-Jul-2019 10:59:38.949 client @0x7ff04c4e5830 213.41.150.218#50990 (rayleigh.systella.fr): view external local: query (cache) 'rayleigh.systella.fr/A/IN' denied
Concrètement, quel résultat attendais-tu et quel résultat as-tu obtenu ? D'après le log, on dirait bien que c'est la vue "external" qui a été sélectionnée, non ?
J'aimerais que la vue 'external' ne chevauche pas 'internal'. Ça me semblerait plus propre.
Ça dépend comment on voit les choses. J'ai aussi deux vues, "internal" pour mes propres réseaux et "external" pour le reste du monde, que je considère comme la vue par défaut d'où le "any".
Si je remplace match-client { ! "lans"; }; par match-client { any; }; ça fonctionne, mais pour moi, le contraire de "lans";, c'est ! "lans";.
Pour info, j'ai aussi utilisé "any" dans ma vue externe, placée en dernier.
Je suppose qu'il y a un truc qui m'a échappé.
Je ne suis pas sûr et je n'ai plus la doc sous la main pour vérifier, mais il me semble qu'il y a une subtilité dans l'interprétation de "!". Si je me souviens bien, ça n'inverse pas seulement la correspondance qui suit mais ça veut dire que si la correspondance est vraie alors le résultat est faux et l'évaluation s'arrête là. Par exemple je vois que dans mon fichier de conf j'ai écrit ceci : listen-on { ! x.x.x.x/30; any; }; ("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 ?
Concrètement, quel résultat attendais-tu et quel résultat as-tu obtenu ?
D'après le log, on dirait bien que c'est la vue "external" qui a été
sélectionnée, non ?
J'aimerais que la vue 'external' ne chevauche pas 'internal'. Ça me
semblerait plus propre.
Ça dépend comment on voit les choses. J'ai aussi deux vues, "internal"
pour mes propres réseaux et "external" pour le reste du monde, que je
considère comme la vue par défaut d'où le "any".
Si je remplace match-client { ! "lans"; }; par match-client { any; };
ça fonctionne, mais pour moi, le contraire de "lans";, c'est !
"lans";.
Pour info, j'ai aussi utilisé "any" dans ma vue externe, placée en dernier.
Je suppose qu'il y a un truc qui m'a échappé.
Je ne suis pas sûr et je n'ai plus la doc sous la main pour vérifier,
mais il me semble qu'il y a une subtilité dans l'interprétation de "!".
Si je me souviens bien, ça n'inverse pas seulement la correspondance qui
suit mais ça veut dire que si la correspondance est vraie alors le
résultat est faux et l'évaluation s'arrête là. Par exemple je vois que
dans mon fichier de conf j'ai écrit ceci :
listen-on { ! x.x.x.x/30; any; };
("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 ?
Tiens, Pascal. Comme tu parles de vues. Il y a un truc que je ne pige pas. J'ai déclaré : acl "lans" { 192.168.0.0/16; 127.0.0.1; }; Dans les vues, j'ai donc une vue : view "internal" { match-clients { "lans"; }; ... }; et j'ai voulu écrire : view "external" { match-client { ! "lans"; }; ... }; Ça ne fonctionne pas. Je me prends un : 15-Jul-2019 10:59:38.949 client @0x7ff04c4e5830 213.41.150.218#50990 (rayleigh.systella.fr): view external local: query (cache) 'rayleigh.systella.fr/A/IN' denied
Concrètement, quel résultat attendais-tu et quel résultat as-tu obtenu ? D'après le log, on dirait bien que c'est la vue "external" qui a été sélectionnée, non ?
J'aimerais que la vue 'external' ne chevauche pas 'internal'. Ça me semblerait plus propre.
Ça dépend comment on voit les choses. J'ai aussi deux vues, "internal" pour mes propres réseaux et "external" pour le reste du monde, que je considère comme la vue par défaut d'où le "any".
Si je remplace match-client { ! "lans"; }; par match-client { any; }; ça fonctionne, mais pour moi, le contraire de "lans";, c'est ! "lans";.
Pour info, j'ai aussi utilisé "any" dans ma vue externe, placée en dernier.
Je suppose qu'il y a un truc qui m'a échappé.
Je ne suis pas sûr et je n'ai plus la doc sous la main pour vérifier, mais il me semble qu'il y a une subtilité dans l'interprétation de "!". Si je me souviens bien, ça n'inverse pas seulement la correspondance qui suit mais ça veut dire que si la correspondance est vraie alors le résultat est faux et l'évaluation s'arrête là. Par exemple je vois que dans mon fichier de conf j'ai écrit ceci : listen-on { ! x.x.x.x/30; any; }; ("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 ?
Et les DNS qui ne se propagent toujours pas, ce qui me permettrait d'avoir au moins les deux masters actuels ! Qu'est-ce qu'ils foutent, chez Amen ?! Dans l'interface, j'ai les bons DNS, mais rien ne se passe.
Je me demande si le fait que les NS de la zone ne soient pas cohérents n'y serait pas pour quelque chose.
Possible. Quoi qu'il en soit, cela fait 72 heures que j'attends la modification de l'AFNIC et ça comment à être long. Entre temps, j'ai eu le support de Nérim qui a récupéré la zone à la main depuis maridia et qui a repris le DNS primaire le temps que cette modification des DNS autoritaires soit effective !...
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Visiblement, le problème vient de chez Amen. Je viens d'avoir un mail du style "oups, on a merdé, veuillez nous excuser...". Je ne comprends pas pourquoi la zone ne correspondrait pas (et en quoi). 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
Et les DNS qui ne se propagent toujours pas, ce qui me permettrait
d'avoir au moins les deux masters actuels ! Qu'est-ce qu'ils
foutent, chez Amen ?! Dans l'interface, j'ai les bons DNS, mais rien
ne se passe.
Je me demande si le fait que les NS de la zone ne soient pas cohérents
n'y serait pas pour quelque chose.
Possible. Quoi qu'il en soit, cela fait 72 heures que j'attends la
modification de l'AFNIC et ça comment à être long. Entre temps, j'ai
eu le support de Nérim qui a récupéré la zone à la main depuis
maridia et qui a repris le DNS primaire le temps que cette
modification des DNS autoritaires soit effective !...
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne
correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique
son zonecheck aux demandes de modification de NS, ça ne risque pas de
changer...
Visiblement, le problème vient de chez Amen. Je viens d'avoir un
mail du style "oups, on a merdé, veuillez nous excuser...".
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en
quoi).
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
Et les DNS qui ne se propagent toujours pas, ce qui me permettrait d'avoir au moins les deux masters actuels ! Qu'est-ce qu'ils foutent, chez Amen ?! Dans l'interface, j'ai les bons DNS, mais rien ne se passe.
Je me demande si le fait que les NS de la zone ne soient pas cohérents n'y serait pas pour quelque chose.
Possible. Quoi qu'il en soit, cela fait 72 heures que j'attends la modification de l'AFNIC et ça comment à être long. Entre temps, j'ai eu le support de Nérim qui a récupéré la zone à la main depuis maridia et qui a repris le DNS primaire le temps que cette modification des DNS autoritaires soit effective !...
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Visiblement, le problème vient de chez Amen. Je viens d'avoir un mail du style "oups, on a merdé, veuillez nous excuser...". Je ne comprends pas pourquoi la zone ne correspondrait pas (et en quoi). 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
("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 ?
Non. 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
("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 ?
Non.
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
("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 ?
Non. 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
Pascal Hambourg
Le 17/07/2019 à 10:26, JKB a écrit :
Pascal Hambourg écrivait :
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes. 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).
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne
correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique
son zonecheck aux demandes de modification de NS, ça ne risque pas de
changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en
quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes.
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).
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes. 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).
("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 ?
("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 ?
("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 ?
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes. 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... 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
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne
correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique
son zonecheck aux demandes de modification de NS, ça ne risque pas de
changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en
quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes.
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...
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
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes. 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... 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
("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". 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
("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".
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
("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". 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
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes. 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.
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne
correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique
son zonecheck aux demandes de modification de NS, ça ne risque pas de
changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en
quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes.
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...
L'ennui, c'est que la zone servie par les serveurs DNS de Nerim ne correspond pas à celle servie par tes serveurs DNS. Si l'AFNIC applique son zonecheck aux demandes de modification de NS, ça ne risque pas de changer...
Je ne comprends pas pourquoi la zone ne correspondrait pas (et en quoi).
En quoi : le SOA (dont le serial) et les NS ne sont pas les mêmes. 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.
("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".
("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".
("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".
