# Debian 10 - bind9 problème de résolution

**URL:** <https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292>\
**Category:** Support Debian\
**Tags:** installation, dns, configuration\
**Created:** [Septembre 29, 2019, 8:09 UTC](https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292 "2019-09-29T20:09:30Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![HujinoKun](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/45deac/32.png) [@HujinoKun](https://www.debian-fr.org/u/HujinoKun)\
**Post date:** [Septembre 29, 2019, 8:09 UTC](https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292/1 "2019-09-29T20:09:31Z")

</div>

Bonjour,

je viens d’installer et de configurer mes deux VMs avec bind9 (master / slave), la résolution interne fonctionne à merveille, cependant, impossible de résoudre un nom dns externe.

> **named.conf.options**
>
> root@ns01:~# cat /etc/bind/named.conf.options  
> acl goodclients {  
> localhost;  
> localnets;  
> 192.168.1.0/24;  
> };
> 
> options {  
> directory “/var/cache/bind”;
> 
> ```
> // If there is a firewall between you and nameservers you want
> // to talk to, you may need to fix the firewall to allow multiple
> // ports to talk. See http://www.kb.cert.org/vuls/id/800113
> 
> // 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.
> auth-nxdomain no;
> forward first;
> forwarders { 8.8.8.8; 8.8.4.4; };
> //listen on { ; };
> //listen-on port 53 { localhost; 192.168.1.15; };
> allow-query { goodclients; };
> allow-recursion { localhost; goodclients; };
> allow-query-cache { localhost; goodclients; };
> allow-transfer { 192.168.1.15; };
> recursion no;
> 
> //========================================================================
> // If BIND logs error messages about the root key being expired,
> // you will need to update your keys. See https://www.isc.org/bind-keys
> //========================================================================
> dnssec-validation auto;
> 
> //listen-on-v6 { any; };
> 
> ```
> 
> };

> **named.conf.local**
>
> root@ns01:~# cat /etc/bind/named.conf.local  
> //  
> // Do any local configuration here  
> //
> 
> // Consider adding the 1918 zones here, if they are not used in your  
> // organization  
> //include “/etc/bind/zones.rfc1918”;
> 
> zone “int.local” {  
> type master;  
> file “/etc/bind/db.int.local”;  
> allow-transfer { 192.168.1.15; };  
> also-notify { 192.168.1.15; };  
> };
> 
> zone “0.168.192.in-addr.arpa” {  
> type master;  
> file “/etc/bind/db.0.168.192”;  
> allow-transfer { 192.168.1.15; };  
> also-notify { 192.168.1.15; };  
> };

> **status du service bind9**
>
> root@ns01:~# systemctl status bind9  
> ● bind9.service - BIND Domain Name Server  
> Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)  
> Active: active (running) since Sun 2019-09-29 21:10:27 CEST; 57min ago  
> Docs: man:named(8)  
> Process: 396 ExecStart=/usr/sbin/named $OPTIONS (code=exited, status=0/SUCCESS)  
> Main PID: 418 (named)  
> Tasks: 4 (limit: 1147)  
> Memory: 15.2M  
> CGroup: /system.slice/bind9.service  
> └─418 /usr/sbin/named -u bind
> 
> sept. 29 21:10:27 ns01 named[418]: zone int.local/IN: loaded serial 6  
> sept. 29 21:10:27 ns01 named[418]: zone localhost/IN: loaded serial 2  
> sept. 29 21:10:27 ns01 named[418]: all zones loaded  
> sept. 29 21:10:27 ns01 systemd[1]: Started BIND Domain Name Server.  
> sept. 29 21:10:27 ns01 named[418]: running  
> sept. 29 21:10:27 ns01 named[418]: zone 0.168.192.in-addr.arpa/IN: sending notifies (serial 21)  
> sept. 29 21:10:27 ns01 named[418]: zone int.local/IN: sending notifies (serial 6)  
> sept. 29 21:10:27 ns01 named[418]: managed-keys-zone: Key 20326 for zone . acceptance timer complete: key now trusted  
> sept. 29 21:10:28 ns01 named[418]: resolver priming query complete  
> sept. 29 21:10:39 ns01 named[418]: client @ 192.168.1.15#45599: received notify for zone ‘0.168.192.in-addr.arpa’

RAS dans la log “syslog”

Avez-vous une idée d’où ça peut venir ? Ai-je mal configurer quelques choses ?

En vous remerciant par avance,

---

<div class="post-metadata">

