Impossible de résoudre les domaines .local internes à mon réseau local de bureau
Sous Linux Debian 9, je suis en mesure de résoudre un domaine local spécifique, par exemple my.sample-domain.local En utilisant certaines commandes comme nslookup ou Host, mais pas avec d'autres commandes comme ping ou le client Postgres psql.
Je pense que des choses comme Network Manager ont correctement configuré mon résolveur DNS (le contenu de /etc/resolv.conf), Donc je ne sais pas pourquoi cela se produit?
J'ai vérifié avec un collègue utilisant Windows 10 et ils n'ont aucune entrée personnalisée dans leur fichier hôte, bien que dans leur cas, la version Windows de ping et leur interface de base de données pour Postgres fonctionne comme prévu en résolvant le domaine en un Adresse IP.
Veuillez voir ci-dessous:
$ ping my.sample-domain.local
ping: my.sample-domain.local: Name or service not known
$ Host my.sample-domain.local
my.sample-domain.local has address <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>
$ ping -c 5 <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>
PING <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN> (<THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>) 56(84) bytes of data.
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=1 ttl=128 time=1.16 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=2 ttl=128 time=0.644 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=3 ttl=128 time=0.758 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=4 ttl=128 time=0.684 ms
64 bytes from <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>: icmp_seq=5 ttl=128 time=0.794 ms
--- <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN> ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4056ms
rtt min/avg/max/mdev = 0.644/0.808/1.160/0.183 ms
$ nslookup my.sample-domain.local
Server: <THE_IP_REPRESENTING_THE_NAMESERVER>
Address: <THE_IP_REPRESENTING_THE_NAMESERVER>#53
Non-authoritative answer:
Name: my.sample-domain.local
Address: <THE_IP_REPRESENTING_THE_LOCAL_DOMAIN>
$ cat /etc/resolv.conf
domain <AN_INTERNAL_DOMAIN>
search <AN_INTERNAL_DOMAIN>
nameserver <THE_IP_REPRESENTING_THE_NAMESERVER>
nameserver <ANOTHER_IP_REPRESENTING_THE_NAMESERVER>
MODIFIER:
Pendant ce temps, je me suis rendu compte qu'il y avait une machine virtuelle Ubuntu 16 dans le même LAN de bureau, alors je me suis connecté et j'ai essayé la commande ping qui fonctionne là-bas.
De plus, Ubuntu VM n'a pas de paramètre personnalisé particulier dans /etc/hosts (Le même que mon portable Debian 9 avec /etc/hosts Non personnalisé)).
Les deux /etc/resolv.conf Se ressemblent (certains domaines/IP partagés, d'autres IP pour le même domaine).
Cependant, le fichier /etc/nsswitch.conf Est différent, donc je pense qu'il se passe quelque chose avec ce mdsn4_minimal Et l'ordre de résolution des hôtes là-dedans comme mdsn4_minimal Avant dns:
hosts: files mdns4_minimal [NOTFOUND=return] dns
et sur Ubuntu:
hosts: files dns
MODIFIER 2:
Ubuntu 16 VM et mon ordinateur portable Debian 9 sont capables de résoudre ce domaine .local À l'aide de la commande Dig.
Host et nslookup effectuent des recherches DNS, mais la plupart des applications utilisent le commutateur de service de noms de la glibc pour décider de l'apparence des noms d'hôte vers le haut.
Votre /etc/nsswitch.conf pourrait activer mDNS, ce qui pourrait entraîner des problèmes lors de la résolution de .local noms. Vous pouvez modifier l'ordre dans lequel les recherches sont effectuées ou simplement supprimer le service mDNS si vous pensez que vous n'en aurez pas besoin.
Votre nsswitch.conf a mdns4_minimal, ce qui fait mDNS recherche (pour .local noms). Le [NOTFOUND=return] après avoir provoqué l'arrêt de la recherche et par conséquent, DNS n'est jamais utilisé et votre application ne peut pas résoudre le nom d'hôte. Vous pouvez soit supprimer l'ensemble mdns4_minimal [NOTFOUND=return], afin que les recherches mDNS ne soient pas utilisées, ou supprimez simplement l'action NOTFOUND pour que la recherche DNS soit effectuée en cas d'échec de la recherche mDNS.
Pour plus de détails, je recommande de consulter la documentation Name Service Switch .
Le plus gros problème est le suivant: il s'agit de noms de domaine DNS connus se terminant par .local ne doit pas être utilisé lors de la configuration des infrastructures DNS.
.local l'utilisation est réservée à l'utilisation de zeroconf/avahi aka bonjour, qui sont des services parallèles pour résoudre les noms/services locaux en plus du DNS.
Votre service de noms DNS interne rencontre très certainement des conflits avec zeroconf dans certains scénarios. Ainsi, la solution dans la question que vous avez acceptée.
À plus long terme, le nom DNS de votre réseau interne ne devrait pas se terminer par .local.
PS En passant, outre DNS, les DC/AD Microsoft locaux ne doivent pas être nommés .local aussi. Vous aurez d'étranges problèmes si vous le faites.
Norme DNS multidiffusion (mDNS).
. résolu via le protocole de résolution de nom DNS multidiffusion.
De MS Technet (wikipedia)
Si vous avez des ordinateurs clients Macintosh qui exécutent le système d'exploitation Macintosh OS X version 10.3 ou version ultérieure,… il est recommandé de ne pas utiliser l'étiquette .local pour le nom DNS complet de votre domaine interne. Si vous devez utiliser l'étiquette .local, vous devez également configurer les paramètres sur les ordinateurs Macintosh afin qu'ils puissent découvrir d'autres ordinateurs sur le réseau
RFC 6762
Toute requête DNS pour un nom se terminant par ".local". DOIT être envoyé au
Adresse de multidiffusion locale de liaison mDNS IPv4 224.0.0.251 (ou son IPv6
équivalent FF02 :: FB).
......
Mappage d'adresse inversée
Comme ".local", les domaines de mappage inversé IPv4 et IPv6 sont également définis pour être locaux de liaison:
Toute requête DNS pour un nom se terminant par "254.169.in-addr.arpa". DOIT être envoyé à l'adresse de multidiffusion mDNS IPv4 liaison locale 224.0.0.251 ou à l'adresse de multidiffusion mDNS IPv6 FF02 :: FB. Étant donné que les noms sous ce domaine correspondent aux adresses IPv4 de liaison locale, il est logique que le lien local soit le meilleur endroit pour trouver des informations relatives à ces noms.
......
Aucun contrôle spécial n'est nécessaire pour activer et désactiver le DNS multidiffusion pour les noms se terminant explicitement par ".local". tel que saisi par l'utilisateur.
. .
Si un utilisateur saisit un nom se terminant par ".local.", Alors nous pouvons sans risque supposer que l'intention de l'utilisateur était probablement qu'il devrait marcher.
Bien qu'il ne provienne pas d'une source officielle, j'ai également trouvé cela, qui contient un paragraphe qui explique bien le problème: Arrêtez d'utiliser .local comme domaine de premier niveau pour votre réseau local
Le domaine .local est ce qu'on appelle un domaine de pseudo-niveau supérieur. Qu'est-ce que ça veut dire? Cela signifie qu'il ne s'agit pas d'un domaine officiel de premier niveau utilisable (routable) sur Internet, mais il a un statut semi-officiel car il est utilisé dans certaines applications.
Dans le cas de .local, il est utilisé par le Multicast Domain Name Service (mDNS). Les hôtes qui implémentent ce service utilisent .local comme nom de domaine et ont leur propre façon de résoudre les noms. Normalement, ce ne serait pas un problème; cependant, si vous implémentez également DNS sur votre réseau avec .local comme domaine de premier niveau, cela entraînera de graves problèmes de résolution de noms.
J'ai vu cela se produire souvent sur les systèmes Linux, et j'imagine que l'OS X d'Apple aura probablement aussi ces problèmes. Habituellement, sur ces types de réseaux, vous constatez que la résolution de noms DNS ne fonctionne pas du tout ou ne fonctionne que de temps en temps. En fin de compte, vous finissez par avoir à utiliser des adresses IP tout le temps parce que vous ne savez pas si un nom peut résoudre ou non (ce qui nie tout l'intérêt d'avoir un serveur DNS en premier lieu).
Vous avez peut-être un NBNS en conflit avec un DNS , corrigez-le ou modifiez votre fichier hosts , ou encapsulez vos commandes;
NAME=my.sample-domain.local
ping $(Host $NAME | Perl -pe 's/.* //g')
Le DNS doit être inspecté avec Dig ;
Dig @$SERVER $NAME +short
Je suppose que Host recherche d'abord NBNS (ou l'inverse).