Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

Pages : 1

#1 Le 04/02/2018, à 15:16

diesel

[RESOLU] Problème de résolution de noms

Bonjour,

J'ai un petit problème avec la résolution de noms sur mon réseau local.

J'ai un serveur sous ubuntu 16.04LTS server et un client sous ubuntu 17.10desktop

Sur mon serveur, je fais tourner bind9 pour la résolution de noms locale. Tout fonctionne très bien depuis longtemps (y compris la résolution des noms sur internet : Un : "host www.ubuntu.org" donnera bien : "www.ubuntu.org has address 82.98.134.233"), que ce soit sur le serveur ou le client.

Mon réseau local s'appelle monreseau et comporte deux machines : monserveur.monreseau et monclient.monreseau

sur le serveur, j'ai (entre autres) les fichiers de zone suivants :

db.monreseau :

$TTL	86400
@		IN	SOA	monserveur.monreseau.	root.monserveur.monreseau. (
					200212111	; Numéro de série
					43200		; Rafraîchissement
					3600		; Nouvelle tentative
					3600000		; Expiration
					2592000 )	; Minimum

		IN	NS	monserveur.monreseau.

monserveur	IN	A	192.168.0.1
monclient	IN	A	192.168.0.2

db.0.168.192 :

$TTL    86400
@		IN	SOA	monserveur.monreseau.	root.monserveur.monreseau. (
					200212111	; Numéro de série
					43200		; Rafraîchissement
					3600		; Nouvelle tentative
					3600000		; Expiration
					2592000 )	; Minimum

		IN	NS	monserveur.monreseau.

1		IN      PTR     monserveur.monreseau.
2		IN      PTR     monclient.monreseau.

Afin de partager mon imprimante branchée à mon serveur, j'ai besoin de résoudre l'adresse locale monserveur.local. J'ai donc ajouté une zone sur laquelle je suis maître et modifié la zone 0.168.192, ce qui donne :

named.conf.local :

zone "monreseau" IN {
	type master;
	file "/etc/bind/db.monreseau";
	allow-update { none; };
};

zone "local" IN {
        type master;
        file "/etc/bind/db.local";
        allow-update { none; };
};

zone "0.168.192.in-addr.arpa" IN {
	type master;
	file "/etc/bind/db.0.168.192";
	allow-update { none; };
};

db.local :

$TTL	86400
@		IN	SOA	monserveur.monreseau.	root.monserveur.monreseau. (
					200212111	; Numéro de série
					43200		; Rafraîchissement
					3600		; Nouvelle tentative
					3600000		; Expiration
					2592000 )	; Minimum

		IN	NS	monserveur.monreseau.

monserveur	IN	A	192.168.0.1

db.0.168.192 :

$TTL    86400
@		IN	SOA	monserveur.monreseau.	root.monserveur.monreseau. (
					200212111	; Numéro de série
					43200		; Rafraîchissement
					3600		; Nouvelle tentative
					3600000		; Expiration
					2592000 )	; Minimum

		IN	NS	monserveur.monreseau.

1		IN      PTR     monserveur.monreseau.
1		IN      PTR     monserveur.local.
2		IN      PTR     monclient.monreseau.

Après un redémarrage de bind9, tout fonctionne parfaitement sur mon serveur, ce qui veut au moins dire que bind9 a bien redémarré. En particulier, un "host monserveur.local" me donne bien "monserveur.local has address 192.168.0.1"

Par contre sur mon client, autant je peux continuer à résoudre toutes mes adresse "habituelles" monserveur.monreseau, par exemple ou un serveur sur internet, une requète "host monserveur.local" se traduit par un "Host passerelle.local not found: 2(SERVFAIL)".

Je précise que dans mon fichier dhcpd.conf, j'ai les lignes suivantes (ça a peut-être une influence) :

subnet 192.168.0.0 netmask 255.255.255.0 {

        allow unknown-clients;
        option broadcast-address 192.168.0.255;
        option routers 192.168.0.1;
        option domain-name "monreseau";
        option domain-name-servers 192.168.0.1;

Voilà. Si quelqu'un a une idée de ce qui cloche dans ma configuration, je suis preneur.

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 08/02/2018, à 09:39)

Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.

