web-dev-qa-db-fra.com

Serveur 18.04 - systemd-resolution renvoie le nom de fichier en cache NODATA pour une recherche

Résumé: la résolution des recherches d’enregistrements DNS A ne peut pas être résolue en raison des recherches NODATA CNAME en cache.

Détails: Le journal de messagerie signale des erreurs lors de recherches DNS:

 Host or domain name not found. Name service error for name=google.com type=A: Host found but no data record of requested type

Après avoir activé le débogage de résolution, je constate que les recherches DNS demandent tout d’abord l’enregistrement CNAME du domaine. C'est souvent le domaine racine qui n'a pas de CNAME et la recherche renvoie correctement NODATA.

Toutefois, lors de recherches ultérieures A, le résultat NODATA pour la recherche CNAME est renvoyé à partir du cache au lieu d'effectuer une recherche A.

Je peux recréer cela systématiquement en lançant les commandes suivantes:

~$ Dig google.com CNAME
~$ Dig google.com A

Voici les résultats du journal de débogage:

Aug 08 11:09:04 leopard systemd-resolved[555]: Transaction 17304 for <domain.com IN CNAME> scope dns on eth0/*.
Aug 08 11:09:04 leopard systemd-resolved[555]: Using feature level UDP+EDNS0 for transaction 17304.
Aug 08 11:09:04 leopard systemd-resolved[555]: Using DNS server 8.8.8.8 for transaction 17304.
Aug 08 11:09:04 leopard systemd-resolved[555]: Sending query packet with id 17304.
Aug 08 11:09:04 leopard systemd-resolved[555]: Processing query...
Aug 08 11:09:04 leopard systemd-resolved[555]: Processing incoming packet on transaction 17304. (rcode=SUCCESS)
Aug 08 11:09:04 leopard systemd-resolved[555]: Added NODATA cache entry for google.com IN CNAME 1799s
Aug 08 11:09:04 leopard systemd-resolved[555]: Transaction 17304 for <google.com IN CNAME> on scope dns on eth0/* now complete with <success> from network (unsigned).
Aug 08 11:09:04 leopard systemd-resolved[555]: Sending response packet with id 22860 on interface 1/AF_INET.
Aug 08 11:09:04 leopard systemd-resolved[555]: Freeing transaction 17304.

Résultats de la recherche record:

Aug 08 11:09:37 leopard systemd-resolved[555]: Processing query...
Aug 08 11:09:51 leopard systemd-resolved[555]: Got DNS stub UDP query packet for id 3119
Aug 08 11:09:51 leopard systemd-resolved[555]: Looking up RR for google.com IN A.
Aug 08 11:09:51 leopard systemd-resolved[555]: NODATA cache hit for google.com IN A
Aug 08 11:09:51 leopard systemd-resolved[555]: Transaction 45189 for <google.com IN A> on scope dns on eth0/* now complete with <success> from cache (unsigned).
Aug 08 11:09:51 leopard systemd-resolved[555]: Freeing transaction 45189.
Aug 08 11:09:51 leopard systemd-resolved[555]: Sending response packet with id 3119 on interface 1/AF_INET.

Informations complémentaires: le serveur exécute une pile LEMP. Il semble que nginx effectue une recherche DNS avant chaque demande et commence par une recherche CNAME, puis une recherche, puis une recherche AAAA. Cela provoque la mise en cache du CNAME NODATA. Par la suite, lorsque le serveur de messagerie tente d'envoyer du courrier, il récupère l'enregistrement NODATA en cache, ce qui entraîne l'erreur ci-dessus.

Questions: ce comportement attendu (CNAME est-il retourné pour une recherche)? Existe-t-il une configuration que je peux modifier pour empêcher les recherches CNAME en cache d'être renvoyées pour les recherches A?

Informations de diagnostic:

~$ ip route
default via 85.159.215.1 dev eth0 proto static 
85.159.215.0/24 dev eth0 proto kernel scope link src 85.159.215.159 


~$ Sudo 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 2 (eth0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 8.8.8.8
                      8.8.4.4


~$ cat /etc/resolv.conf
nameserver 127.0.0.53
networkingserverdnssystemd-resolved
4
mattf10

Cela semble être un réel problème pour la version de systemd utilisée actuellement par Ubuntu 18.04. https://github.com/systemd/systemd/issues/98 et également sur le tableau de bord https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/ 1818527

Pas sûr si Ubuntu mettra à niveau la version de systemd cependant.

1
morhook