DNS sur 127.0.0.53 de systemd ignore certaines recherches


14

Le DNS de systemd adoré à 127.0.0.53 semble fonctionner sauf lorsque je recherche des machines locales par nom. Mais si je les interroge et spécifie spécifiquement le serveur DNS local (mon routeur), j'obtiens la bonne réponse. Mais le fichier de configuration indique qu'il utilise également le routeur comme adresse de recherche. Des pensées?

J'utilise Ubuntu 18.04 sur mon ordinateur portable Dell.

Résultats incorrects:

$ nslookup web1

Server:     127.0.0.53
Address:    127.0.0.53#53

** server can't find web1: SERVFAIL

Échoue également

$ nslookup -i wlp3s0 web1
nslookup: couldn't get address for 'web1': not found

Résultats corrects:

$ nslookup web1 192.168.1.1

Server:     192.168.1.1
Address:    192.168.1.1#53

Name:   web1
Address: 192.168.1.107

Informations de configuration systemd-resolver

$ systemd-resolve --status

Global
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

Link 3 (wlp3s0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.1.1
          DNS Domain: wp.comcast.net

Link 2 (enp2s0)
      Current Scopes: none
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

Informations de configuration NetworkManager

$ cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

[device]
wifi.scan-rand-mac-address=no

Alors, comment puis-je obtenir nslookup pour retourner la bonne réponse? Le lien 3 semble être les informations correctes (ma connexion wifi) et mon DNS sur le routeur renvoie la bonne réponse mais le cache local n'essaie jamais de rechercher l'adresse (ou du moins il semble).


Consultez cet article et voyez si cela résout votre problème: askubuntu.com/questions/1034064/…

Je n'ai pas dns = dnsmasq dans mon fichier de configuration. Je mets à jour ma question pour le montrer.
schworak

Quelle version d'Ubuntu utilisez-vous et pouvez-vous également mettre à jour votre publication avec la configuration IP?

J'utilise Ubuntu 18.04 sur un ordinateur portable Dell.
schworak

pourriez-vous plz essayernslookup -i wlp3s0 web1
cmak.fr

Réponses:


9

Votre fichier resolv.conf ne pointait pas au mauvais endroit - ../run/systemd/resolve/stub-resolv.conf c'est là qu'il est censé pointer par défaut.

Le problème est que les systemd-resolvednoms non pointés ne sont pas transmis au DNS. Apparemment, cela fonctionne "comme prévu". Voir ce problème de github qui déclare que «résolu ne permettra jamais aux recherches en une seule étiquette de fuir sur le DNS unicast».

Que vous soyez d'accord ou non avec le raisonnement de cette question github, il existe un moyen de résoudre ce problème. Cela ne nécessite même pas de modifier la configuration par défaut de votre machine Ubuntu:

  1. Tout d'abord, le DNS de votre LAN doit avoir un nom de domaine.

    Si vous utilisez dnsmasq, ajoutez ce qui suit /etc/dnsmasq.confsur votre serveur DNS:

    expand-hosts
    domain=your-domain # replace "your-domain" with domain of your choice
    

    Vous devriez maintenant être en mesure de résoudre les noms d'hôtes LAN si vous ajoutez le domaine:

    nslookup web1.your-domain
    
  2. Ensuite, assurez-vous que le nom du domaine de votre LAN est également défini dans votre serveur DHCP s'il est différent de votre serveur DNS. Sur mon serveur DHCP (mon routeur), ce paramètre est simplement appelé "Nom de domaine".

    Si vous renouvelez ensuite votre bail DHCP sur votre box Ubuntu, vous devriez voir une directive de recherche apparaître dans /run/systemd/resolve/stub-resolv.conf:

    nameserver 127.0.0.53
    search your-domain
    

Maintenant, la recherche web1le développera web1.your-domain, ce qui résoudra ensuite en utilisant DNS.

$ nslookup web1
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   web1.your-domain
Address: 192.168.1.107

Notez que si vous utilisez digau lieu de nslookup, dign'utilise pas le chemin de recherche par défaut - utilisez son +searchoption pour l'activer.


Avant de redémarrer, il a bien recherché web1.mydomain.com. Mais bien sûr, rechercher uniquement web1 n'a pas fonctionné. J'ai donc redémarré et pour la vie de moi, je n'ai aucune idée où il récupère le domaine Comcast, mais maintenant, si je recherche web1, il répond avec l'IP correcte mais montre le domaine comcast au lieu de mon domaine. Il résout donc je ne suis pas trop inquiet mais que diable ????
schworak

@schworak Weird! Votre serveur DHCP est-il également votre modem Comcast? Voyez-vous ce domaine apparaître dans /etc/resolv.confou dans la sortie de nmcli -g allou systemd-resolve --status? Essayez peut-être de regarder ce qui est dans votre bail DHCP ?
Laurence Gonsalves

Ce n'est pas le modem comcast. J'ai un routeur SysLink avec DDWRT en cours d'exécution. Les paramètres de comcast sont totalement remplacés. Le nom comcast apparaît dans le fichier resolv.conf qui est généré automatiquement au démarrage. Je ne suis pas trop inquiet mais c'est bizarre.
schworak

@LaurenceGonsalves Merci beaucoup pour le lien vers le problème de github. J'avais trouvé des solutions à ce problème, mais cela m'a en fait aidé à comprendre le problème racine.
Gregory Arenius

19

J'ai trouvé le correctif qui fonctionnait pour moi.

mon fichier resolv.conf pointait au mauvais endroit. Cela semble être un bug dans Ubuntu car il s'est produit sur mon ordinateur portable (la machine sur laquelle j'ai remarqué ce problème pour la première fois) et sur une nouvelle installation d'Ubuntu 18.04 Server.

