Impossible d'exécuter des requêtes DNS lorsque la réponse est supérieure à 512 octets et tronquée

"Quelqu'un peut-il expliquer pourquoi cela fonctionne comme ça et aider avec une solution, le cas échéant ? "

RÉPONSE COURTE :

Une machine virtuelle Azure par défaut est créée avec un DNS défectueux :systemd-resolved nécessite une configuration supplémentaire. sudo systemctl status systemd-resolved le confirmera rapidement. /etc/resolv.conf pointe vers 127.0.0.53 - un résolveur de stub local non configuré.

Le résolveur de stub local systemd-resolved n'était pas configuré. Il n'y avait pas de transitaire défini, donc après avoir atteint 127.0.0.53 il n'avait personne d'autre à qui demander. Pouah. Allez à la fin pour voir comment le configurer pour Ubuntu 18.04.

Si vous vous souciez de la façon dont cette conclusion a été tirée, veuillez lire la réponse longue.

RÉPONSE LONGUE :

Pourquoi les réponses DNS ont-elles été tronquées sur 512 octets :

TCP [RFC793] est toujours utilisé pour les transferts de zone complète (à l'aide d'AXFR) et est souvent utilisé pour les messages dont la taille dépasse la limite originale de 512 octets du protocole DNS.

Source :https://tools.ietf.org/html/rfc7766

ANALYSE :

C'était plus délicat que je ne le pensais. J'ai donc lancé une machine virtuelle Ubuntu 18.04 dans Azure afin de pouvoir tester du point de vue de l'OP :

Mon point de départ était de valider que rien n'étouffait les requêtes DNS :

sudo iptables -nvx -L
sudo apparmor_status

Toutes les chaînes dans les iptables avaient leur politique par défaut définie sur ACCEPTER et bien que Apparmor a été défini sur "appliquer ", ce n'était pas sur quoi que ce soit lié au DNS. Donc, aucun problème de connectivité ou d'autorisations n'a été observé sur l'hôte à ce stade.

Ensuite, j'ai dû établir comment les requêtes DNS s'enroulaient dans les engrenages.

cat /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 "systemd-resolve --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
search ns3yb2bs2fketavxxx3qaprsna.zx.internal.cloudapp.net

Donc selon resolv.conf , le système attend un résolveur de stub local appelé systemd-resolved . Vérification de l'état de systemd-resolved selon l'indice donné dans le texte ci-dessus, nous voyons qu'il est erroné :

sudo systemctl status systemd-resolved

● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2019-10-08 12:41:38 UTC; 1h 5min ago
     Docs: man:systemd-resolved.service(8)
           https://www.freedesktop.org/wiki/Software/systemd/resolved
           https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
           https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
 Main PID: 871 (systemd-resolve)
   Status: "Processing requests..."
    Tasks: 1 (limit: 441)
   CGroup: /system.slice/systemd-resolved.service
           └─871 /lib/systemd/systemd-resolved

Oct 08 12:42:14 test systemd-resolved[871]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
<Snipped repeated error entries>

/etc/nsswitch.conf définir les sources d'ordre des sources utilisées pour résoudre les requêtes DNS. Qu'est-ce que cela nous dit ? :

hosts:          files dns

Eh bien, les requêtes DNS n'atteindront jamais le systemd-resolved local résolveur de stub car il n'est pas spécifié dans /etc/nsswitch.conf .

Les transitaires sont-ils même définis pour le systemd-resolved résolveur de stub ?!?!? Passons en revue cette configuration dans /etc/systemd/resolved.conf

[Resolve]
#DNS=
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

Non :systemd-resolved n'a pas de redirecteur défini pour demander si un mappage ip:name local n'est pas trouvé.

Le résultat net de tout cela est :

/etc/nsswitch.conf envoie des requêtes DNS au DNS s'il n'y a pas d'IP :nom local mappage trouvé dans /etc/hosts
Le serveur DNS à interroger est 127.0.0.53 et nous venons de voir que ce n'est pas configuré en examinant son fichier de configuration /etc/systemd/resolved.conf . Sans transitaire spécifié ici, il est impossible que nous résolvions quoi que ce soit avec succès.

TEST :

J'ai essayé de remplacer le résolveur de stub 127.0.0.53 en spécifiant directement 168.63.129.16. Ceci a échoué :

dig aerserv-bc-us-east.bidswitch.net 168.63.129.16

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> aerserv-bc-us-east.bidswitch.net 168.63.129.16
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24224
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;168.63.129.16.         IN  A

;; Query time: 13 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 08 13:26:07 UTC 2019
;; MSG SIZE  rcvd: 42

Non :voir ;; SERVER: 127.0.0.53#53(127.0.0.53) dans la sortie nous indique que nous ne l'avons pas remplacé et que le résolveur de stub local non configuré est toujours utilisé.

Cependant, l'utilisation de l'une des commandes suivantes a remplacé la valeur par défaut 127.0.0.53 résolveur de stub et a donc réussi à renvoyer NOERROR résultats :

sudo dig aerserv-bc-us-east.bidswitch.net @168.63.129.16

dig +trace aerserv-bc-us-east.bidswitch.net @168.63.129.16

Ainsi, toutes les requêtes reposant sur l'utilisation du systemd-resolved résolveur de stub étaient condamnés jusqu'à ce qu'il soit configuré.

SOLUTION :

Mon initiale - incorrecte - la croyance était que TCP/53 était bloqué :l'ensemble "512 tronqué " était un peu un faux-fuyant. Le résolveur de stub n'était pas configuré. J'ai fait l'hypothèse - je sais, je sais, "NE JAMAIS ASSUMER ;-) - que le DNS était configuré autrement.

Comment configurer `systemd-resolved` :

Ubuntu 18.04

Modifiez le hosts directive en /etc/nsswitch.conf comme ci-dessous en ajoutant resolve pour définir systemd-resolved comme première source de résolution DNS :

hosts:          resolve files dns

Modifiez le DNS directive (au minimum) en /etc/systemd/resolved.conf pour spécifier le transitaire souhaité, qui dans cet exemple serait :

[Resolve]
DNS=168.63.129.16

Redémarrez systemd-resolved :

sudo systemctl restart systemd-resolved

RHEL 8 :

Red Hat fait presque tout pour vous en ce qui concerne la configuration de systemd-resolved en tant que résolveur de stub, sauf qu'ils n'ont pas dit au système de l'utiliser !