Bonjour,
J'ai un problème de résolution DNS interne de plus en plus gênant sur les postes de devloppeurs qui sont en Ubuntu 20.04 en DHCP.
Le postes ne savent pas resoudre les noms en mycompany.local.
Pas de problème avec les noms dns public mais les noms en .local ne fonctionnent pas.
Les serveurs DNS fournit par le DHCP sont les bons (des serveurs DNS Windows).
Ce sont également ces serveurs DNS Windows qui sont SOA des zones en .local.
C'est vraiment problèmatique car à chaque fois qu'un dev me décrit le pb je suis obligé de lui dire de mettre l'entrée dans le fichier hosts.
Quelqu'un peut il me dire comment on configure les workstations Ubuntu pour que la résolution DNS fonctionne correctement.
Je précise que les postes Windows n'ont pas ce problème.
Merci de votre aide
# nslookup
Posté par zedS . Évalué à 1.
Que donne un nslookup depuis une machine ubuntu ?
Quel serveur est interrogé ?
[^] # Re: nslookup
Posté par Orwell . Évalué à 1. Dernière modification le 01 février 2021 à 17:42.
Voici le résultat des commandes host web0.mydomain.local et nslookup web0.mydomain.local
et le contenu du fichier /etc/resolv.conf
# .local hors DNS ?
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 01 février 2021 à 14:26.
Il me semble que le
.local
est hors DNS et est juste déclaratif de chacun (protocole Bonjour de Apple)Il te faut vérifier que zeroconf est bien présent.
Les mots-clés pour chercher sont
zeroconf
,avahi
etmdns
(plus ou moins synonymes, j'avoue que j'ai jamais trop compris comment ça s'imbrique tout ça).Après j'ai déjà eu des soucis entre plusieurs réseaux (style l'objet
.local
est sur le WiFi et tu tentes d'y accéder en réseau filaire), là il faut voir les règles de broadcast.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: .local hors DNS ?
Posté par Sylvain (site web personnel) . Évalué à 2.
Je plussoie le .local c'est une source a emmerde, faut absolument eviter d'utiliser ce nom, les equipements/services reseaux/navigateur on une gestion incoherente/heterogene du .local
https://www.reddit.com/r/sysadmin/comments/2qu6lr/why_shouldnt_i_name_my_ad_domain_domainlocal/
[^] # Re: .local hors DNS ?
Posté par Tonton Th (Mastodon) . Évalué à 3.
Justement, j'ai eu à me pencher là-dessus il y a quelques semaines, et c'est pas clair du tout pour moi. Si quelqu'un d'entre vous connait une synthèse du pourquoi et du comment, une petite
[url]
serait appréciée par un grand nombre de moules…# IPv6 / IPv4
Posté par Yves Bourguignon . Évalué à 2.
A tester en désactivant IPv6 sur les clients Linux car possiblement les requêtes peuvent échouer à cause d'un enregistrement IPv6 absent sur le serveur.
[^] # Re: IPv6 / IPv4
Posté par Orwell . Évalué à 1.
ok merci je vais tester.
Comment fait on ça sur ubuntu ?
[^] # Re: IPv6 / IPv4
Posté par NeoX . Évalué à 2.
temporairement avec les commandes
ou bien
de maniere systématique, en mettant ipv6_disable=1 au boot
# .local = multicatDNS
Posté par WhiteCat . Évalué à 6. Dernière modification le 01 février 2021 à 19:27.
Aaaahh les fameux domaines .local !
J'ai presque toujours vu les AD Windows des boites configurés comme ça alors que c'est une TLD réservé au multicast DNS. Bravo à Microsoft et aux admins… :-)
Bref, je suis quasiment sûr que tes machines sont configurées pour checker en 1er le multicastDNS avant le DNS, comme c'est le cas par exemple sur ma Fedora par exemple :
$ cat /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns
Sur Fedora la résolution DNS est faite en dernier !
Le module mdns4_minimal ne fait que de la résolution d'adresses en .local. Vu qu'il ne trouve rien en mDNS correspondant à tes entrées, il stoppe complètement la résolution à cause du "[NOTFOUND=return]". Donc le DNS n'est jamais cherché.
Normalement en enlevant le "mdns4_minimal [NOTFOUND=return]" de la ligne, tes résolutions DNS devraient fonctionner, par exemple :
$ cat /etc/nsswitch.conf
hosts: files resolve [!UNAVAIL=return] myhostname dns
[^] # Uniquement en VPNSSL
Posté par Orwell . Évalué à 1.
Hello,
Merci de vos réponses.
Finalement j'ai pu observer que le problème ne se produit qu'en VPNSSL.
J'utilise le VPNSSL intégré à mes Firewalls (Fortinet forticlient) et quand je suis connecté avec forticlient depuis un poste Linux la résolution dns des noms en .local ne fonctionne pas.
Je vais ouvrir un ticket chez l'éditeur.
Merci encore pour votre aide
[^] # Re: Uniquement en VPNSSL
Posté par Sylvain (site web personnel) . Évalué à 1.
Parceque Linux et MacOS respecte les standards sur le .local et pas windows.
Forti ne t'aidera pas sur le sujet.
[^] # Re: Uniquement en VPNSSL
Posté par Orwell . Évalué à 1.
Ok mais je n'ai pas bien compris quel est le standard et qu'est-ce qui pose problème avec les noms en .local.
Sauf erreur de ma part ce n'est pas un nom de domaine public. Alors pourquoi serait il déconseillé de l'utiliser à usage privé?
Si quelqu'un peut vulgariser pour moi sans me renvoyer à une RFC encyclopédique et de surcroit en anglais.
Et désolé je viens de monde MS (mais je ne prends pas partie).
Merci pour vos explications
[^] # Re: Uniquement en VPNSSL
Posté par WhiteCat . Évalué à 2.
En 2013 est apparu une RFC qui dévoile un nouveau protocole : multicast DNS.
Le but de ce protocole est de pouvoir faire de la résolution de noms sur un réseau local, là où un serveur DNS n'existe pas par exemple. Typiquement un LAN à la maison.
Or ce protocole spécifie que son "champ d'application" est limité au domaine en .local.
Autrement dit, les implémentations de ce protocole s'occuperont de faire de la résolution de noms uniquement sur des appareils qui disposent d'un nom sur ce domaine.
Et c'est là que c'est malheureux car depuis 2 ou 3 décennies, Microsoft a pu documenté ici ou là des tutos, documentation, etc. avec des déploiement d'AD en .local.
Ce TLD étant "libre", il n'y avait a priori pas de problèmes (mêmes si j'entends de plus en plus aujourd'hui que c'est une mauvaise idée d'utiliser un TLD qui n'existe pas, mais bref).
Or du jour au lendemain, ce TLD est officiellement déclaré comme spécifique à un protocole (en l’occurrence mDNS) !
Et donc aujourd'hui les OS qui veulent se conformer à la RFC pour couvrir le multicast DNS doivent faire ce qui est indiqué dans cette RFC, qui dit que les noms en .local doivent être résolues en priorité par un résolveur mDNS.
Extraits de la RFC :
"This document specifies that the DNS top-level domain ".local." is a
special domain with special semantics, […], and names within
this domain are meaningful only on the link where they originate."
"Any DNS query for a name ending with ".local." MUST be sent to the
mDNS IPv4 link-local multicast address 224.0.0.251"
"Using ".local" as a private top-level domain conflicts with
Multicast DNS and may cause problems for users.
[…] Because of this, we recommend against using ".local" as
a private Unicast DNS top-level domain. We do not recommend use
of unregistered top-level domains at all, but […] the following
top-level domains have been used on private internal networks
without the problems caused by trying to reuse ".local." for this purpose:
.intranet.
.internal.
.private.
.corp.
.home.
.lan."
[^] # Re: Uniquement en VPNSSL
Posté par Sylvain (site web personnel) . Évalué à 1. Dernière modification le 04 février 2021 à 19:50.
Depuis microsft ne le recommande plus d'ailleurs et conseil de changer de TLD pour ceux qui ont un .local car cela ne fonctionne pas avec AZURE AD.
https://docs.microsoft.com/fr-fr/microsoft-365/enterprise/prepare-a-non-routable-domain-for-directory-synchronization?view=o365-worldwide
[^] # Re: Uniquement en VPNSSL
Posté par Orwell . Évalué à 1.
Ok, c'est très clair.
Merci
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.