Le défaut

$ ls -l /etc/resolv.conf

lrwxrwxrwx 1 root root 39 Apr 26 12:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

J'ai supprimé cela et pointé vers le bon fichier. Après le redémarrage, cela a résolu mon problème. Et j'ai même pu changer de réseau sur mon ordinateur portable et le DNS a été commuté correctement. Bien sûr, lorsque je suis sur des réseaux externes, je ne peux résoudre aucune de mes machines locales, mais cela est attendu. Dès que je reviens à mon réseau local, toutes les machines locales se résolvent correctement car mon routeur est le DNS.

The Fix

$ sudo rm -f /etc/resolv.conf
$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf

lrwxrwxrwx 1 root root 32 May 29 08:48 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

$ sudo reboot

Après cela, tout a fonctionné comme prévu et 127.0.0.53 n'est plus utilisé du tout.

Les bons résultats

$ nslookup web1

Server:     192.168.1.1
Address:    192.168.1.1#53

Name:   web1
Address: 192.168.1.107

$ nslookup google.com

Server:     192.168.1.1
Address:    192.168.1.1#53

Non-authoritative answer:
Name:   google.com
Address: 172.217.7.174
Name:   google.com
Address: 2607:f8b0:4004:80e::200e

Veuillez signaler ce bogue en utilisant ubuntu-bug resolvconf.
Chai T. Rex

Quand je commence à l'envoyer, il dit resolvconf (non installé). Resolvconf et systemd-resolve sont-ils la même chose?
schworak

systemd-resolveest fourni par le systemdpaquet , veuillez donc essayer à la ubuntu-bug systemdplace.
Chai T. Rex

Merci! Je n'avais jamais utilisé cette fonctionnalité de rapport de bogue auparavant. Très agréable.
schworak

1
Wow, c'est fou. Je vous remercie. Ce bug a-t-il déjà été corrigé? Est-ce un bug spécifique à Docker? Je pense que le resolv.confest configuré de cette façon pour le DNS du réseau de docker bridge, non?
void.pointer
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.