Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[HS]: Prblème dans la résolution DNS

1 réponse
Avatar
Thierry Leurent
Bonjour,

Encore une fois, je viens vous présenter un problème abracadabrant de
relation conflictuelle entre Windows et Linux (Debian et RedHat)

La situation :
Une infrastructure basée sur Active Directory windows 2003, il y a 3 DC
qui répliquent l'ensemble de l'AD. Les 3 font office de DNS, les machines
ont une IP fixe encodée en "dur" dans chacunes d'elles (donc pas de DHCP).
Une partie de notre infrastrucutre logitielle est basée sur des serveurs
Linux intégrés à l'AD via SAMBA 3.5.11. Une partie de cette infrastructure
logitelle est basé sur CUPS et SAMBA afin que l'utilisateur puisse
imprimer sur son imprimante "personnelle" les documents générés sur le
serveur.
C'est à dire l'appli imprime le document sur l'imprimante partagé windows,
connectée en usb, via CUPS et SAMBA. Il n'y a pas de "filtre", un Firewall
par exemple, entre les serveurs Linux et Windows ni entre les serveurs et
les postes de travail.

Parfois, l'impression ne fonctionne pas et les logs de cups donnent les
messages suivants :
- Unable to connect to CIFS host, will retry in 60 seconds...
- Connection failed: NT_STATUS_NETWORK_UNREACHABLE

J'ai fini par sniffer la communiquation entre le serveur d'impression et
un pc posant problème. JE me suis alors rendu compte que ce problème se
produisait, le dns me retournait toujours un record SOA. Voici un excemple
recueilli avec scapy en réponse à une requête dns sur le même serveur.
|###[ DNS Resource Record ]###
| rrname= 'mydomain.be.'
| type= SOA
| rclass= IN
| ttl= 3600
| rdlen= 42
| rdata=
'\x0bmyDC1\xc0\x17\x05admin\xc0\x17\x00\x01n\xd8\x00\x00\x03\x84\x00\x00\x02X\x00\x01Q\x80\x00\x00\x0e\x10'
ar= None
Après vérifications :
- Seul la résolution DNS, lorsqu'elle est demandé par un client Linux ne
fonctionne pas. Je peux ping la machine en utilisant son IP.
- A un instant donné, ce problème est spécifique à une machine.
- Cela peut durer 2 minutes commes 2 heures
- Ce phénomène se produit aléatoirement. Bien que sur un prériode donnée,
nous pouvons identifier des postes qui sont plus souvent touchés que
d'autres. Mais cela peut changer dans la prériode suivante.
- Chacun des 3 DNS me répond de manière identique, la seule différence
notable est que son nom figure dans rdata.
- Quelque soit la distribution Linux, le problème est le même.
- Que le Linus soit dans le domain ou pas cela ne change rien.
- La résolution reverse DNS fonctionne.
- Un redémarrage du poste client Windows peut parfois résoudre le problème.

Voila tout ce que je sais

Merci

--
Thierry Leurent



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/6472546b1ace9c75dd693e3b8d78ec73.squirrel@ssl0.ovh.net

1 réponse

Avatar
Bzzz
On Wed, 20 Jun 2012 09:56:23 +0200
"Thierry Leurent" wrote:

Une infrastructure basée sur Active Directory windows 2003, il y a
3 DC qui répliquent l'ensemble de l'AD. Les 3 font office de DNS,
les machines ont une IP fixe encodée en "dur" dans chacunes
d'elles (donc pas de DHCP). Une partie de notre infrastrucutre



Il y a déjà qq chose de zarb: pourquoi sont-ce les w$ qui officie nt
en tant que svrs DNS, plutôt que de concentrer ça sur 2 ou 3 bind 9?

Ensuite, est-ce que hors svrs w$ "le reste" est en attribution DHCP,
et qui s'occupe de délivrer les leases?

Et finalement, est-ce qu'il n'y aurait pas un doublonnage DHCP (par
absence de coordination entre 2 svrs DHCP, par ex.)?
Ca pourrait expliquer l'impossibilité de CUPS de joindre la machine
appelante en retour.

Il-y-a aussi une possibilité (à très faible probabilité , mais
existante): je suis tombé un jour sur un PB d'impression/liaison
sur un segment qui paraissait normal (PB aléatoire justement /
tout en w$); après interrogation de l'admin local il s'est avér é
que 4 machines avaient tout récemment été ajoutées au r éseau.

On a donc retesté en branchant ces machines une à une et isolà ©
le PB, qui venait de sa carte Ethernet (une 10/100 Realtek de
base); hé bien elle avait la même adresse MAC qu'une autre!

Vu ce qu'il faut payer pour adhérer à l'organisme qui délivre
des segments officiels pour la numération des MACs, certains
petits fabricants passent outre et s'en remettent à la chance…

--
Chicagoan: "So, where're you from?"
Hoosier: "What's wrong with Indiana?"

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/