Hors ligne

#2 Le 06/02/2018, à 15:14

bruno

Re : [RESOLU] Problème de résolution de noms

Bonjour,

C'est tordu comme configuration…
Première chose, normalement le TLD .local est réservé au protocole mDNS (RFC 6762), il vaut donc mieux éviter de l'utiliser avec un résoveur faisant autorité si on veut éviter des conflits…

D'autre part la configuration de bind9 fournie par Debian/Ubuntu utilise le fichier db.local pour résoudre l'adresse de bouclage (127.0.0.1, ::1; localhost). Je ne suis pas sûr que ce soit une bonne idée de supprimer cette configuration.

De toute façon ton fichier db.local ne permet pas de résoudre le nom monserveur.local

Pour finir, utiliser bind9 pour résoudre deux adresses sur un réseau local, c'est comme utiliser une arme thermonucléaire pour tuer un acarien. big_smile

Explique-nous pourquoi tu as besoin de cela juste pour partager une imprimante (normalement c'est le rôle de CUPS).

#3 Le 06/02/2018, à 16:32

diesel

Re : [RESOLU] Problème de résolution de noms

Tout d'abord, merci beaucoup pour ta réponse.

Mon problème à la base est le suivant (oublions dans un premier temps le fichier db.local) :

J'ai un réseau local que j'ai baptisé "monreseau". J'ai aussi d'autres réseaux locaux avec d'autres noms. C'est pourquoi j'ai installé et configuré bind9 sur mon serveur.

Sur mon serveur, j'ai installé cups pour pouvoir gérer et partager mon imprimante.

Le problème est  que le process cups-browsed qui se charge de publier mon imprimante sur le réseau s'appuie sur avahi et que celui-ci s'obstine à publier mon imprimante avec la ligne "ipp://monserveur.local/printers/CLP-365". Or, nativement, mon serveur bind9 ne résoud pas les adresses avec un domaine en .local puisque mon réseau s'appelle "monreseau", ce qui fait que les requêtes d'impression venant de mon client n'aboutissent pas. Par contre, sur mon client, si je crée à la main (c'est ce qui fonctionne actuellement) une imprimante réseau avec la ligne "ipp://monserveur.monreseau/printers/CLP365", ça marche parfaitement, sauf que je me retrouve avec deux déclarations d'imprimantes sur mon client, dont une qui ne fonctionne pas.

D'où ma tentative de résoudre le domaine "local" en créant un db.local.

bruno a écrit :

De toute façon ton fichier db.local ne permet pas de résoudre le nom monserveur.local

Ben, "bizarrement", si. Un "host passerelle.local" donne le bon résultat sur le serveur (192.168.0.1) mais me donne un SERVFAIL lorsque je le fais sur le client.

bruno a écrit :

Pour finir, utiliser bind9 pour résoudre deux adresses sur un réseau local, c'est comme utiliser une arme thermonucléaire pour tuer un acarien. big_smile

Sur le segment réseau "monreseau", j'ai plus que 1 serveur et 1 client (j'ai simplifié pour augmenter la lisibilité) et j'ai plusieurs réseaux locaux, d'où le bind9. De plus, bind tourne sur mon serveur depuis longtemps (voir les "numéros de série" des fichiers de zones : 2002) et je ne l'ai pas mis en œuvre juste pour résoudre mon problème actuel.

Finalement, je me demande si le fait que ça ne marche pas sur le client ne vient pas de la config du client elle-même et si le SERFAIL n'est pas envoyé par le résolveur local. Pourtant mon DHCP (sur le serveur) envoie bien l'adresse du serveur comme serveur DNS, mais un cat /riun/NetworkManager/resolv.conf sur le client donne un "search monreseau" et "nameserver 127.0.0.1". Je vais passer un petit coup de tcpdump pour voir qui dit quoi.

J'ai aussi essayé de modifier sur le serveur le fichier /etc/avahi/avahi-daemon.conf en mettant la ligne "domain-name=monreseau", mais ça ne marche pas. Ce coup là, il ne sait plus communiquer avec le client qui, lui, est resté avec sa configuration de base avec un domaine "avahi" en ".local". Et comme j'ai des clients non permanents (des MAC en particulier), je ne peux pas faire la modif partout.

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 06/02/2018, à 17:06)

Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.

