Impossibile eseguire query DNS quando la risposta è maggiore di 512 byte e viene troncata

"Qualcuno può fornire alcune informazioni sul motivo per cui funziona in questo modo e aiutare con qualche soluzione, se presente? "

RISPOSTA BREVE:

Viene creata una macchina virtuale di Azure predefinita con DNS interrotto:systemd-resolved necessita di ulteriore configurazione. sudo systemctl status systemd-resolved lo confermerà rapidamente. /etc/resolv.conf punta a 127.0.0.53 - uno stub resolver locale non configurato.

Il risolutore di stub locale systemd-resolved non era configurato. Non aveva un forwarder impostato così dopo aver colpito 127.0.0.53 non aveva nessun altro a cui chiedere. Uffa. Vai alla fine per vedere come configurarlo per Ubuntu 18.04.

Se ti interessa sapere come si è giunti a tale conclusione, leggi la risposta lunga.

RISPOSTA LUNGA:

Perché le risposte DNS sono state troncate oltre i 512 byte:

TCP [RFC793] viene sempre utilizzato per i trasferimenti di zona completi (utilizzando AXFR) ed è spesso utilizzato per i messaggi le cui dimensioni superano il limite originale di 512 byte del protocollo DNS.

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

ANALISI:

Questo è stato più complicato di quanto pensassi. Quindi ho avviato una VM Ubuntu 18.04 in Azure in modo da poter testare dal punto di vista dell'OP:

Il mio punto di partenza era verificare che nulla stesse soffocando le query DNS:

sudo iptables -nvx -L
sudo apparmor_status

Tutte le catene in iptables avevano la norma predefinita impostata su ACCETTA e anche se Apparmor era impostato su "applicazione ", non riguardava nulla che riguardasse il DNS. Quindi, a questo punto, non sono stati osservati problemi di connettività o di autorizzazione sull'host.

Poi dovevo stabilire come le query DNS si stavano esaurendo.

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

Quindi secondo resolv.conf , il sistema prevede un risolutore di stub locale chiamato systemd-resolved . Verifica dello stato di systemd-resolved per il suggerimento dato nel testo sopra vediamo che è errato :

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 impostare l'ordine delle origini delle origini utilizzate per risolvere le query DNS. Cosa ci dice questo?:

hosts:          files dns

Bene, le query DNS non raggiungeranno mai il systemd-resolved locale stub resolver poiché non è specificato in /etc/nsswitch.conf .

Gli spedizionieri sono impostati anche per il systemd-resolved risolutore stub?!?!? Rivediamo quella configurazione in /etc/systemd/resolved.conf

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

No:systemd-resolved non ha un server d'inoltro impostato per chiedere se non viene trovata una mappatura ip:nome locale.

Il risultato netto di tutto ciò è:

• /etc/nsswitch.conf invia query DNS a DNS se non è presente un IP:nome locale mappatura trovata in /etc/hosts

• Il server DNS da interrogare è 127.0.0.53 e abbiamo appena visto che questo non è configurato esaminando il suo file di configurazione /etc/systemd/resolved.conf . Senza uno spedizioniere specificato qui, non c'è modo di risolvere nulla con successo.

PROVA:

Ho provato a sovrascrivere il risolutore di stub 127.0.0.53 specificando direttamente 168.63.129.16. Questo non è riuscito:

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

No:vedo ;; SERVER: 127.0.0.53#53(127.0.0.53) nell'output ci dice che non l'abbiamo sovrascritto e che il risolutore di stub locale non configurato è ancora in uso.

Tuttavia, l'utilizzo di uno dei seguenti comandi sovrascrive il 127.0.0.53 predefinito stub resolver e quindi è riuscito a restituire NOERROR risultati:

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

o

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

Quindi tutte le query che si basavano sull'utilizzo del systemd-resolved stub resolver erano condannati fino a quando non è stato configurato.

SOLUZIONE:

La mia iniziale- errata - la convinzione era che TCP/53 veniva bloccato:l'intero "troncato 512 " era un po' una falsa pista. Lo stub resolver non era configurato. Ho fatto il presupposto - lo so, lo so, "MAI ASSUMERLO;-) - che il DNS fosse configurato diversamente.

Come configurare systemd-resolved :

Ubuntu 18.04

Modifica il hosts direttiva in /etc/nsswitch.conf come sotto anteponendo resolve per impostare systemd-resolved come prima fonte di risoluzione DNS:

hosts:          resolve files dns

Modifica il DNS direttiva (almeno) in /etc/systemd/resolved.conf per specificare il forwarder desiderato, che in questo esempio sarebbe:

[Resolve]
DNS=168.63.129.16

Riavvia systemd-resolved :

sudo systemctl restart systemd-resolved

REL 8:

Red Hat fa quasi tutto per te per quanto riguarda l'impostazione di systemd-resolved come risolutore di stub, tranne che non hanno detto al sistema di usarlo!

Modifica il hosts direttiva in /etc/nsswitch.conf come di seguito anteponendo resolve per impostare systemd-resolved come prima fonte di risoluzione DNS:

hosts:          resolve files dns

Quindi riavvia systemd-resolved :

sudo systemctl restart systemd-resolved

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

CONCLUSIONE:

Una volta systemd-resolved è stato configurato il DNS della mia VM di prova si è comportato nel modo previsto. Penso che questo lo faccia...