OVH Cloud OVH Cloud

[HS] Sur quoi écoute Bind ?

28 réponses
Avatar
Ph. Gras
Bonsoir,

# netstat -antp
Connexions Internet actives (serveurs et =E9tablies)
Proto Recv-Q Send-Q Adresse locale Adresse distante =
Etat PID/Program name
tcp 0 0 127.0.0.1:953 =
0.0.0.0:* LISTEN 764/named =20=

tcp 0 0 5.196.73.219:53 =
0.0.0.0:* LISTEN 764/named =20=

tcp 0 0 127.0.0.1:53 =
0.0.0.0:* LISTEN =
764/named =20
tcp6 0 0 =
2001:41d0:e:7db::1:53 :::* LISTEN =
764/named =20
tcp6 0 0 ::1:53 =
:::* LISTEN =
764/named =20

D'apr=E8s vous, sur quelles adresses =E9coute Bind9 ?

Y a-t-il une utilit=E9 pour qu'il =E9coute n'importe qui ?

J'ai lu des =E9chos, comme quoi les adresses ipv4 et ipv6 seraient =
incompatibles.
Qu'en pensez-vous ?

D'avance, je vous remercie.

Ph. Gras=

10 réponses

1 2 3
Avatar
Pascal Hambourg
Le 19/08/2016 à 19:15, Ph. Gras a écrit :
D'après vous, sur quelles adresses écoute Bind9 ?

Celles sur lesquelle on lui dit d'écouter. Par défaut, toutes.
Y a-t-il une utilité pour qu'il écoute n'importe qui ?

Ça dépend de son rôle.
J'ai lu des échos, comme quoi les adresses ipv4 et ipv6 seraient incompatibles.
Qu'en pensez-vous ?

Qu'en tant que telle cette phrase ne veut rien dire.
Autant dire qu'un train et un bateau sont incompatibles.
Avatar
Ph. Gras
Merci Pascal,
Le 19/08/2016 à 19:15, Ph. Gras a écrit :
D'après vous, sur quelles adresses écoute Bind9 ?

Celles sur lesquelle on lui dit d'écouter. Par défaut, toutes.
Y a-t-il une utilité pour qu'il écoute n'importe qui ?

Ça dépend de son rôle.
J'ai lu des échos, comme quoi les adresses ipv4 et ipv6 seraient incompatibles.
Qu'en pensez-vous ?

Qu'en tant que telle cette phrase ne veut rien dire.
Autant dire qu'un train et un bateau sont incompatibles.

Je vais me renseigner.
Ph. Gras=
Avatar
Ph. Gras
Bonsoir,
# netstat -antp
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp6 0 0 ::1:53 :::* LISTEN 764/named <= <=

Je n'ai pas compris ce qui commande cette écoute =>
https://wiki.debian.org/fr/Bind9
Si vous avez une idée…
D'avance, je vous remercie.
Ph. Gras=
Avatar
Christophe
Hello,
Le 19/08/2016 à 22:40, Ph. Gras a écrit :
Bonsoir,
# netstat -antp
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp6 0 0 ::1:53 :::* LISTEN 764/named <= < >>

Je n'ai pas compris ce qui commande cette écoute =>
https://wiki.debian.org/fr/Bind9
Si vous avez une idée…
D'avance, je vous remercie.
Ph. Gras