Hors ligne

#4 Le 06/02/2018, à 17:43

bruno

Re : [RESOLU] Problème de résolution de noms

Au temps pour moi, ton fichier db.local semble correct, ceci dit tu ne devrais pas utiliser ce TLD car justement cela interfère avec mDNS (avahi, zeroconf, bonjour)

Tes commandes host ne permettent pas de déboguer le souci, utilise des commandes dig :

dig monserveur.local

dig monserveur.local @monserveur.monreseau

Et plutôt que de triturer bind, il serait peut-être plus simple de vérifier que le service d'impression est bien annoncé avec avahi. Il faut regarder si un fichier correspondant existe dans /etc/avahi/services et le cas échéant le créer (cf. https://wiki.archlinux.org/index.php/Av … g_services)

Edit : et aussi voir si tu ne peux pas simplement définir ton nom de serveur dans /etc/avahi/hosts

Dernière modification par bruno (Le 06/02/2018, à 18:00)

#5 Le 06/02/2018, à 21:39

diesel

Re : [RESOLU] Problème de résolution de noms

Bon, j'ai mis en branle tcpdump sur mon client.

Host monserveur.monreseau :

17:22:35.351330 IP monclient.44814 > monserveur.monreseau.domain: 60169+ [1au] A? monserveur.monreseau. (44)
17:22:35.351826 IP monserveur.monreseau.domain > monclient.44814: 60169* 1/0/1 A 192.168.0.1 (60)
17:22:35.352280 IP monclient.38244 > passerelle.delapierre.domain: 8155+ [1au] AAAA? monserveur.monreseau. (44)
17:22:35.352761 IP monserveur.monreseau.domain > monclient.38244: 8155* 0/1/1 (96)
17:22:35.353131 IP monclient.56667 > monserveur.monreseau.domain: 13735+ [1au] MX? monserveur.monreseau. (44)
17:22:35.353597 IP monserveur.monreseau.domain > monclient.56667: 13735* 0/1/1 (96)

Jusque là tout va bien. Une requête DNS standard.

Host monserveur.local :

17:18:20.213705 IP6 monclient.mdns > ff02::fb.mdns: 0 A (QM)? monserveur.local. (34)
17:18:20.213760 IP monclient.mdns > 224.0.0.251.mdns: 0 A (QM)? monserveur.local. (34)
17:18:21.214645 IP6 monclient.mdns > ff02::fb.mdns: 0 A (QM)? monserveur.local. (34)
17:18:21.214699 IP monclient.mdns > 224.0.0.251.mdns: 0 A (QM)? monserveur.local. (34)
17:18:23.217779 IP6 monclient.mdns > ff02::fb.mdns: 0 A (QM)? monserveur.local. (34)
17:18:23.217830 IP monclient.mdns > 224.0.0.251.mdns: 0 A (QM)? monserveur.local. (34)

'tain !. c'est quoi ces processus qui se permettent de court-circuiter la résolution de nom !.
Encore heureux que je n'ai pas donné en son temps le nom de domaine .local à ce sous-réseau.

Maintenant, je comprends pourquoi ça marche sur le serveur et pas sur le client (quoi que, dans la mesure où avahi tourne aussi sur le serveur, pourquoi il laisse bind faire le boulot ?. Il faudra éventuellement que j'essaye de comprendre une autre fois).

Et donc, dans la mesure où c'est avahi qui reçoit les requêtes de résolution de nom pour monserveur.monreseau, il ne me reste plus qu'à virer mon db.local et trouver comment dire à avahi de répondre 192.168.0.1 sur une requête mdns avec le nom passerelle.local.

Vous avouerez quand-même que c'est tordu.

Et pour couronner le tout, sur mon serveur, j'ai mon pare-feu qui me bloque tout le trafic avec une adresse de destination différente de 192.168.0.x (ce qui, au passage, doit expliquer pourquoi ça marche en local sur le serveur et pas à partir du client). Il me reste donc,a priori, à mettre en place une règle spécifique pour mdns et ça devrait fonctionner.

Je viens aussi de me rendre compte qu'il me manquait le fichier db.local (celui qui définit localhost) sur mon serveur, c'est pourquoi il m'a paru tout naturel d'en créer un pour le domaine .local. Je viens de le réinstaller à partir d'une sauvegarde. C'est déjà ça de fait.

En tous cas, merci beaucoup Bruno pour l'éclairage que tu m'as donné qui m'a permis d'avancer rapidement sur la résolution de ce problème. J'y serais peut-être arrivé finalement tout seul mais au bout de combien de temps...

Je vous tiens au courant dès que j'ai trouvé la solution définitive.

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 06/02/2018, à 22:09)

Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.