**Author:** ![valde](https://www.debian-fr.org/user_avatar/www.debian-fr.org/valde/32/8087_2.png) [@valde](https://www.debian-fr.org/u/valde)\
**Post date:** [Septembre 29, 2019, 8:45 UTC](https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292/2 "2019-09-29T20:45:58Z")

</div>

Je ne suis pas certain que mettre en forwarder les DNS de google suffise.  
Sauf si les DNS de google autorise tes DNS à forwarder tes reqûetes mais j’en doute 😛

---

<div class="post-metadata">

**Author:** ![HujinoKun](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/45deac/32.png) [@HujinoKun](https://www.debian-fr.org/u/HujinoKun)\
**Post date:** [Septembre 29, 2019, 8:47 UTC](https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292/3 "2019-09-29T20:47:08Z")

</div>

Hello,

Connais-tu des providers qui l’autorisent ?

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Septembre 29, 2019, 10:07 UTC](https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292/4 "2019-09-29T22:07:44Z")

</div>

> [@HujinoKun](#):
>
> impossible de résoudre un nom dns externe

Cette phrase ne contient aucune information utile. Un minimum aurait été la sortie détaillée de `host` ou `dig` lors de la résolution d’un nom externe.

> [@valde](#):
>
> Sauf si les DNS de google autorise tes DNS à forwarder tes reqûetes mais j’en doute

Pourquoi en doutes-tu ? Les DNS récursifs de Google sont ouverts et répondent à tout le monde et se fichent bien que les requêtes soient faites directement par un client ou forwardées par un autre serveur récursif. D’autre part même dans le cas contraire, avec l’option `forward first` si BIND n’obtenait pas de réponse des forwarders il ferait la résolution récursive lui-même.

Je m’intéresserais plutôt à l’option `recursion no`.

---

<div class="post-metadata">

**Author:** ![valde](https://www.debian-fr.org/user_avatar/www.debian-fr.org/valde/32/8087_2.png) [@valde](https://www.debian-fr.org/u/valde)\
**Post date:** [Septembre 30, 2019, 5:30 UTC](https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292/5 "2019-09-30T05:30:14Z")

</div>

> [@PascalHambourg](#):
>
> Pourquoi en doutes-tu ? Les DNS récursifs de Google sont ouverts et répondent à tout le monde et se fichent bien que les requêtes soient faites directement par un client ou forwardées par un autre serveur récursif. D’autre part même dans le cas contraire, avec l’option `forward first` si BIND n’obtenait pas de réponse des forwarders il ferait la résolution récursive lui-même.

Et bien tu vois, voilà pourquoi le mot «&nbsp;doute&nbsp;» 😛  
Je ne savais, je pensais que le problème viendrait de là.

> [@PascalHambourg](#):
>
> Je m’intéresserais plutôt à l’option `recursion no` .

Je cite : «&nbsp;Autorise les requêtes clientes récursives sur le serveur. Auquel cas, si la réponse n’est pas connue du serveur, c’est-à-dire si le serveur n’est pas autoritaire pour la zone concernée, ce dernier agit alors comme un relais et les serveurs racines (root) seront consultés, sauf si des forwarders ont été définis et paramétrés pour être consultés en priorité (forward first ou only).&nbsp;»

C’est bien là le soucis donc.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Septembre 30, 2019, 7:00 UTC](https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292/6 "2019-09-30T07:00:32Z")

</div>

Dans named.conf.options

> [@HujinoKun](#):
>
> recursion no;

Ca ne serait pas mieux avec yes ?

---

<div class="post-metadata">

**Author:** ![HujinoKun](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/h/45deac/32.png) [@HujinoKun](https://www.debian-fr.org/u/HujinoKun)\
**Post date:** [Octobre 1, 2019, 4:29 UTC](https://www.debian-fr.org/t/debian-10-bind9-probleme-de-resolution/80292/7 "2019-10-01T16:29:34Z")

</div>

> **named.conf.options**
>
> acl goodclients {  
> localhost;  
> localnets;  
> 192.168.1.0/24;  
> };
> 
> options {  
> directory “/var/cache/bind”;
> 
> ```
> // If there is a firewall between you and nameservers you want
> // to talk to, you may need to fix the firewall to allow multiple
> // ports to talk. See http://www.kb.cert.org/vuls/id/800113
> 
> // 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.
> auth-nxdomain no;
> forward only;
> forwarders { 8.8.8.8; 8.8.4.4; };
> //listen on { ; };
> //listen-on port 53 { localhost; 192.168.1.15; };
> allow-query { goodclients; };
> allow-recursion { localhost; goodclients; };
> allow-query-cache { localhost; goodclients; };
> allow-transfer { 192.168.1.15; };
> recursion yes;
> 
> //========================================================================
> // If BIND logs error messages about the root key being expired,
> // you will need to update your keys. See https://www.isc.org/bind-keys
> //========================================================================
> dnssec-validation auto;
> 
> //listen-on-v6 { any; };
> 
> ```
> 
> };

Après vos dires et mes recherches sur internet, en activant l’option recursion tout fonctionne.

Merci de votre aide !