Non mais stop la !
Que veux tu faire au juste ???
1 : Tu veux retirer toute écoute de bind ?
ou
2 : L'écoute sur ::1 de bind est dérangeante ??
ou
3 : tu veux que bind écoute une interface ou adresse IP en particulier ???
Le contexte précisé est totalement inadéquat (parce qu'inexistant) pour
une telle question ...
Accessoirement ::1 (en IPv6) correspond ni plus ni moins à 127.0.0.1 (en
IPv4) à savoir "localhost".
Sur le cas 1 : tu arrêtes le service bind, voire, tu le retires !
Sur le cas 2 (si cas 1 non rempli): il faut largement plus d'infos pour
comprendre ce que tu cherches à faire ...
Sur le cas 3 : je doute sérieusement que tu puisses te passer de
"localhost" avec bind ...
@+
Christophe.
Avatar
Pascal Hambourg
Le 19/08/2016 à 22:40, Ph. Gras a écrit :
# netstat -antp
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp6 0 0 ::1:53 :::* LISTEN 764/named <= < >>

Je n'ai pas compris ce qui commande cette écoute =>

Le contenu de la directive listen-on-v6 qui doit inclure ::1 ou
"localhost" (toutes les adresses locales).
https://wiki.debian.org/fr/Bind9
Si vous avez une idée…
D'avance, je vous remercie.
Ph. Gras
Avatar
Ph. Gras
Bonjour Pascal,
Bonjour à toutes et à tous,
# netstat -antp
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp6 0 0 ::1:53 :::* LISTEN 764/named <= <=

Je n'ai pas compris ce qui commande cette écoute =>

Le contenu de la directive listen-on-v6 qui doit inclure ::1 ou "localhost" (toutes les adresses locales).

Je me suis demandé si les écoutes sur :
tcp 0 0 5.196.73.219:53 0.0.0.0:* LISTEN 764/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 764/named
ne suffisaient pas. Mais je n'avais pas remarqué que les unes s'effectuaient sur TCP, tandis que l'autre
est branchée sur TCP6 (… il faudra que je me renseigne sur leurs spécificités respectives, merci de ne
pas spoiler).
Par ailleurs, j'ai appris que Bind pouvait recevoir des requêtes avec UDP, ce que je n'ai pas vu avec la
commande netstat -antp (peut-être que -t ou -p signifient TCP ?, je vais vérifier -- motus).
Merci pour vos réponses,
Ph. Gras=
Avatar
Ph. Gras
Bonjour,
toujours dans mes élucubrations bindesques, j'ai compris dans cet article :
http://www.mathieupeloquin.com/fr/2010/05/utilisation-de-base-de-iptables/
qu'il fallait que bind9 écoute l'extérieur, mais n'envoie pas de requêtes :
========================= ========================= ========
# DNS TCP et UDP et RNDC
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 953 -j ACCEPT
========================= ========================= ========
Or, j'ai eu à mon sens de ce fait, plein d'erreurs de ce type :
========================= ========================= ========
Aug 21 22:42:14 ns3001166 named[9847]: error (host unreachable) resolving 'arpa/DS/IN': 192.5.5.241#53
Aug 21 22:42:14 ns3001166 named[9847]: error (host unreachable) resolving 'in-addr.arpa/DS/IN': 199.7.91.13#53
Aug 21 22:42:14 ns3001166 named[9847]: error (host unreachable) resolving 'in-addr.arpa/DS/IN': 192.58.128.30#53
Aug 21 22:42:14 ns3001166 named[9847]: error (host unreachable) resolving 'arpa/DNSKEY/IN': 192.203.230.10#53
Aug 21 22:42:14 ns3001166 named[9847]: error (host unreachable) resolving '82.in-addr.arpa/DS/IN': 199.7.83.42#53
Aug 21 22:42:14 ns3001166 named[9847]: error (host unreachable) resolving '82.in-addr.arpa/DS/IN': 192.112.36.4#53
Aug 21 22:42:15 ns3001166 named[9847]: error (host unreachable) resolving 'in-addr.arpa/DNSKEY/IN': 196.216.169.10#53
Aug 21 22:42:15 ns3001166 named[9847]: error (host unreachable) resolving 'in-addr.arpa/DNSKEY/IN': 199.253.183.183#53
Aug 21 22:42:15 ns3001166 named[9847]: error (host unreachable) resolving '124.82.in-addr.arpa/DS/IN': 200.10.60.53#53
Aug 21 22:42:15 ns3001166 named[9847]: error (host unreachable) resolving '124.82.in-addr.arpa/DS/IN': 192.5.4.1#53
========================= ========================= ========
D'autre part, je n'arrivais pas à avoir de réponse avec host, nslookup, etc.
Qu'en pensez-vous ?
ne suffisaient pas. Mais je n'avais pas remarqué que les unes s'effectuaient sur TCP, tandis que l'autre
est branchée sur TCP6 (… il faudra que je me renseigne sur leurs spécificités respectives, merci de ne
pas spoiler).

Ça, c'est vu.
Par ailleurs, j'ai appris que Bind pouvait recevoir des requêtes avec UDP, ce que je n'ai pas vu avec la
commande netstat -antp (peut-être que -t ou -p signifient TCP ?, je vais vérifier -- motus).

C'est réglé aussi.
Au plaisir,
Ph. Gras
Avatar
Ph. Gras
Hello !
Or, j'ai eu à mon sens de ce fait, plein d'erreurs de ce type :
D'autre part, je n'arrivais pas à avoir de réponse avec host, nslookup, etc.
Qu'en pensez-vous ?

je me réponds à moi-même, car je viens de comprendre mon erreur :
Au lieu de tout ouvrir au départ comme le propose Matthieu Péloquin
j'ai tout fermé dans Netfilter, ce qui provoquait cette erreur chez moi…
et pas chez lui, qui ferme tout à la fin.
Reste à savoir quelle est la meilleure méthode : au début ou à la fin ?
Bonne journée,
Ph. Gras=
Avatar
Pascal Hambourg
Le 22/08/2016 à 13:31, Ph. Gras a écrit :
Bonjour,
toujours dans mes élucubrations bindesques, j'ai compris dans cet article :
http://www.mathieupeloquin.com/fr/2010/05/utilisation-de-base-de-iptables/
qu'il fallait que bind9 écoute l'extérieur, mais n'envoie pas de requêtes :

Encore une fois, ça dépend de son rôle, et donc de sa configuration.
S'il joue le rôle d'une serveur faisant autorité totalement isolé, avec
sa propre zone racine, sans serveur secondaire à notifier, il n'a pas
besoin d'envoyer de requêtes.
Dans les autres cas, serveur récursif ou serveur faisant autorité non
isolé, il a besoin d'envoyer des requêtes. En serveur récursif, c'est
nécessaire pour faire suivre les requêtes qu'il reçoit. En serveur
faisant autorité, il peut avoir besoin d'envoyer des requêtes pour
récupérer la liste à jour des NS de la zone racine ou notifier une
modification de zone à un serveur secondaire.
Avatar
S
Bonjour,
Le lundi 22 août 2016 à 14:47, Ph. Gras a écrit :
je me réponds à moi-même, car je viens de comprendre mon erreur :
Au lieu de tout ouvrir au départ comme le propose Matthieu Péloquin
j'ai tout fermé dans Netfilter, ce qui provoquait cette erreur chez moi…
et pas chez lui, qui ferme tout à la fin.
Reste à savoir quelle est la meilleure méthode : au début ou à la fin ?

Il est toujours préférable de tout interdire et d’autoriser au cas par cas. Si
on fait l’inverse, on court le risque qu’un cas qu’on n’avait pas prévu permette
de rentrer.
Sébastien
1 2 3