DNS-Abfragen können nicht ausgeführt werden, wenn die Antwort größer als 512 Bytes und abgeschnitten ist

TCP [RFC793] wird immer für vollständige Zonenübertragungen (unter Verwendung von AXFR) und häufig für Nachrichten verwendet, deren Größe die ursprüngliche 512-Byte-Grenze des DNS-Protokolls überschreitet.

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

ANALYSE:

Das war kniffliger als ich dachte. Also habe ich eine Ubuntu 18.04-VM in Azure hochgefahren, damit ich aus der Sicht des OP testen konnte:

Mein Ausgangspunkt war, zu validieren, dass nichts die DNS-Abfragen abwürgt:

sudo iptables -nvx -L
sudo apparmor_status

Alle Ketten in den iptables hatten ihre Standardrichtlinie auf AKZEPTIEREN gesetzt und zwar Apparmor wurde auf "erzwingen gesetzt ", es war nichts mit DNS zu tun. Daher wurden zu diesem Zeitpunkt keine Verbindungs- oder Berechtigungsprobleme auf dem Host beobachtet.

Als nächstes musste ich herausfinden, wie die DNS-Abfragen schlängelten sich durch die Gänge.

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

Also nach resolv.conf , erwartet das System einen lokalen Stub-Resolver namens systemd-resolved . Überprüfung des Status von systemd-resolved gemäß dem Hinweis im obigen Text sehen wir, dass es fehlerhaft ist :

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 Legen Sie die Reihenfolge der Quellen fest, die zum Auflösen von DNS-Abfragen verwendet werden. Was sagt uns das?:

hosts:          files dns

Nun, die DNS-Abfragen werden niemals den lokalen systemd-resolved treffen Stub-Resolver, da er nicht in /etc/nsswitch.conf angegeben ist .

Sind die Forwarder überhaupt für die systemd-resolved gesetzt Stub-Resolver?!?!? Sehen wir uns diese Konfiguration in /etc/systemd/resolved.conf an

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

Nein:systemd-resolved hat keine Weiterleitung, die fragt, ob eine lokale IP:Name-Zuordnung nicht gefunden wird.

Das Nettoergebnis von all dem ist:

• /etc/nsswitch.conf sendet DNS-Anfragen an DNS, wenn kein lokaler IP:name vorhanden ist Zuordnung gefunden in /etc/hosts

• Der abzufragende DNS-Server ist 127.0.0.53 und wir haben gerade gesehen, dass dies nicht konfiguriert ist, indem wir die Konfigurationsdatei /etc/systemd/resolved.conf überprüft haben . Wenn hier keine Weiterleitung angegeben ist, können wir nichts erfolgreich lösen.

TESTS:

Ich habe versucht, den Stub-Resolver 127.0.0.53 zu überschreiben durch direkte Angabe von 168.63.129.16. Dies ist fehlgeschlagen:

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

Nein:;; SERVER: 127.0.0.53#53(127.0.0.53) wird angezeigt in der Ausgabe sagt uns, dass wir es nicht überschrieben haben und der lokale, nicht konfigurierte Stub-Resolver immer noch verwendet wird.

Die Verwendung eines der folgenden Befehle überschreibt jedoch den Standardwert 127.0.0.53 Stub-Resolver und konnte daher erfolgreich NOERROR zurückgeben Ergebnisse:

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

oder

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

Also alle Abfragen, die sich auf die Verwendung von systemd-resolved stützten Stub-Resolver waren dem Untergang geweiht, bis er konfiguriert wurde.

LÖSUNG:

Meine Initiale - falsch - Glaube war, dass TCP/53 blockiert wurde:die ganze "Truncated 512 " war ein kleiner Ablenkungsmanöver. Der Stub-Resolver war nicht konfiguriert. Ich ging davon aus - ich weiß, ich weiß, "NIEMALS ANNAHME;-) - dass DNS anders konfiguriert war.

So konfigurieren Sie systemd-resolved :

Ubuntu 18.04

Bearbeiten Sie hosts Direktive in /etc/nsswitch.conf wie unten, indem Sie resolve voranstellen um systemd-resolved einzustellen als erste Quelle der DNS-Auflösung:

hosts:          resolve files dns

Bearbeiten Sie DNS Direktive (mindestens) in /etc/systemd/resolved.conf um Ihre gewünschte Weiterleitung anzugeben, die in diesem Beispiel wäre:

[Resolve]
DNS=168.63.129.16

Starten Sie systemd-resolved neu :

sudo systemctl restart systemd-resolved

RHEL 8:

Red Hat erledigt fast alles für Sie in Bezug auf die Einrichtung von systemd-resolved als Stub-Resolver, außer sie haben dem System nicht gesagt, dass es ihn verwenden soll!

Bearbeiten Sie den hosts Direktive in /etc/nsswitch.conf wie unten, indem Sie resolve voranstellen um systemd-resolved einzustellen als erste Quelle der DNS-Auflösung:

hosts:          resolve files dns

Starten Sie dann systemd-resolved neu :

sudo systemctl restart systemd-resolved

Quelle :https://www.linkedin.com/pulse/config-rhel8-local-dns-caching-terrence-houlahan/

SCHLUSSFOLGERUNG:

Einmal systemd-resolved konfiguriert war, verhielt sich das DNS meiner Test-VM wie erwartet. Ich denke, das reicht....