Bind9 sous Debian : un ping ne fonctionne pas
Francois
Je suis en train d'apprendre à faire un petit serveur DNS simplement en
"mode cache" (le DNS ne fait que renvoyer la balle au DNS de mon FAI)
sous une debian 5.0 version stable et j'ai du mal. Je vais essayé d'être
complet, désolé pour la longueur du message.
a) Je "suis derrière" ma freebox dont le dhcp n'est pas activé.
b) J'ai une distribution ubuntu qui me sert de client DNS dont les
paramètres sont :
IP = 192.168.0.1 avec le masque 255.255.255.0
Passerelle par défaut = 192.168.0.254 (IP de la freebox)
DNS = 192.168.0.2 (IP de la debian, le serveur DNS)
c) Sur Ubuntu j'ai installé en OS virtuel une debian donc, que j'essaye
de transformer en serveur DNS. Voici ses paramètres :
IP = 192.168.0.2 avec le masque 255.255.255.0
Passerelle par défaut = 192.168.0.254 (IP de la freebox)
Le domaine qu'elle est censée gérer s'appelle "dom" et le PC-serveur DNS
s'appelle "debian".
Voici certains fichiers sur le serveur DNS (debian) que j'ai
laborieusement essayé d'éditer correctement (sachant que j'ai installé
le paquet bind9 dessus) :
----------------
# /etc/host.conf
order hosts, bind
----------------
----------------
# /etc/hosts
127.0.0.1 localhost.dom localhost
192.168.0.2 debian.dom debian
# et des trucs qui étaient là au départ
# semble-t-il pour gérer l'IP6...
----------------
----------------
# /etc/resolv.conf
nameserver 127.0.0.1
domain dom
----------------
----------------
# /etc/bind/named.conf qui modulo des include donne ceci :
acl "dom" { 127.0.0.0/8; 192.168.0.0/24; };
options {
directory "/var/cache/bind";
allow-query { "dom"; };
forward first;
forwarders {
212.27.40.241; // DNS de free
212.27.40.240; // DNS de free
};
}
zone "." {
type hint;
file "/etc/bind/db.root";
};
// 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";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
----------------
Voilà pour la configuration. Et bien le DNS fonctionne un peu dans le
sens où pour aller chercher des hôtes sur le net (je parle du client
ubuntu), ça fonctionne. Et quand je tue le processus "named" (c'est bien
le processus du DNS ???) sur ma debian et bien là plus de navigation
possible sur Internet avec le client (Ubuntu) il n'arrive plus à
résoudre les noms. Par contre, pour avec le terminal d'ubuntu, un simple :
$ ping debian.dom
me renvoie un :
ping: unknown host debian.dom
Donc le DNS ne fait pas bien son travail et je ne vois absolument pas
pourquoi ? Si vous avez des idées... J'y est passé du temps et je
commence à m'embrouiller.
Au passage, je croyais que les deamons étaient tous répertoriés dans
/etc/init.d/. Or je ne vois pas de "named" dans ce répertoire, mais je
vois un "bind9". C'est normal ça ? On lance le deamom comment ? Avec la
commande "named" ou en lançant le script /etc/init.d/bind9 ? Est-ce
équivalent ? Dans mon esprit, ça me complique les choses, déjà que je
trouve ça compliqué...
Merci de m'avoir lu jusqu'au bout (et bravo ;-)).
À bientôt.
--
François Lafont
Pascal Hambourg
Francois a écrit :
>
> $ ping debian.dom
>
> me renvoie un :
>
> ping: unknown host debian.dom
Mauvais intitulé : ce n'est pas le ping qui ne marche pas mais la
résolution de nom préalable. Sauf erreur de ma part, la raison est qu'il
n'y a pas de zone "dom" définie dans named.conf.
> Au passage, je croyais que les deamons étaient tous répertoriés dans
> /etc/init.d/. Or je ne vois pas de "named" dans ce répertoire, mais je
> vois un "bind9". C'est normal ça ?
Le script s'appelle bind9 probablement parce que c'est le nom du paquetage.
On lance le deamom comment ? Avec la commande "named"
Je suppose qu'on peut, mais cela nécessite de saisir toutes les options
éventuelles à la main.
> ou en lançant le script /etc/init.d/bind9 ?
Ou avec la commande "invoke-rc.d bind9 start", si on est dans un
runlevel compatible.
La Bete des Vosges (Francis Chartier)
> Bonjour à tous,
'lut
> ----------------
> # /etc/resolv.conf
> nameserver 127.0.0.1
> domain dom
> ----------------
>
> $ ping debian.dom
>
> me renvoie un :
>
> ping: unknown host debian.dom
>
> Donc le DNS ne fait pas bien son travail et je ne vois absolument pas
> pourquoi ? Si vous avez des idées... J'y est passé du temps et je
> commence à m'embrouiller.
Je ne vois nulle part dans ta config de déclaration pour le domaine "dom"
auquel tu fais référence dans ton resolf.conf, et dont tu dois faire
normalement partie j'imagine ?
Sur une debian tu as normalement à la fin du named.conf la ligne
include "/etc/bind/named.conf.local";
qui te permettra d'inclure la déclaration de tes zones
Qu'as tu dans ton named.conf.local ?
Tu devrais normalement avoir un truc du genre :
zone "dom" {
type master;
file "/etc/bind/db.dom";
};
ou (ma préférence)
zone "dom" {
type master;
file "/var/cache/bind/db.dom";
};
Et le ficher db.dom en question doit contenir les définitions pour la
zone.
Se reporter par exemple à :
http://fr.wikibooks.org/wiki/Le_syst%C3%A8me_d%27exploitation_GNU-Linux/
Le_serveur_de_noms_Bind#.2Fetc.2Fbind.2Fnamed.conf.local
> Au passage, je croyais que les deamons étaient tous répertoriés dans
> /etc/init.d/. Or je ne vois pas de "named" dans ce répertoire, mais je
> vois un "bind9". C'est normal ça ? On lance le deamom comment ? Avec la
> commande "named" ou en lançant le script /etc/init.d/bind9 ? Est-ce
> équivalent ? Dans mon esprit, ça me complique les choses, déjà que je
> trouve ça compliqué...
les daemons sont lancés ou arrêtés grâce aux liens symboliques dans
/etc/rc<runlevel>.d
Les liens nécessaires sont normalement créés automatiquement lors de
l'installation du paquet.
Pour plus de détails :
man update-rc.d
Bon courage.
--
La Bête des Vosges
Francois
>> $ ping debian.dom
>>
>> me renvoie un :
>>
>> ping: unknown host debian.dom
>
> Mauvais intitulé : ce n'est pas le ping qui ne marche pas mais la
> résolution de nom préalable.
C'est exact (d'ailleurs le ping avec l'IP ad hoc marche). Mais, n'étant
pas très calé dans sur ces questions, la seul test que je suis capable
de faire en ligne de commande, c'est un ping.
> Sauf erreur de ma part, la raison est qu'il
> n'y a pas de zone "dom" définie dans named.conf.
Oui, c'est conforté dans le message suivant. J'y répondrai dans mon
prochain message.
Merci pour votre réponse.
--
François Lafont
Francois
> Je ne vois nulle part dans ta config de déclaration pour le domaine "dom"
> auquel tu fais référence dans ton resolf.conf, et dont tu dois faire
> normalement partie j'imagine ?
Oui, c'est sûrement ça. Mais il y a une chose que je ne comprends pas.
Dans le fichier /etc/host.conf du DNS, j'ai fais en sorte que d'abord le
DNS utilise /etc/hosts pour la résolution des noms, puis *ensuite* fait
appel au processus named (bind). Or dans le /etc/hosts du DNS, le nom
debian y figure bien avec l'IP qui va bien, donc ça devrait marcher mon
ping. Où est mon erreur ? (Quelque chose m'échappe.)
> Sur une debian tu as normalement à la fin du named.conf la ligne
>
> include "/etc/bind/named.conf.local";
>
> qui te permettra d'inclure la déclaration de tes zones
>
> Qu'as tu dans ton named.conf.local ?
Ça :
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are note used
// in your organization
// include "/etc/bind/zones.rfc1918";
et /etc/bind/zones.rfc1918 contient une vingtaine de lignes du genre :
zone "<n>.in-addr.arpa" { type master; file "/etc/bind/db.empty"; };
C'est un peu du chinois pour moi.
> Tu devrais normalement avoir un truc du genre :
>
> zone "dom" {
> type master;
> file "/etc/bind/db.dom";
> };
>
> ou (ma préférence)
>
> zone "dom" {
> type master;
> file "/var/cache/bind/db.dom";
> };
>
> Et le ficher db.dom en question doit contenir les définitions pour la
> zone.
C'est à moi d'éditer ce fichier à la main ? Parce que, quand j'ai jeté
un oeil sur ce type du fichier, ça m'a paru vraiment obscur. Ah, c'est
pas facile linux.
> Se reporter par exemple à :
>
> http://fr.wikibooks.org/wiki/Le_syst%C3%A8me_d%27exploitation_GNU-Linux/
> Le_serveur_de_noms_Bind#.2Fetc.2Fbind.2Fnamed.conf.local
Merci pour le lien.
>> Au passage, je croyais que les deamons étaient tous répertoriés dans
>> /etc/init.d/. Or je ne vois pas de "named" dans ce répertoire, mais je
>> vois un "bind9". C'est normal ça ? On lance le deamom comment ? Avec la
>> commande "named" ou en lançant le script /etc/init.d/bind9 ? Est-ce
>> équivalent ? Dans mon esprit, ça me complique les choses, déjà que je
>> trouve ça compliqué...
>
> les daemons sont lancés ou arrêtés grâce aux liens symboliques dans
>
> /etc/rc<runlevel>.d
Et ces liens symboliques pointent vers des "vrais" fichiers qui sont
tous dans /etc/init.d/, c'est ça ?
> Les liens nécessaires sont normalement créés automatiquement lors de
> l'installation du paquet.
Ok. Par exemple le runlevel de mon DNS-debian est 2. Quand je démarre
normalement l'ordinateur (en runlevel 2 donc) après avoir installé
bind9, j'ai la garantie que le contenu de /etc.rc2.d/ a été modifié pour
que le deamon bind-names soit activé juste après le démarrage, c'est ça ?
Au passage, si je modifie la configuration de names, en changeant
/etc/bind/named.conf, suis-je obligé de redémarrer l'ordinateur ?
Dois-je au moins tuer le processus named et le relancer ? Si oui, est-ce
que ceci :
$ kill <PID du processus named>
$ named
est une manière propre de faire ? Peut-être qu'il faut des arguments
particulier à named ?
> Bon courage.
Merci, je vais en avoir besoin. ;-)
Mer pour votre aide.
--
François Lafont
Fabien LE LEZ
>Dans le fichier /etc/host.conf du DNS,
Les fichiers de config de BIND sont dans /etc/bind/.
Francois
>> Dans le fichier /etc/host.conf du DNS,
>
> Les fichiers de config de BIND sont dans /etc/bind/.
Je me suis mal exprimé. Par "le fichier /etc/host.conf du DNS", je
voulais dire "le fichier /etc/host.conf qui se trouve dans l'ordinateur
jouant le rôle du DNS".
--
François Lafont
Fabien LE LEZ
>"le fichier /etc/host.conf qui se trouve dans l'ordinateur
>jouant le rôle du DNS".
Qui n'a, si je ne m'abuse, aucune influence sur le PC client.
Il ne faut pas confondre le système de résolution de noms sur une
machine donnée, qui sert pour les besoins des applications qui
tournent sur cette machine, et BIND, qui donne des informations aux
machines qui l'interrogent via le port 53.
La Bete des Vosges (Francis Chartier)
>> Qu'as tu dans ton named.conf.local ?
>
> Ça :
>
> //
> // Do any local configuration here
> //
>
> // Consider adding the 1918 zones here, if they are note used // in your
> organization
> // include "/etc/bind/zones.rfc1918";
Donc pas de référence à un fichier de définition pour ta zone.
Normal que ça ne marche pas.
>> Tu devrais normalement avoir un truc du genre :
>>
>> zone "dom" {
>> type master;
>> file "/etc/bind/db.dom";
>> };
>>
>> Et le ficher db.dom en question doit contenir les définitions pour la
>> zone.
>
> C'est à moi d'éditer ce fichier à la main ?
Ben oui : c'est ta zone, c'est à toi de renseigner.
> Parce que, quand j'ai jeté
> un oeil sur ce type du fichier, ça m'a paru vraiment obscur. Ah, c'est
> pas facile linux.
Soyons clairs : la mise en oeuvre d'un serveur DNS est normalement un
boulot d'administrateur plus que de simple utilisateur et ça demande de
bonnes notions réseau si on veut que ça fonctionne correctement.
C'est souvent une resource qu'on met en place parce que ça va améliorer
le fonctionnement d'autres serveurs sur son propre réseau.
Il me paraît délicat de se lancer là dedans sans sérieusement étudier la
doc abondante disponible.
Et cette démarche n'est pas propre à linux, mais valable quel que soit le
système utilisé. Enfin, c'est à espérer. :)
> Ok. Par exemple le runlevel de mon DNS-debian est 2. Quand je démarre
> normalement l'ordinateur (en runlevel 2 donc) après avoir installé
> bind9, j'ai la garantie que le contenu de /etc.rc2.d/ a été modifié pour
> que le deamon bind-names soit activé juste après le démarrage, c'est ça
> ?
Normalement, il est même lancé après l'installation.
Il y a généralement peu de raisons qui nécessitent un redémarrage d'un
serveur, à part l'installation d'un nouveau noyau ou d'une nouvelle
version d'une bibliothèque fondamentale du système.
Un ps -ax | grep named vous en dira plus, ainsi que la lecture des logs.
> Si oui, est-ce
> que ceci :
>
> $ kill <PID du processus named>
> $ named
>
> est une manière propre de faire ? Peut-être qu'il faut des arguments
> particulier à named ?
Non, c'est sale. :)
La plupart des daemons lancés via les liens dans rc<x>.d prennent reload
ou restart comme argument, c'est notamment le cas pour /etc/init.d/bind9
Francois
>> pas facile linux.
>
> Soyons clairs : la mise en oeuvre d'un serveur DNS est normalement un
> boulot d'administrateur plus que de simple utilisateur et ça demande de
> bonnes notions réseau si on veut que ça fonctionne correctement.
> C'est souvent une resource qu'on met en place parce que ça va améliorer
> le fonctionnement d'autres serveurs sur son propre réseau.
>
> Il me paraît délicat de se lancer là dedans sans sérieusement étudier la
> doc abondante disponible.
>
> Et cette démarche n'est pas propre à linux, mais valable quel que soit le
> système utilisé. Enfin, c'est à espérer. :)
Oui, faire un DNS est compliqué je m'en rend compte. En fait, je
m'occupe (bénévolement) du réseau de mon lycée (je suis prof). Je ne
suis pas un spécialiste comme tu peux constater, mais ça m'intéresse
fichtrement. Pour l'instant, le réseau de notre lycée est géré par un
Windows Server 2000 et nous avons un intervenant qui s'en occupe (et je
"l'assiste" un peu). Notre serveur est un peu vieux et il faudra en
changer un jour. Or les directives de l'éducation nationale nous
incitent fortement (et à juste titre selon moi) à mettre en place des
serveurs Linux. Alors, c'est un peu une sorte de prétexte pour essayer
de m'initier un peu dans mon temps libre en prévision du futur
changement (pas avant 2 ans je pense). À l'heure actuel, notre
intervenant ne connaît pas du tout Linux.
Pardon pour cette digression...
Bref faire un DNS c'est pas simple. Il semble que faire un serveur DHCP
soit bien plus simple par exemple.
> Un ps -ax | grep named vous en dira plus, ainsi que la lecture des logs.
Oui, j'utilisais "ps ax | grep named" (sans le -).
>> Si oui, est-ce
>> que ceci :
>>
>> $ kill <PID du processus named>
>> $ named
>>
>> est une manière propre de faire ? Peut-être qu'il faut des arguments
>> particulier à named ?
>
> Non, c'est sale. :)
>
> La plupart des daemons lancés via les liens dans rc<x>.d prennent reload
> ou restart comme argument, c'est notamment le cas pour /etc/init.d/bind9
Oui, en effet.
Merci beaucoup pour ton aide. :-)
--
François Lafont
Kevin Denis
> Bref faire un DNS c'est pas simple. Il semble que faire un serveur DHCP
> soit bien plus simple par exemple.
>
vers le programme dnsmasq.
Il fait tout en un, et fonctionne bien.
Ceci dit, ce n'est peut être pas forcément ce que tu cherches, mais tu
peux jeter un coup d'oeil.
--
Kevin
Fabien LE LEZ
Chartier)" <franci...@bete-des-vosges.org>:
>Et cette démarche n'est pas propre à linux, mais valable quel que soit le
>système utilisé.
À un détail près : BIND est nettement plus chiant à installer sous
Windows que sous Linux.
La Bete des Vosges (Francis Chartier)
> À un détail près : BIND est nettement plus chiant à installer sous
> Windows que sous Linux.
Aucune idée, quand j'ai eu à installer un serveur DNS je ne me suis même
pas posé la question de le faire sous Windows.
Antoine EMERIT
news:49edc09c$0$6721$426a...@news.free.fr:
> Bonjour à tous,
Bonjour,
> Au passage, je croyais que les deamons étaient tous répertoriés dans
> /etc/init.d/. Or je ne vois pas de "named" dans ce répertoire, mais je
> vois un "bind9". C'est normal ça ? On lance le deamom comment ? Avec
> la commande "named" ou en lançant le script /etc/init.d/bind9 ? Est-ce
> équivalent ? Dans mon esprit, ça me complique les choses, déjà que je
> trouve ça compliqué...
Petite précision qui facilite la compréhension de cette histoire de DNS :
- 'bind' est le nom propre d'un serveur DNS (voir http://www.isc.org/).
C'est une des implémentations (libres) du protocol DNS.
- 'bind9' est le nom symbolique de la série 9.x de bind, et on le
retrouve en général dans le nom du package intégré aux distributions
Linux et comme nom de script de démarrage (/etc/init.d/bind9) et des
fichiers de configurations (/etc/bind).
- 'named' est le nom du binaire fourni par bind, c'est-à dire le nom du
démon qui s'exécute sur le serveur.
Donc on parle de bind ou de named pour la même chose, mais on ne retrouve
pas d'exécutable nommé bind sur le serveur.
Bind (named en fait) sers à la machine local à travers les fichiers de
configuration /etc/host.conf (ordre des résolutions de noms sur le
serveur lui-même) et /etc/resolv.conf (liste des serveurs DNS a appeler,
et suffixe de domaine par défaut pour les recherches, localement au
serveur). Ces 2 fichiers font parti de la librairie client 'resolv'
utilisée par les programmes qui tournent sur la machine.
Dans le cas d'un poste client de type *nix ce sont les fichiers
/etc/host.conf et /etc/resolv.conf du poste client qui sont utilisées et
non pas ceux du serveur. Il n'y a aucun lien entre le client et le
serveur pour ces fichiers.
En revanche, quand le poste client accède au serveur DNS, il intéragie
directement avec le binaire named qui résoud pour lui les noms de
machine. Ce sont alors uniquement les fichiers de bind, contenu en
général dans /etc/bind, qui entrent en jeux.
A+
Francois
et autres suggestions. J'ai eu le temps de faire quelques tentatives
mais sans succès. Je ne suis pas du tout au clair, loin de là, avec la
configuration des zones et il faudra donc que je lise de la doc. Bref,
je pense que je ne solutionnerai pas mon problème tout de suite. :-)
Antoine EMERIT a écrit :
> Donc on parle de bind ou de named pour la même chose, mais on ne retrouve
> pas d'exécutable nommé bind sur le serveur.
Question simple et précise : y a t-il une différence entre les deux
commandes suivantes ?
1) named
2) /etc/init.d/bind9 start
Merci pour vos précisions.
--
François Lafont
YBM
Lis le script /etc/init.d/bind9, tu verras bien ce qu'il lance
quand tu luis passe l'argument start.
En réalité on s'en fout : le paquet Debian fournit le script
/etc/init.d/bind9 qui *nécessairement* lance (ou arrête, relance,
etc.) BIND correctement (en allant lire la conf comme il faut, en
le lançant avec le bon user, etc.), DONC il FAUT utiliser ce
script pour lancer BIND.
Pour lui demander de relire sa configuration tu as le choix par contre :
/etc/init.d/bind9 reload ou bien rndc reload reviennent au même.
Regis
[Une longue explication]
Merci Antoine, je viens de prendre une lecon et ca me fait plaisir de
voir qu'il y a des gens assez passionnes pour donner de telles
precisions afin de faciliter la comprehension ; merci encore.
Amicalement,
Regis.
--
Francois
YBM a �crit :
> DONC il FAUT utiliser ce script (bind9) pour lancer BIND.
Ok, c'est compris merci.
Je remonte ce fil car j'ai eu r�cemment le temps de me pencher � nouveau
sur bind9 et je pense �tre arriv� � quelque chose, mais j'aimerais votre
avis et j'ai quelques questions aussi. Je vous rappelle ce que je
voulais faire :
* Pour l'instant je suis en IP fixes partout ;
* j'ai une connexion Internet via un routeur dont l'IP c�t� LAN est
192.168.0.254 ;
* j'ai un PC tournant sur une debian qui est le serveur DNS. Son nom est
"debian" et ce serveur va faire autorit� sur le domaine
"mondomaine.local." et sinon il redirigera les requ�tes vers les DNS de
mon FAI ;
* j'ai un PC membre du domaine sur Ubuntu dont le nom est franPC
d'adresse IP (fixe) 192.168.0.1 ;
* j'ai un PC client sur XP PRO dont le nom est XPPRO d'adresse IP
192.168.0.2.
Modulo les "includes", voici mon fichier /etc/bind/named.conf (j'ai
laiss� des lignes qui �tait l� par d�faut et qu'il ne faut pas toucher
apparemment) :
--------------------------------------------------
acl "mon_reseau" {127.0.0.1; 192.168.0.0/24;};
options {
directory "/var/cache/bind";
allow-query { "mon_reseau"; };
forward only;
forwarders {
212.27.40.241;
212.27.40.240;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// 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";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// --------MES ZONES------------
zone "mondomaine.local" {
type master;
file "db.mondomaine.local";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "db.0.168.192.reverse";
};
--------------------------------------------------
Voici les deux fichiers /var/cache/bind/db.mondomaine.local
et /var/cache/bind/db.0.168.192.reverse :
----------------db.mondomaine.local-----------------
$TTL 1w
@ IN SOA debian.mondomaine.local. root.debian.mondomaine.local.(
2009050305
21600
1800
604800
900)
IN NS debian.mondomaine.local.
localhost IN A 127.0.0.1
debian IN A 192.168.0.253
franPC IN A 192.168.0.1
XPPRO IN A 192.168.0.2
--------------------------------------------------
-------------db.0.168.192.reverse-----------
$TTL 1w
@ IN SOA debian.mondomaine.local. root.debian.mondomaine.local.(
2009050305
21600
1800
604800
900)
IN NS debian.mondomaine.local.
253 IN PTR debian.mondomaine.local.
1 IN PTR franPC.mondomaine.local.
2 IN PTR XPPRO.mondomaine.local.
--------------------------------------------------
J'ai param�tr� le r�solveur ainsi :
-------------/etc/resolv.conf---------------------
nameserver 192.168.0.253 # j'ai mis 127.0.0.1 pour le DNS lui-m�me
domain mondomaine.local.
--------------------------------------------------
-------------/etc/host.conf---------------------
order hosts, bind
--------------------------------------------------
1) Est-ce que cela vous para�t correct ?
2) Quand je fais "dig debian" sur le PC franPC, �a fonctionne et � la
deuxi�me tentative on voit bien que le cache du DNS fonctionne car j'ai
un "Query time" beaucoup plus rapide. Mais l'adresse IP de debian
n'appara�t pas dans la sortie de la commande, est-ce normal ?
Si je fais "dig debiannnnnn", le nom est r�solu aussi semble-t-il, mais
comment puis-je savoir qu'il est r�solu n�gativement ?
3) L� je suis en IP fixe et donc au d�marrage d'un "membre du domaine"
(par exemple de franPC), il faut que je configure correctement son
r�solveur. Pour que la configuration se fasse automatiquement au
d�marrage, j'ai �dit� le fichier /etc/rc.local comme ceci :
--------------------------------------------------
# On configure la carte reseau en IP fixe
# et on parametre la passerelle par defaut
ifconfig eth0 192.168.0.1
route add default gw 192.168.0.254
# On regle les parametres du resolveur
echo "
nameserver 192.268.0.253 # j'ai mis 127.0.0.1 pour le DNS lui-m�me
domain mondomaine.local.
" > /etc/resolv.conf
exit 0
--------------------------------------------------
Dans le cadre d'une politique en IP fixes, est-ce une mani�re correcte
de s'y prendre (notamment le fait de passer par le fichier
/etc/rc.local) ? Bon j'ai conscience que la bonne politique serait de
passer en DHCP, j'ai l'intention de me documenter sur ce point (quand
j'aurais le temps)...
4) Si j'ai une nouvelle machine que je veux int�grer au domaine, me
suffit-il de faire ceci ?
a) param�trer son IP, sa passerelle et son r�solveur (comme dans 3. ?)
b) puis, sur le serveur DNS, mettre une ligne suppl�mentaire dans les
deux fichiers /var/cache/bind/db.mondomaine.local
et /var/cache/bind/db.0.168.192.reverse
-----------pour db.mondomaine.local
lenouveau IN A 192.168.0.3
-----------
et
-----------pour db.0.168.192.reverse
3 IN PTR lenouveau.mondomaine.local.
-----------
Existe-t-il une commande pour ajouter un membre dans le domaine sans
�diter � la main les fichiers de zones ?
Merci d'avance et d�sol� pour ce message un peu fleuve.
--
Fran�ois Lafont
Francois
> Je remonte ce fil car j'ai eu r�cemment le temps de me pencher � nouveau
> sur bind9 et je pense �tre arriv� � quelque chose...
J'ai parl� un peu vite car il y a quand m�me ceci que je ne comprends pas :
5) Si je tape sur le poste membre franPC :
$ ping debian
�a fonctionne, mais si je tape
$ ping debian.mondomaine.local.
il me r�pond "ping: unknown host debian.mondomaine.local." ???
Sur le serveur DNS, je n'ai pas ce probl�me.
Avez vous une explication ?
--
Fran�ois Lafont
YBM
Commencez par utiliser un outil adapt� afin de tester votre
configuration DNS : host et non ping :
host debian
host debian.mondomaine.local
�ventuellement avec l'option -v (verbeux).
Francois
>> 5) Si je tape sur le poste membre franPC :
>> $ ping debian
>> �a fonctionne, mais si je tape
>> $ ping debian.mondomaine.local.
>> il me r�pond "ping: unknown host debian.mondomaine.local." ???
>> Sur le serveur DNS, je n'ai pas ce probl�me.
>>
>> Avez vous une explication ?
>
> Commencez par utiliser un outil adapt� afin de tester votre
> configuration DNS : host et non ping :
>
> host debian
> host debian.mondomaine.local
>
> �ventuellement avec l'option -v (verbeux).
Merci pour cette r�ponse qui me fait avancer. En fait (et �a rejoint un
peu la question 2 de mon long message pr�c�dent), j'utilisais la
commande dig, car on m'avait d�j� fait la remarque (� juste titre) sur
la non pertinence de la commande ping. Mais je n'arrive pas � savoir
avec dig si le nom est r�solu positivement (le serveur DNS � trouver un
h�te correspondant) ou n�gativement (le serveur DNS estime qu'il n'y a
pas d'h�te correspondant) : par exemple "dig debiannnn" me renvoyait un
message qui ne me semblait pas tr�s diff�rent de "dig debian" et
d'ailleurs j'aimerais bien comprendre ceci.
La commande host est exactement ce que je recherchais et �a me donne �a :
francois@franPC:~$ host debian
debian.mondomaine.local has address 192.168.0.253
francois@franPC:~$ host debian.mondomaine.local.
debian.mondomaine.local has address 192.168.0.253
Donc le DNS semble faire son travail. �a confirme une fois encore la non
pertinence de ping. Mais du coup, je comprends encore moins pourquoi le
ping ne fonctionne pas ?
francois@franPC:~$ ping debian.mondomaine.local.
ping: unknown host debian.mondomaine.local.
--
Fran�ois Lafont
Francois
> debian.mondomaine.local n'a pas ￜtￜ ajoutￜ dans le fichier /etc/hosts de
> la machine franPC
Oui ï¿œa va sans doute fonctionner comme ï¿œa, mais c'est de la "triche". :-)
Je ne veux pas passer par le fichier /etc/hosts, mais par un serveur DNS
ￜ peu prￜs bien configurￜ.
--
Franï¿œois Lafont
La Bete des Vosges (Francis Chartier)
> J'ai paramétré le résolveur ainsi :
>
> -------------/etc/resolv.conf--------------------- nameserver
> 192.168.0.253 # j'ai mis 127.0.0.1 pour le DNS lui-même
> domain mondomaine.local.
> --------------------------------------------------
Pas de point à la fin de domain mondomaine.local dans le fichier
resolv.conf
Seul endroit où il faut mettre ce point final c'est dans le fichier
"reverse".
> # On regle les parametres du resolveur echo "
> nameserver 192.268.0.253 # j'ai mis 127.0.0.1 pour le DNS lui-même
> domain mondomaine.local.
> " > /etc/resolv.conf
même remarque que précédemment.
> Dans le cadre d'une politique en IP fixes, est-ce une manière correcte
> de s'y prendre (notamment le fait de passer par le fichier
> /etc/rc.local) ?
Je ne comprends pas trop pourquoi vous faites comme ça.
Pourquoi ne pas configurer une bonne fois pour toute directement le
fichier resolv.conf ?
C'est à cause d'une "amélioration" de la distrib qui reconfigure à chaque
démarrage le réseau ?
Si c'est ça, il doit exister le moyen de le figer avec des valeurs persos.
> Bon j'ai conscience que la bonne politique serait de
> passer en DHCP, j'ai l'intention de me documenter sur ce point (quand
> j'aurais le temps)...
Bof.
Sur un réseau limité en nombre de machines et qui évolue peu (notamment
sans postes nomades), je ne vois pas réellement d'intérêt à DHCP.
D'autant plus qu'il va falloir récupérer et gérer les addresses MAC pour
les postes autorisés, écrire éventuellement les fichiers d'attributions
des addresses IP à certains postes qu'on veut voire en IP fixe, etc.
Pas forcément moins de boulot en fait.
>
> 4) Si j'ai une nouvelle machine que je veux intégrer au domaine, me
> suffit-il de faire ceci ?
> a) paramétrer son IP, sa passerelle et son résolveur (comme dans 3. ?)
> b) puis, sur le serveur DNS, mettre une ligne supplémentaire dans les
> deux fichiers /var/cache/bind/db.mondomaine.local et
> /var/cache/bind/db.0.168.192.reverse
Pensez à mettre à jour à chaque révision du fichier
@ IN SOA debian.mondomaine.local. root.debian.mondomaine.local.(
2009050305
^^^^^^^^^^
C'est le classique oubli du débutant, avec l'oubli du point final au PTR
dans le fichier reverse. :))
> Existe-t-il une commande pour ajouter un membre dans le domaine sans
> éditer à la main les fichiers de zones ?
Editer à la main présente le risque de coquilles, mais ça permet d'eviter
d'oublier la syntaxe. Si vous devez ajouter pas mal de machines et ce
assez régulièrement, une macro en perl ?
> Merci d'avance et désolé pour ce message un peu fleuve.
Nan c'est bien, en plus on voit que vous avez faits vos devoirs :)
C'est mieux que le "Sa march' pô cé tout Kcé, ou é le tuto???".
Bon courage pour la suite.
Je confonds peut-être plusieurs fils, mais n'est-ce pas vous qui deviez
configurer le réseau d'une école ?
Si c'est le cas (avec un certains nombre de machines), vous avez intérêt
à bien réfléchir votre topologie, les plages d'adresses, qui a accès à
quoi, etc.
C'est très pénible de devoir recommencer parce qu'on a pas assez réfléchi
avant. :)
Francois
> Le Sun, 03 May 2009 15:06:39 +0200, Francois a écrit :
>
>
>> J'ai paramétré le résolveur ainsi :
>>
>> -------------/etc/resolv.conf--------------------- nameserver
>> 192.168.0.253 # j'ai mis 127.0.0.1 pour le DNS lui-même
>> domain mondomaine.local.
>> --------------------------------------------------
>
> Pas de point à la fin de domain mondomaine.local dans le fichier
> resolv.conf
Ah d'accord. Je croyais qu'il fallait au contraire mettre un nom FQDN
systématiquement avec un point "." à la fin dans les fichiers de
configuration, je croyais que c'était justement la façon propre d'écrire
un FQDN.
> Seul endroit où il faut mettre ce point final c'est dans le fichier
> "reverse".
Et pas dans le fichier de zone normal (le "non-reverse") ? Car c'est ce
que j'ai fait dans le fichier /var/cache/bind/db.mondomaine.local :
#--------------------------------------------
$TTL 1w
$ORIGIN mondomaine.local.
@ IN SOA debian.mondomaine.local. root.debian.mondomaine.local.(
2009050305
21600
1800
604800
900)
IN NS debian.mondomaine.local.
localhost IN A 127.0.0.1
debian IN A 192.168.0.253
franPC IN A 192.168.0.1
XPPRO IN A 192.168.0.2
#--------------------------------------------
Dans ce fichier aussi, il faudra que je supprime tous les points "." à
la fin ?
>> Dans le cadre d'une politique en IP fixes, est-ce une manière correcte
>> de s'y prendre (notamment le fait de passer par le fichier
>> /etc/rc.local) ?
>
> Je ne comprends pas trop pourquoi vous faites comme ça.
> Pourquoi ne pas configurer une bonne fois pour toute directement le
> fichier resolv.conf ?
> C'est à cause d'une "amélioration" de la distrib qui reconfigure à chaque
> démarrage le réseau ?
Non, vous avez raison. En fait, mon routeur était activé en DHCP et donc
au démarrage le PC prenait les DNS du FAI. J'ai enlevé le DHCP et là
c'est Ok. En revanche, je ne sais pas "couler dans le marbre" la
configuration IP fixe du PC "debian", celui qui sert de DNS. Quand je fais :
ifconfig eth0 192.168.0.253 # l'IP fixe du PC DNS "debian"
au prochain redémarrage du PC, le PC ne garde pas cette IP (avec
pourtant le DHCP du routeur désactivé bien sûr). Au démarrage suivant,
j'ai ça :
#---------------------------------------------------------
eth0 Link encap:Ethernet HWaddr 08:00:27:b8:ac:bd
adr inet6: 2a01:e35:2e6d:a280:a00:27ff:feb8:acbd/64 Scope:Global
adr inet6: fe80::a00:27ff:feb8:acbd/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:338 (338.0 B) TX bytes:2116 (2.0 KiB)
#---------------------------------------------------------
Du coup, là par contre, j'ai mis la commande "ifconfig eth0
192.168.0.253" dans le fichier /etc/rc.local. Je ne connais pas d'autres
manière de faire.
Sinon, il y a un problème que je ne comprends pas et que je n'arrive pas
à résoudre, le voici résumé par ces quelques commandes. Je les effectue
sur le PC "franPC" pour vérifier que le DNS ("debian") fonctionne bien.
#----------------------------------------------------
~$ host forum.mathematex.net
forum.mathematex.net has address 88.191.61.117
### Ok, le DNS transmet bien la requête aux DNS de mon FAI
~$ host debian
debian.mondomaine.local has address 192.168.0.253
### Ok, le DNS résout le nom "debian" qui fait partie de
### mondomaine.local
~$ host debian.mondomaine.local.
debian.mondomaine.local has address 192.168.0.253
### Ok, le DNS résout le nom complet (FQDN) également
~$ ping 192.168.0.253
PING 192.168.0.253 (192.168.0.253) 56(84) bytes of data.
64 bytes from 192.168.0.253: icmp_seq=1 ttl=64 time=1.22 ms
### Ok, la connexion fonctionne entre "franPC" et le DNS "debian"
~$ ping debian
PING debian.mondomaine.local (192.168.0.253) 56(84) bytes of data.
64 bytes from debian.mondomaine.local (192.168.0.253): icmp_seq=1 ttl=64
time=0.606 ms
### Ok, le nom "debian" est résolu et le ping fonctionne
~$ ping debian.mondomaine.local.
ping: unknown host debian.mondomaine.local.
### ###
### Pourquoi ??? ###
### ###
#----------------------------------------------------
Je ne comprends absolument pas pourquoi le "ping <IP>" marche, le "host
<nom FQDN>" marche aussi mais pas le "ping <nom FQDN>" ? En plus, le
"ping debian" fonctionne lui. Tout ça me paraît complètement
contradictoire !? J'ai essayé avec ou sans point "." à la fin, ça ne
change rien (et j'ai bien enlevé le point "." du /etc/resolv.conf").
Est-ce mon fichier /var/cache/bind/db.mondomaine.local (cité plus haut)
qui est mal configuré ?
>> Bon j'ai conscience que la bonne politique serait de
>> passer en DHCP, j'ai l'intention de me documenter sur ce point (quand
>> j'aurais le temps)...
>
> Bof.
> Sur un réseau limité en nombre de machines et qui évolue peu (notamment
> sans postes nomades), je ne vois pas réellement d'intérêt à DHCP.
> D'autant plus qu'il va falloir récupérer et gérer les addresses MAC pour
> les postes autorisés, écrire éventuellement les fichiers d'attributions
> des addresses IP à certains postes qu'on veut voire en IP fixe, etc.
> Pas forcément moins de boulot en fait.
Ah oui, c'est possible. Je vais peut-être dire une bêtise, mais par
exemple quand on clone un PC pour faire un déploiement sur une salle de
15 PC par exemple, ce n'est pas mieux d'être en DHCP dans ce cas là ?
> Pensez à mettre à jour à chaque révision du fichier
>
> @ IN SOA debian.mondomaine.local. root.debian.mondomaine.local.(
> 2009050305
> ^^^^^^^^^^
>
> C'est le classique oubli du débutant, avec l'oubli du point final au PTR
> dans le fichier reverse. :))
Ah oui, je ne déroge pas à la règle alors (pour le numéro de série). :-)
Dans ma configuration, ça ne doit pas être trop grave, non ? Car aucun
DNS secondaire ne scrute d'éventuelles mises à jour.
>> Existe-t-il une commande pour ajouter un membre dans le domaine sans
>> éditer à la main les fichiers de zones ?
>
> Editer à la main présente le risque de coquilles, mais ça permet d'eviter
> d'oublier la syntaxe. Si vous devez ajouter pas mal de machines et ce
> assez régulièrement, une macro en perl ?
Ok. Bon, Perl je ne connais pas, mais je connais un peu Python. De toute
façon, pour éditer des fichiers textes, j'imagine que n'importe quel
type de langage de script fait l'affaire.
>> Merci d'avance et désolé pour ce message un peu fleuve.
>
> Nan c'est bien, en plus on voit que vous avez faits vos devoirs :)
J'essaye. :-)
> Bon courage pour la suite.
Merci. :-)
> Je confonds peut-être plusieurs fils, mais n'est-ce pas vous qui deviez
> configurer le réseau d'une école ?
C'est ça. Je suis dans un lycée et j'assiste un intervenant. Je me
penche sur Linux car notre serveur vieillissant qui un windows server
2000 sera remplacé d'ici un an ou deux par un serveur Linux. Je le fais
aussi parce que je trouve ça intéressant.
> Si c'est le cas (avec un certains nombre de machines), vous avez intérêt
> à bien réfléchir votre topologie, les plages d'adresses, qui a accès à
> quoi, etc.
> C'est très pénible de devoir recommencer parce qu'on a pas assez réfléchi
> avant. :)
D'accord sur le principe général. Mais je ne suis pas sûr de comprendre
le mot "topologie". Je suis prof de maths, donc en maths je vois bien la
signification. Dans le monde du réseau, ce terme me semble relever de la
connectique du coup, non ? De ce point de vue, le réseau est déjà en
place et c'est standard dans un établissement scolaire : on a un PC qui
fait routeur et proxy (pour éviter que nos chers élèves n'aillent
visiter des sites douteux) qui s'appelle le SLIS. Lui, il est géré à
distance par des techniciens de l'éducation nationale, pas par
l'établissement. Donc au niveau de la topologie, c'est plutôt simple, on
a ça : (à voir avec une police à chasse fixe).
--------
(WAN) o---| SLIS |---(LAN)-----o serveur de fichiers
-------- |
|---o client 1
|
|---o client 2
|
|
`---o client N
Donc au niveau "topologie", il n'y a pas de question à se poser, il me
semble. Ou alors, je n'ai peut-être pas compris le sens de ce mot d'un
point de vue réseau ? (c'est possible).
En tout cas, merci bien pour votre aide précieuse. :-)
--
François Lafont
La Bete des Vosges (Francis Chartier)
> Ah d'accord. Je croyais qu'il fallait au contraire mettre un nom FQDN
> systématiquement avec un point "." à la fin dans les fichiers de
> configuration, je croyais que c'était justement la façon propre d'écrire
> un FQDN.
>
>> Seul endroit où il faut mettre ce point final c'est dans le fichier
>> "reverse".
>
> Et pas dans le fichier de zone normal (le "non-reverse") ? Car c'est ce
> que j'ai fait dans le fichier /var/cache/bind/db.mondomaine.local :
Si, il est nécessaire dans les fichiers de zone pour bind, c'est dans le
resolv.conf qu'il ne doit pas figurer.
> Dans ce fichier aussi, il faudra que je supprime tous les points "." à
> la fin ?
Non, c'est ok.
> Non, vous avez raison. En fait, mon routeur était activé en DHCP et donc
> au démarrage le PC prenait les DNS du FAI. J'ai enlevé le DHCP et là
> c'est Ok. En revanche, je ne sais pas "couler dans le marbre" la
> configuration IP fixe du PC "debian",
/etc/network/interfaces
man interfaces
exemple :
------------------------------
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.4
# dns-* options are implemented by the resolvconf package, if
installed
dns-nameservers 192.168.0.4
dns-search bete-des-vosges.org
-----------------------------
>
> Sinon, il y a un problème que je ne comprends pas et que je n'arrive pas
> à résoudre, le voici résumé par ces quelques commandes. Je les effectue
> sur le PC "franPC" pour vérifier que le DNS ("debian") fonctionne bien.
>
> ~$ ping debian.mondomaine.local.
> ping: unknown host debian.mondomaine.local.
^
Parce que debian.mondomaine.local. ne correspond à rien dans la zone,
c'est debian.mondomaine.local (sans le . final) qui existe...
Jacques Lav!gnotte
> La Bete des Vosges (Francis Chartier) a écrit :
>> Pas de point à la fin de domain mondomaine.local dans le fichier
>> resolv.conf
resolv.conf ne sert qu'à indiquer les serveurs de nom quel'on veut
utiliser. Il contient des adresses IP
> Ah d'accord. Je croyais qu'il fallait au contraire mettre un nom FQDN
> systématiquement avec un point "." à la fin dans les fichiers de
> configuration,
Il faut un point dans un * fichier de zone * :
IN NS ns.eu.org.
IN NS ns.melusine.eu.org.
IN A 213.215.35.70
IN MX 10 melusine.eu.org.
J.
Francois
La Bete des Vosges (Francis Chartier) a écrit :
> Si, il est nécessaire dans les fichiers de zone pour bind, c'est dans le
> resolv.conf qu'il ne doit pas figurer.
Ok, c'est clair.
> /etc/network/interfaces
>
> man interfaces
>
> exemple : [...]
Ok, merci beaucoup, c'est parfait.
>> ~$ ping debian.mondomaine.local.
>> ping: unknown host debian.mondomaine.local.
> ^
>
> Parce que debian.mondomaine.local. ne correspond à rien dans la zone,
> c'est debian.mondomaine.local (sans le . final) qui existe...
Oui, oui j'ai bien compris cela. Mais, comme je le disais dans mon
précédent message, même sans le point, ça ne fonctionne pas. Regardez :
------------------------------------------------
~$ host debian
debian.mondomaine.local has address 192.168.0.253
~$ host debian.mondomaine.local
debian.mondomaine.local has address 192.168.0.253
~$ ping 192.168.0.253
PING 192.168.0.253 (192.168.0.253) 56(84) bytes of data.
64 bytes from 192.168.0.253: icmp_seq=1 ttl=64 time=1.22 ms
~$ ping debian
PING debian.mondomaine.local (192.168.0.253) 56(84) bytes of data.
64 bytes from debian.mondomaine.local (192.168.0.253): icmp_seq=1 ttl=64
time=0.606 ms
~$ ping debian.mondomaine.local
ping: unknown host debian.mondomaine.local ### ?????????
------------------------------------------------
Je ne comprends pas. Le DNS ne semble pas en cause ici vu que les
commandes "host" fonctionnent, non ? J'ai testé sur XPPRO (un autre
membre du domaine qui est une machine sur XP pro comme son nom
l'indique) et le "ping debian.mondomaine.local" marche.
Je ne comprends pas pourquoi ça ne marche pas et je comprends encore
moins pourquoi le "ping debian" marche *et* pas le "ping
debian.mondomaine.local"
Pourtant, je n'ai mis aucun point "." à la fin du nom FQDN dans
resolv.conf :
------------------------------------------------
~$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.0.253
domain mondomaine.local
------------------------------------------------
(J'ai une interface graphique qui gère ma connexion filaire. Je peux
tout y paramétrer sauf le nom "mondomaine.local". Donc ensuite, j'édite
moi-même /etc/resolv.conf pour y ajouter ce paramètre).
--
François Lafont
Francois
> resolv.conf ne sert qu'à indiquer les serveurs de nom quel'on veut
> utiliser. Il contient des adresses IP
Mais on peut bien aussi lui ajouter la ligne comme :
domain mondomaine.local
ce qui permet quand on cherche à contacter un hôte via un nom sans point
"." (comme dans "debian") de le compléter (ce qui donne
"debian.mondomain.local"). En tout cas, c'est comme ça que je l'ai compris.
> Il faut un point dans un * fichier de zone * :
Oui, oui maintenant je ne l'oublierai pas.
Merci.
--
François Lafont
La Bete des Vosges (Francis Chartier)
> (J'ai une interface graphique qui gère ma connexion filaire. Je peux
> tout y paramétrer sauf le nom "mondomaine.local". Donc ensuite, j'édite
> moi-même /etc/resolv.conf pour y ajouter ce paramètre).
Hum, je vois pas trop d'où ça peut venir.
De mon côté sur mes serveurs ou stations je n'utilise pas d'utilitaires
graphiques pour configurer le réseau, et dans /etc/default/bind9 des
serveurs j'ai l'option
RESOLVCONF=no pour éviter l'autoconfiguration "magique".
Histoire d'être sûr, vous pourriez mettre à jour le serial dans les
fichiers de zone et recharger la configuration de bind ?
Ca ne devrait pas être ça puisque host répond correctement, mébon...
Francois
> Hum, je vois pas trop d'où ça peut venir.
> De mon côté sur mes serveurs ou stations je n'utilise pas d'utilitaires
> graphiques pour configurer le réseau,
C'est sûrement une bonne idée car je commence à penser que c'est lui que
me joue des tours.
> et dans /etc/default/bind9 des
> serveurs j'ai l'option
> RESOLVCONF=no pour éviter l'autoconfiguration "magique".
Tiens, je croyais que les fichiers de configuration de bind étaient dans
/etc/bind/ ? À quoi correspond le fichier /etc/default/bind9 ?
RESOLVCONF=no, c'est pour empêcher l'auto-configuration du fichier
/etc/resolv.conf chez le PC client ?
> Histoire d'être sûr, vous pourriez mettre à jour le serial dans les
> fichiers de zone et recharger la configuration de bind ?
>
> Ca ne devrait pas être ça puisque host répond correctement, mébon...
Hélas, ça ne fonctionne pas. J'ai réglé l'option RESOLVCONF=no, j'ai
changé le numéro de série de mes deux fichiers de zones et j'ai fait :
#/etc/init.d/bind9 restart
Mais c'est toujours la même chose. Dans l'interface graphique de
configuration réseau, je n'ai pas fait attention, mais il y a un champ
"Domaines de recherches" dans lequel je me suis empressé de mettre
"mondomaine.local", si bien que le fichier /etc/resolv.conf est bien
édité par l'utilitaire graphique lui-même (et non pas moi) puisque j'ai :
-------------------------------
# Generated by NetworkManager
search mondomaine.local
nameserver 192.168.0.253
-------------------------------
Et bien ça ne marche toujours pas. C'est bête parce que l'interface
graphique à une interface simple et propre. Si ça se trouve c'est pas
elle la coupable ?
Un "host <nom FQDN>" qui marche avec un "ping <IP du PC >" qui marche et
un "ping <nom FQDN>" qui plante, ça me dépasse. :-)
--
François Lafont
YBM
> Un "host <nom FQDN>" qui marche avec un "ping <IP du PC >" qui marche et
> un "ping <nom FQDN>" qui plante, ça me dépasse. :-)
Il y a quoi dans /etc/hosts ?
Pascal Hambourg
>
> Un "host <nom FQDN>" qui marche avec un "ping <IP du PC >" qui marche et
Moi aussi. Il pourrait ￜtre intￜressant de sniffer le trafic DNS gￜnￜrￜ
par la commande ping, ou de regarder dans les logs de named si le
logging des requￜtes est activￜ.
Francois
>> Un "host <nom FQDN>" qui marche avec un "ping <IP du PC >" qui marche
>> et un "ping <nom FQDN>" qui plante, ça me dépasse. :-)
>
> Il y a quoi dans /etc/hosts ?
Alors j'imagine que la question s'applique pour le PC client (qui
s'appelle "FranPC" dans mon cas), il y a ceci :
#-----------------------------
~$ cat /etc/hosts
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
#-----------------------------
Bon, dans le doute, voici le /etc/hosts du serveur DNS (qui s'appelle
"debian" dans mon cas) :
#-----------------------------
127.0.0.1 localhost
192.168.0.253 debian.mondomaine.local debian
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
#-----------------------------
Voilà. :-)
--
François Lafont
Francois
> Moi aussi. Il pourrait ￜtre intￜressant de sniffer le trafic DNS gￜnￜrￜ
> par la commande ping, ou de regarder dans les logs de named si le
> logging des requￜtes est activￜ.
Je suis incapable de faire tout ï¿œa, hï¿œlas. Mais je vais essayer de
chercher. Dￜjￜ, y a-t-il un log pour bind9 et oￜ il se trouve ?
--
Franï¿œois Lafont
Francois
J'ai mis dans le domaine ("mondomaine.local") une machine sur XP Pro
(qui s'appelle XPpro d'ailleurs) qui a l'IP fixe 192.168.0.2. Et bien ï¿œa
marche trï¿œs bien. Le "ping debian.mondomaine.local" fonctionne trï¿œs
bien. En revanche le "ping debian" ne fonctionne pas, mais cela est
normal vu que je n'ai pas paramￜtrￜ l'ￜquivalent XP de
"/etc/resolv.conf" (j'ignore comment ï¿œa se passe sous XP). Mais dans ce
sens lￜ, les choses sont cohￜrentes je trouve.
Alors que sur ma Ubuntu ("FranPC"), le fait qu'un "ping debian"
fonctionne mais pas un "ping debian.mondomain.local", ï¿œa me laisse
pantois, surtout avec un /etc/resolv.conf comme ï¿œa :
#--------------------------
# Generated by NetworkManager
search mondomaine.local
nameserver 192.168.0.253
#--------------------------
Je pensais justement qu'avec un tel paramï¿œtrage, "ping debian" (qui
marche) ￜtait strictement ￜquivalent ￜ "ping debian.mondomain.local"
(qui ne marche pas), non ?
Bref, tout ï¿œa pour dire que le fait que ï¿œa fonctionne avec XPpro me
laisse penser que c'est pas le DNS le coupable mais le client Ubuntu.
--
Franï¿œois Lafont
Antoine EMERIT
news:4a0179ec$0$16539$426a...@news.free.fr:
> Francois a écrit :
>> La Bete des Vosges (Francis Chartier) a écrit :
>
>>> Pas de point à la fin de domain mondomaine.local dans le fichier
>>> resolv.conf
>
> resolv.conf ne sert qu'à indiquer les serveurs de nom quel'on veut
> utiliser. Il contient des adresses IP
Concernant le '.' � la fin des 'hostname', comme indiqu� plus haut, il ne
concerne que les fichiers de configuration de bind. La r�gle est la
suivante :
- tout nom 'complet' (FQDN) doit �tre termin�e par un .
Il sagit pour le serveur bind de savoir s'il doit ajouter le nom deu
domaine au nom indiqu� dans le fichier de configuration d'une zone
(zone=domaine).
Ex:
dans le fichier db.toto.com qui correspond � la zone toto.com, on a les
lignes suivantes :
@ SAO ........
MX 10 mail1
MX 20 mail1.tata.com.
pc1 IN A 192.168.0.10
pc2.toto.com. IN A 192.168.0.11
pc3 IN CAME pc1
pc4 IN CNAME pc2.toto.com.
vous remarquerez que les noms qui pointent vers un autre domaine
(mail1.tata.com.) se terminent par un point. C'est aussi valable pour les
pointages dans le m�me domaine (pc2.toto.com.) bien que dans ce cas ce ne
soit pas tr�s utile.
On peut � l'extr�me pr�ciser le nom long � gauche (pc2.toto.com.) mais �a
ne sert � rien.
Le @ a pour valeur le nom de domaine, il est tout � fait utilisable dans
les autres lignes du fichier mais comme il est sous-entendu on ne
l'utilise que dans l'enregistrement SOA (start ot authority) qui d�marre
la d�finition de la zone (=domaine).
La valeur de la zone courante (=@) est d�finie par le fichiers de
confugration g�n�rale (/etc/bind/named.conf en g�n�ral) :
zone "toto.com" {
type master;
file "/etc/bind/db.toto.com";
};
ici le 'zone "toto.com"' pr�cise la zone � configurer avec le fichier
/etc/bind/db.toto.com.
Comme indiqu� pr�c�demment les 'zones inverses', qui r�solvent les IP en
nom de host, utilisent le '.'. En fait, comme on fait pointer les IP vers
un domaine pr�cis qui n'est pas celui du 'domaine inverse' ont est oblig�
de mettre le les hostname cible en long (FQDN) :
1.0.0 IN PTR firewall.bogus.fr.
2.0.0 IN PTR app.bogus.fr.
Pour rappel le 'domaine inverse' est le domaine public 'in-addr.arpa'. Il
poss�de une arborescence avec les IPs invers�es. Ainsi le l'IP
192.168.0.0 est point� par le hostname 0.0.192.168.in-addr.arpa.
Dans la pratique et comme on regroupe les hostname en sous-r�seau, il
faut cr�er une zone inverse sur sont dns.
Exemple pour le r�seau 192.168.0.0/24, on a le domaine 0.168.192.in-
addr.arpa, et donc le contenu du fichier de configuration
db.0.168.192.in-addr.arpa :
10 IN PTR pc1.toto.com.
11 IN PTR pc2.toto.com.
Si l'on avait d�cider de d�couper le r�seau 'un cran plus haut'
(192.168.0.0/16) , on aurait alors le domaine 168.192.in-addr.arpa, et le
fichier db.168.192.in-addr.arpa :
10.0 IN PTR pc1.toto.com.
11.0 IN PTR pc2.toto.com.
Notez l'inversion des IP dans le fichier lui-m�me (10.0 et non 0.10).
Les noms des fichiers sont de pures convention. C'est le fichier
named.conf qui les relient correctement entre eux.
Voil�
Pascal Hambourg
> Pascal Hambourg a ï¿œcrit :
>
>> gￜnￜrￜ par la commande ping, ou de regarder dans les logs de named si
>> le logging des requￜtes est activￜ.
>
> Je suis incapable de faire tout ï¿œa, hï¿œlas.
Pour sniffer avec tcpdump (par exemple) :
# tcpdump -nti <interface> -s 512 port 53
> Dￜjￜ, y a-t-il un log pour bind9 et oￜ il se trouve ?
Oui, dans /var/log/syslog ou /var/log/daemon.log. Le processus est
named. Les requￜtes normales ne sont pas forcￜment loggￜes par dￜfaut, ￜ
vï¿œrifier avec :
# rndc status
Si "query logging is OFF", alors :
# rndc querylog
(mï¿œme commande pour le dï¿œsactiver ensuite, c'est une bascule)
Antoine EMERIT
news:4a0367d6$0$27585$426a...@news.free.fr:
> Je pr�cise une petite chose.
>
> J'ai mis dans le domaine ("mondomaine.local") une machine sur XP Pro
> (qui s'appelle XPpro d'ailleurs) qui a l'IP fixe 192.168.0.2. Et bien
> �a marche tr�s bien. Le "ping debian.mondomaine.local" fonctionne tr�s
> bien. En revanche le "ping debian" ne fonctionne pas, mais cela est
> normal vu que je n'ai pas param�tr� l'�quivalent XP de
> "/etc/resolv.conf" (j'ignore comment �a se passe sous XP). Mais dans
> ce sens l�, les choses sont coh�rentes je trouve.
Petite r�cap/explication entre les ping, host et dig :
- ping utilise la librairie r�solver du poste client pour r�soudre les
hostname en IP (et l'inverse). - host et dig ne discutent qu'avec des
DNS. Il servent � tester/d�bugger le fonctionnement des serveurs de
noms.
ping:
-----
Note : cela concerne aussi presque toutes les applications (et
services/da�mons).
La librairie r�solver commence par lire le fichier /etc/host.conf pour
savoir quells fichiers ou serveur elle doit consulter :
/etc/host.conf :
order hosts,bind
'order' d�termine dans quel ordre doivent tester les 'serivces' de
recherche de nom. Ici 'hosts' veut dire 'le fichier /etc/hosts' et
'bind' veut dire 'les serveurs de noms d�fini dans le fichier
/etc/resolv.conf'.
De plus, il peut y avoir des options dans le fichier /etc/nsswitch.conf
qui modifient ce comportement. Notament les ligne 'hosts' :
/etc/nsswitch.conf:
...
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
...
Indique ici d'utiliser le fichier /etc/hosts puis les serveurs de noms
avec diff�rents options.
host/dig:
---------
S'appuis directement sur le fichier /etc/resolv.conf.
Le fichier /etc/resolv.conf indique la liste des serveurs de nom, mais
aussi les suffixes des domaine de recherche � ajouter � tout nom
'court'.
Les suffixes de recherche sont soit le domaine du poste (s'il est
pr�cis� par la commande 'hostname -d'), soit la valeur de la ligne
'domaine' (dans /etc/resolv.conf), soit la valeur de la ligne 'search'
(dans /etc/resolv.conf).
Est consid�r� comme nom 'court' tout nom ne contenant pas de point (en
fait l'option 'ndots' de ce fichier permet de sp�cifier le nombre de
point minimal).
d�buggage :
-----------
Si on a order 'files,bind' dans /etc/host.conf et 'domain :
ping pc1
-> recherche dans /etc/hosts
-> puis r�solution DNS vers les serveurs list�s dans /etc/resolv.conf,
apr�s avoir ajouter le domaine list� dans /etc/resolv.conf (ou le
domaine local � d�faut).
ping pc1.toto.com
-> recherche dans /etc/hosts
-> puis r�solution DNS vers les serveurs list�s dans /etc/resolv.conf,
sans modifier le nom donn� avant recherche
host pc1
-> puis r�solution DNS vers les serveurs list�s dans /etc/resolv.conf,
apr�s avoir ajouter le domaine list� dans /etc/resolv.conf (ou le
domaine local � d�faut).
host pc1.toto.com
-> puis r�solution DNS vers les serveurs list�s dans /etc/resolv.conf,
sans modifier le nom donn� avant recherche
de plus la commande 'host' peut prendre un second param�tre qui est
l'adresse (IP en g�n�ral) du serveur DNS, ce qui permet de passer au
dessus du pointage DNS effectu� par le fichier resolv.conf.
Donc avec ces requ�tes ont peur cerner les diff�rents probl�mes
courants:
- la commande 'host' suivi du hostname complet et de l'adresse IP du
serveur permet de v�rifier le DNS ind�pendament de la configuration du
poste client.
- la commande 'host' suivi d'un nom long puis d'un court et sans IP de
l'adresse du serveur DNS permet de v�rifier la configuration du fichier
resolv.conf.
- enfin, la commande ping suivi d'un nom long puis d'un court permet de
v�rifier la configuration des fichiers /etc/host.conf et /etc/hosts.
Voil�
Antoine EMERIT
$426a...@news.free.fr:
> Je pr�cise une petite chose.
>
> J'ai mis dans le domaine ("mondomaine.local") une machine sur XP Pro
> (qui s'appelle XPpro d'ailleurs) qui a l'IP fixe 192.168.0.2. Et bien �a
> marche tr�s bien. Le "ping debian.mondomaine.local" fonctionne tr�s
> bien. En revanche le "ping debian" ne fonctionne pas, mais cela est
> normal vu que je n'ai pas param�tr� l'�quivalent XP de
> "/etc/resolv.conf" (j'ignore comment �a se passe sous XP). Mais dans ce
> sens l�, les choses sont coh�rentes je trouve.
Les �quivalents des fichiers linux sur XP :
- /etc/hosts -> c:\WINDOWS\system32\drivers\etc\hosts et c:\WINDOWS
\system32\drivers\etc\lmhosts.sam (ce dernier est sp�cique aux r�solutions
Windows LanManager).
- /etc/resolv.conf se retrouve dans les boites de dialogue des Connexions
r�seaux du Panneaux de configuration :
Protocol Internet / Propri�t�s
Avanc�
Onglet "DNS"
Adresses des serveurs DNS
Ajouter ces suffixes DNS
Sans oublier que le domaine par d�faut se configure dans les propri�t�s du
Poste de travail en saisissant un nom long avec le bouton "Nom de
l'Oridnateur".
A+
Sergio
> Francois <fran...@noSpam.fr> �crivait news:4a0367d6$0$27585
> $426a...@news.free.fr:
>
>> Je pr�cise une petite chose.
>>
>> J'ai mis dans le domaine ("mondomaine.local") une machine sur XP Pro
>> (qui s'appelle XPpro d'ailleurs) qui a l'IP fixe 192.168.0.2. Et bien �a
>> marche tr�s bien. Le "ping debian.mondomaine.local" fonctionne tr�s
>> bien. En revanche le "ping debian" ne fonctionne pas, mais cela est
>> normal vu que je n'ai pas param�tr� l'�quivalent XP de
>> "/etc/resolv.conf" (j'ignore comment �a se passe sous XP). Mais dans ce
>> sens l�, les choses sont coh�rentes je trouve.
>
> Les �quivalents des fichiers linux sur XP :
>
> - /etc/hosts -> c:\WINDOWS\system32\drivers\etc\hosts et c:\WINDOWS
> \system32\drivers\etc\lmhosts.sam (ce dernier est sp�cique aux r�solutions
> Windows LanManager).
Ce dernier devant �tre renomm� lmhosts (le "sam" ce n'est pas celui qui
ne boit pas, mais l'abr�viation de "sample").
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Francois
lire, je ne r�siste pas � l'envie de vous expliquer un test que j'ai
fait et qui, je crois, est un gros d�but de piste.
Je vous la fait courte : si je change le nom de mon domaine
"momdomaine.local" par le nom "mondomaine.chezmoi", �a marche !!!!!
-------Rappel vite fait du probl�me-------
J'ai un DNS qui s'appelle "debian" qui fait autorit� dans le domaine
"mondomaine.local" et un client qui s'appelle "franPC" (sur ubuntu).
Sur le client "franPC" :
host debian.mondomaine.local ---> marche
ping 192.168.0.253 # IP de "debian" ---> marche
ping debian.mondomaine.local ---> marche pas (unknown host
debian.mondomaine.local)
-------fin du rappel-------
Je d�taille ce que j'ai fait. Le PC client "franPC" est en IP fixe
192.168.0.1. J'ai �a comme configuration pour ce client :
#-----------------------------------
~$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.0.253 # IP (fixe) du DNS "debian"
#-----------------------------------
#-----------------------------------
~$ cat /etc/hosts
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
#-----------------------------------
#-----------------------------------
~$ cat /etc/host.conf
order hosts, bind
#-----------------------------------
Maintenant pour le DNS "debian", j'ai tout �a :
#---------------------------------
acl "mon_reseau" {
127.0.0.1;
192.168.0.0/24;
};
options {
directory "/var/cache/bind";
allow-query { "mon_reseau"; };
forward only;
forwarders {
212.27.40.241;
212.27.40.240;
};
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
// 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";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
//-------------MES ZONES-------------
//zone "mondomaine.chezmoi" {
zone "mondomaine.local" {
type master;
// file "db.mondomaine.chezmoi";
file "db.mondomaine.local";
};
zone "0.168.192.in-addr.arpa" {
type master;
// file "db.0.168.192.reverse.chezmoi";
file "db.0.168.192.reverse.local";
};
#-------------------------------------------
Voici les fichiers de zones :
#------------db.mondomaine.local-------------
$TTL 1w
@ IN SOA debian.mondomaine.local. root.debian.mondomaine.local. (
2009050305
21600
1800
604800
900)
IN NS debian.mondomaine.local.
localhost IN A 127.0.0.1
debian IN A 192.168.0.253
franPC IN A 192.168.0.1
XPPRO IN A 192.168.0.2
#---------------------------------------
#------------db.0.168.192.reverse.local-----------
$TTL 1w
@ IN SOA debian.mondomaine.local. root.debian.mondomaine.local. (
2009050719
21600
1800
604800
900)
IN NS debian.mondomaine.local.
253 IN PTR debian.mondomaine.local.
1 IN PTR franPC.mondomaine.local.
2 IN PTR XPPRO.mondomaine.local.
#----------------------------------------
Je ne mets pas les fichiers db.*.chezmoi car ce sont les m�mes que les
deux pr�c�dents sauf que j'y ai remplac� les cha�nes "local." par la
cha�ne "chezmoi.", c'est tout.
Maintenant, voici les deux tests que j'ai fait :
1) TEST AVEC MONDOMAINE.LOCAL
Je laisse la configuration de bind9 comme ci-dessus, c'est-�-dire
configur� pour la zone "mondomaine.local". Au cas o�, je fais :
/etc/init.d/bind9 restart # tout est ok !
Ensuite, j'ai ceci :
host debian.mondomaine.local ---> marche
ping 192.168.0.253 # IP de "debian" ---> marche
ping debian.mondomaine.local ---> marche pas !!!!!
Pour rajouter � la confusion, si j'�dite /etc/resolv.conf du pc client
en �a :
-----------------------------
# Generated by NetworkManager
nameserver 192.168.0.253
domain mondomaine.local # <----- rajout
-----------------------------
Alors, j'ai ceci :
ping debian ---> marche ???????????????
2) TEST AVEC MONDOMAINE.CHEZMOI
Je r��dite /etc/resolv.conf du pc client en l'�tat initial :
-----------------------------
# Generated by NetworkManager
nameserver 192.168.0.253
-----------------------------
Ensuite, je retourne dans le fichier /etc/bind/named.conf du PC DNS
"debian" et je commente/d�commente ce qu'il faut pour que bind9 soit
configur� pour la zone "mondomaine.chezmoi". C'est la m�me chose bien
s�r, juste le nom de la zone change. Ensuite, je fais :
/etc/init.d/bind9 restart # tout est ok, pas de message d'erreur !
Et l� tout marche !!!
host debian.mondomaine.chezmoi ---> marche
ping 192.168.0.253 # IP de "debian" ---> marche
ping debian.mondomaine.chezmoi ---> marche
Si j'�dite /etc/resolv.conf du pc client pour ajouter la ligne "domain
mondomaine.chezmoi", alors "ping debian" marche aussi. Bref, dans ce
test l�, tout fonctionne.
Avez vous une explication ? Est-ce un bug ? O� suis-je � c�t� de la plaque ?
PS : le pc client "franPC" est une Ubuntu 9.04 sur Gnome. Le DNS est une
machine virutelle debian lenny tournant sur l'h�te "franPC". Entre ces
deux machines, tous les pings avec adresse IP fonctionnent.
--
Fran�ois Lafont
YBM
...
> Avez vous une explication ? Est-ce un bug ? O� suis-je � c�t� de la
> plaque ?
La seule chose sp�cifique que je vois qui concerne le domaine de
premier niveau "local", est qu'il est suppos� �tre utilis� par
ZeroConf (alias "bonjour" chez Apple).
cf. http://en.wikipedia.org/wiki/Top-level_domain :
> .local deserves special mention as it is required by the Zeroconf
> protocol. It is also used by many organizations internally, which will
> become a problem for those users as Zeroconf becomes more popular. Both
> .site and .internal have been suggested for private usage, but no
> consensus has emerged
Sur ton poste client, est-ce que le d�mon avahi tourne ? (c'est le
d�mon qui impl�mente mDNS, �l�ment de ZeroConf). Pour en avoir le
coeur net, tu peux essayer de refaire tes tests avec le domaine
en .local une fois que avahi est arr�t� :
sudo /etc/init.d/avahi-daemon stop
YBM
Bingo ! c'est �a, sur un r�seau o� rien de sp�cial n'est
dit dans le DNS sur un domaine en .local, on a sur une Ubuntu :
$ hostname
otrante
$ host otrante.local
Host otrante.local not found: 3(NXDOMAIN)
$ ping -c 1 otrante.local
PING otrante.local (10.1.2.100) 56(84) bytes of data.
64 bytes from otrante.local (10.1.2.100): icmp_seq=1 ttl=64 time=0.036 ms
--- otrante.local ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.036/0.036/0.036/0.000 ms
$ sudo /etc/init.d/avahi-daemon stop
* Stopping Avahi mDNS/DNS-SD Daemon avahi-daemon [ OK ]
$ ping -c 1 otrante.local
ping: unknown host otrante.local
Les m�mes tests sur un serveur Debian o� ZeroConf/Avahi ne montrent
pas de comportement particulier de .local. Ce qui explique tes
probl�mes est que ZeroConf est automatiquement install� sur une
Ubuntu (et sans doute sous Windows aussi).
Conclusion : si tu tiens absolument � utiliser le domaine .local
sans avoir des bizarreries il faut d�sactiver compl�tement z�roconf
sur les postes clients (update-rc.d -f avahi-daemon remove ou bien
suprimer les allusions � mdns dans /etc/nsswitch.conf, � la ligne
"hosts").
AMHA, le mieux est d'utiliser autre chose que .local. .site par
exemple me semble pas mal.
En tout cas, gr�ce � toi je crois que pas mal de lecteurs du groupe,
dont moi, ont appris quelque chose aujourd'hui !
YBM
des DNS configur�s pour g�rer un domaine sous local. et
comment le g�rer proprement quand �a arrive :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393711
Il para�t que Microsoft conseille d'utiliser .local pour
un Active Directory hors Internet... sigh.
Francois
> Bingo ! [...]
Que n'ai-je pas fait de choisir un nom de domaine du type "*.local".
J'ai bloqu� pendant une semaine sur cette saloperie de daemon. C'est
quand m�me un peu l'usine � gaz tous ces couches de daemons qui
s'accumulent (en plus avec des noms de scripts de d�marrage dans
/etc/init.d/ souvent diff�rent du nom du processus qui tourne histoire
de rajouter un peu complexit�). Moi, je trouve que cette histoire
pourrait presque s'appeler un bug.
J'ai eu moins de souci pour param�trer "debian" install�e de fa�on
minimaliste, sans interface graphique etc. que pour param�trer ubuntu.
Mais c'est quoi ce ZeroConf ? Ici http://doc.ubuntu-fr.org/zeroconf, je
lis :
#-------------------------------------
ZeroConf
Le partage de ressources de mani�re transparente sur un r�seau local.
#-------------------------------------
Moralit� : m�fions nous de ce qui est transparent. Effectivement, avec
de dameon, chaque PC s'identifie sur le r�seau par <hostname>.local et
effectivement un "ping franPC.local" marche et si je stoppe
avahi-daemon, "ping franPC.local" ne marche plus, mais ping
franPC.mondomaine.local" marche. Bref, c'est source de conflit.
> Les m�mes tests sur un serveur Debian o� ZeroConf/Avahi ne montrent
> pas de comportement particulier de .local. Ce qui explique tes
> probl�mes est que ZeroConf est automatiquement install� sur une
> Ubuntu (et sans doute sous Windows aussi).
Ah, sur XP je n'ai eu aucune bizarrerie.
> Conclusion : si tu tiens absolument � utiliser le domaine .local
> sans avoir des bizarreries il faut d�sactiver compl�tement z�roconf
> sur les postes clients (update-rc.d -f avahi-daemon remove ou bien
> suprimer les allusions � mdns dans /etc/nsswitch.conf, � la ligne
> "hosts").
>
> AMHA, le mieux est d'utiliser autre chose que .local. .site par
> exemple me semble pas mal.
Je pense aussi. Mais je croyais bien faire en mettant .local � la fin.
Je l'ai fais car je suis � peu pr�s s�r d'avoir entendu quelque part
qu'il fallait mettre .local � la fin d'un nom de domaine local.
Maintenant, je pense exactement le contraire. :-)
> En tout cas, gr�ce � toi je crois que pas mal de lecteurs du groupe,
> dont moi, ont appris quelque chose aujourd'hui !
Et bien tant mieux. Personnellement, j'ai appris beaucoup tout au long
du fil, et bien au del� du canular ".local".
Merci beaucoup � Francis Chartier, � Antoine Emerit et aux autres pour
leurs messages/explications qui m'ont �t� tr�s pr�cieux. Je garde ce fil
dans mes favoris. Bravo � toi YBM pour avoir port� l'estocade.
--
Fran�ois Lafont
Francois
> Il para�t que Microsoft conseille d'utiliser .local pour
> un Active Directory hors Internet... sigh.
Et ben, c'est de l� que je tenais l'info selon laquelle il fallait
mettre ".local" dans le nom. Grrrr !!!
--
Fran�ois Lafont