Nelze spustit dotazy DNS, když je odpověď větší než 512 bajtů a je zkrácená

„Může někdo prosím poskytnout nějaké informace o tom, proč to takto funguje, a pomoci s nějakým řešením, pokud nějaké existuje? "

."

KRÁTKÁ ODPOVĚĎ:

Vytvoří se výchozí virtuální počítač Azure s poškozeným DNS:systemd-resolved potřebuje další konfiguraci. sudo systemctl status systemd-resolved to rychle potvrdí. /etc/resolv.conf ukazuje na 127.0.0.53 - místní nenakonfigurovaný stub resolver.

Lokální stub resolver systemd-resolved byl nenakonfigurován. Nemělo nastaveno žádné předávání, takže po stisknutí 127.0.0.53 neměl se koho jiného zeptat. Fuj. Přejděte na konec a podívejte se, jak jej nakonfigurovat pro Ubuntu 18.04.

Pokud vás zajímá, jak bylo dosaženo tohoto závěru, přečtěte si prosím Dlouhou odpověď.

DLOUHÁ ODPOVĚĎ:

Proč byly odpovědi DNS zkráceny na více než 512 bajtů:

TCP [RFC793] se vždy používá pro přenosy celé zóny (pomocí AXFR) a často se používá pro zprávy, jejichž velikost přesahuje původní limit 512 bajtů protokolu DNS.

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

ANALÝZA:

Tohle bylo složitější, než jsem si myslel. Takže jsem stočil virtuální počítač Ubuntu 18.04 v Azure, abych mohl testovat z pohledu OP:

Mým výchozím bodem bylo ověřit, že nic neškrtí dotazy DNS:

sudo iptables -nvx -L
sudo apparmor_status

Všechny řetězce v iptables měli výchozí zásady nastaveny na AKCEPTOVAT a přestože Apparmor byla nastavena na „vynucování ", nebylo to na ničem, co by se týkalo DNS. Takže v tomto okamžiku nebyly na hostiteli pozorovány žádné problémy s připojením nebo oprávněními.

Dále jsem potřeboval stanovit jak DNS dotazy se vinou soukolím.

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

Tedy podle resolv.conf , systém očekává lokální stub resolver s názvem systemd-resolved . Kontrola stavu systemd-resolved podle nápovědy v textu výše vidíme, že je to chybné :

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 nastavit zdroje pořadí zdrojů použitých k vyřešení dotazů DNS. Co nám to říká?:

hosts:          files dns

No, DNS dotazy nikdy nenarazí na místní systemd-resolved stub resolver, protože není specifikován v /etc/nsswitch.conf .

Jsou přeposílání dokonce nastaveny na systemd-resolved stub resolver?!?!? Podívejme se na tuto konfiguraci v /etc/systemd/resolved.conf

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

Ne:systemd-resolved nemá nastaven žádný forwarder, který by se zeptal, zda není nalezeno místní mapování ip:name.

Čistý výsledek toho všeho je:

• /etc/nsswitch.conf odešle dotazy DNS na DNS, pokud neexistuje místní IP:name mapování nalezeno v /etc/hosts

• Server DNS, na který se má dotazovat, je 127.0.0.53 a právě jsme viděli, že to není nakonfigurováno při kontrole jeho konfiguračního souboru /etc/systemd/resolved.conf . Není-li zde uveden žádný přeposílání, neexistuje způsob, jak něco úspěšně vyřešit.

TESTOVÁNÍ:

Pokusil jsem se přepsat stub resolver 127.0.0.53 přímým uvedením 168.63.129.16. Toto se nezdařilo:

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

Ne:viz ;; SERVER: 127.0.0.53#53(127.0.0.53) ve výstupu nám říká, že jsme to nepřepsali a místní, nenakonfigurovaný stub resolver se stále používá.

Použití některého z následujících příkazů však přepíše výchozí 127.0.0.53 stub resolver, a proto se mu podařilo vrátit NOERROR výsledky:

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

nebo

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

Tedy všechny dotazy, které se spoléhaly na použití systemd-resolved stub resolver byly odsouzeny k záhubě, dokud nebyl nakonfigurován.

ŘEŠENÍ:

Moje iniciála- nesprávná - přesvědčení bylo, že TCP/53 byl blokován:celý „Zkrácený 512 “ byl trochu červený sleď. Překladač útržků nebyl nakonfigurován. Předpokládal jsem – já vím, já vím, „NIKDY NEPŘEDPOVÍDEJTE;-) – že DNS byl nakonfigurován jinak.

Jak nakonfigurovat systemd-resolved :

Ubuntu 18.04

Upravte hosts direktiva v /etc/nsswitch.conf jako níže přidáním resolve nastavte systemd-resolved jako první zdroj překladu DNS:

hosts:          resolve files dns

Upravte DNS direktiva (minimálně) v/etc/systemd/resolved.conf k zadání požadovaného přeposílání, což by v tomto příkladu bylo:

[Resolve]
DNS=168.63.129.16

Restartujte systemd-resolved :

sudo systemctl restart systemd-resolved

RHEL 8:

Red Hat udělá téměř vše za vás, pokud jde o nastavení systemd-resolved jako stub resolver, kromě toho, že neřekli systému, aby to použil!

Upravte hosts direktiva v /etc/nsswitch.conf jako níže přidáním resolve nastavte systemd-resolved jako první zdroj překladu DNS:

hosts:          resolve files dns

Poté restartujte systemd-resolved :

sudo systemctl restart systemd-resolved

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

ZÁVĚR:

Jednou systemd-resolved byl nakonfigurován DNS mého testovacího VM se choval očekávaným způsobem. Myslím, že to asi dělá...