Forum Linux.général Pb résolution dns sur Ubuntu 20.04 en dhcp

Posté par  . Licence CC By‑SA.
Étiquettes :
2
1
fév.
2021

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  . Évalué à 1.

    Que donne un nslookup depuis une machine ubuntu ?
    Quel serveur est interrogé ?

    • [^] # Re: nslookup

      Posté par  . É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

      user@cheick-HP-ProBook-430-G7:~$ host web0.mydomain.local
    Host web0.mydomain.local not found: 3(NXDOMAIN)

user@HP-ProBook-430-G7:~$ nslookup web0.domain.local
Server:     ::1
Address:    ::1#53
server can't find web0.mydomain.local: NXDOMAIN
user@HP-ProBook-430-G7:~$

      et le contenu du fichier /etc/resolv.conf

      # This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad

  • # .local hors DNS ?

    Posté par  (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 et mdns (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.

  • # IPv6 / IPv4

    Posté par  . É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  . Évalué à 1.

      ok merci je vais tester.
      Comment fait on ça sur ubuntu ?

      • [^] # Re: IPv6 / IPv4

        Posté par  . Évalué à 2.

        temporairement avec les commandes

        echo 1>/proc/sys/net/all/disable_ipv6

        ou bien

        sysctl -w net. ipv6. conf. all. disable_ipv6=1

        de maniere systématique, en mettant ipv6_disable=1 au boot

  • # .local = multicatDNS

    Posté par  . É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  . É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  (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  . É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  . É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."

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.