Hors ligne

#6 Le 07/02/2018, à 19:54

diesel

Re : [RESOLU] Problème de résolution de noms

Bon, on ne doit pas avoir la même définition du zéro (zéroconf).

j'ai les fichiers suivants :

/etc/nsswitch

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat
group:          compat
shadow:         compat
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

/etc/hostname

monserveur

/etc/avahi/avahi-daemon.conf

# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

# See avahi-daemon.conf(5) for more information on this configuration
# file!

[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
#domain-name=delapierre
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000

[wide-area]
enable-wide-area=yes

[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no

[reflector]
#enable-reflector=no
#reflect-ipv=no

[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3

et un ps -ef |grep -i avahi me donne :

avahi     3870     1  0 19:40 ?        00:00:00 avahi-daemon: running [passerelle.local]
avahi     3875  3870  0 19:40 ?        00:00:00 avahi-daemon: chroot helper

Le pare-feu de mon serveur n'a aucune règle concernant l'interface lo.

J'ai reconfiguré mon serveur bind9 comme il était à l'origine (il ne me résoud plus le nom "monserveur.local").

Et pourtant, sur le serveur, si je fais : "host monserveur.local", j'obtiens la réponse : "Host monserveur.local not found: 3(NXDOMAIN)"

AU SECOURS !!!.

Amicalement.

Jean-Marie

Dernière modification par diesel (Le 07/02/2018, à 22:56)

Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.

Hors ligne

#7 Le 08/02/2018, à 08:58

bruno

Re : [RESOLU] Problème de résolution de noms

La commande host, comme dig, est un outil d'interrogation DNS. Il est peut-être possible de les utiliser pour mDNS mais je ne sais pas faire.

Une simple commande ping devrait fonctionner à condition que libnss-mdns soit installée:

ping -c 2 monserveur.local

ou avec les outils avahi (paquet avahi-utils) :

avahi-resolve-host-name monserveur.local

#8 Le 08/02/2018, à 09:40

diesel

Re : [RESOLU] Problème de résolution de noms

Bonjour Bruno,

Merci pour ta réponse.

Je viens d'essayer (sans succès) "avahi-resolve-host-name monserveur.local".

Puis, je me suis souvenu que mon problème était de faire fonctionner cups pour partager mon imprimante physiquement reliée à mon serveur. Et là, oh miracle !, ça marche.

Finalement, pour moi, je suis arrivé au bout de ma recherche, même si je ne suis pas parvenu à résoudre le nom "monserveur.local" avec les commandes habituelles de résolution de nom (mais je n'ai pas beaucoup l'utilité à passer mes jours à taper des "host monserveur.local" pour le plaisir de voir afficher l'adresse 192.168.0.1 wink big_smile big_smile big_smile )

Et le problème était bien que c'était mon pare-feu qui me bloquait (au moins en partie) mes commandes d'impression.

Il me reste donc maintenant à passer un coup de tcpdump sur mon serveur pour voir comment ça se passe et mettre en place les règles qui vont bien pour virer tout le reste.

Aussi, merci encore.

Amicalement.

Jean-Marie

[EDIT] P.S. je viens de réessayer "avahi-resolve-host-name monserveur.local" sur mon client et même ça, ça fonctionne.

Dernière modification par diesel (Le 08/02/2018, à 09:59)

Je déteste qu'on cherche à me faire passer pour un con, j'y arrive déjà très bien tout seul.
Le mort, il sait pas qu'il est mort ; c'est pour les autres que c'est dur.................... Pour les cons, c'est pareil.

Hors ligne

Pages : 1