16.10 impossibile risolvere il DNS

Dopo aver aggiornato la mia installazione 16.04 a 16.10, ho problemi con DNS.

Innanzitutto ho avuto problemi un paio di volte quando sono collegato al WiFi, mentre ha funzionato su Ethernet. Ora sembra funzionare anche su WiFi. Non sono sicuro del perché e se sia in qualche modo correlato al problema che devo affrontare ora:

Quando ci si connette a un host VPN con Cisco Anyconnect VPN , aggiunge una riga in "/etc/resolv.conf" . Capisco che Ubuntu ora sta usando systemd-resolver e la pagina man dice che ci sono tre diverse modalità per gestire /etc/resolv.conf. Il mio /etc/resolv.conf non è un collegamento simbolico e non elenca 127.0.0.53 come un server DNS, quindi per quanto ho capito systemd risolto dovrebbe "leggerlo per i dati di configurazione DNS". Tuttavia, non sembra interessarsene.

scavare

La cosa strana (per me) è che dig host.customer.tld, restituisce una bella risposta con una SEZIONE RISPOSTA che mostra l'ip dell'host richiesto e si riferisce al server DNS aggiunto a /etc/resolv.conf dal client vpn come SERVER. Quando la connessione VPN è disabilitata non ricevo risposta. Vale a dire scavare legge /etc/resolv.conf .

ping

Il browser, dall'altro lato, non arriva a /etc/resolv.conf e non è in grado di risolvere il nome host. Neanche ping / curl, comunque.

nmcli

Ho trovato un post correlato e ho provato a correre

nmcli device show <interfacename> | grep IP4.DNS

ma non elenca nessun DNS per il dispositivo cscotun0. (Non lo è nemmeno nel 16.04.) Inoltre, nmcli elenca il mio server dhcp (il mio router) come host IP4.DNS per le mie connessioni eth / wlan. L'uso dig @192.168.0.1 xxxper qualsiasi dominio pubblico funziona bene.

configurazione

Ci sono alcuni altri server DNS elencati nel mio /run/systemd/resolve/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 2001:4860:4860::8888
# Too many DNS servers configured, the following entries may be ignored.
nameserver 2001:4860:4860::8844

Questi non sono serviti dal mio server DHCP. il file /etc/systemd/resolved.conf contiene solo righe commentate, ad eccezione dell'intestazione di sezione:

[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844

Lo dice la pagina man di resolved.conf

DNS = Un elenco separato da spazi di indirizzi IPv4 e IPv6 da utilizzare come server DNS di sistema. ... Per motivi di compatibilità, se questa impostazione non viene specificata, vengono utilizzati i server DNS elencati in /etc/resolv.conf, se quel file esiste e tutti i server sono configurati in esso. L'impostazione predefinita è l'elenco vuoto.

FallbackDNS = Un elenco separato da spazi di indirizzi IPv4 e IPv6 da utilizzare come server DNS di fallback. Qualsiasi server DNS per collegamento ottenuto da systemd-networkd.service (8) ha la precedenza su questa impostazione, così come tutti i server impostati tramite DNS = above o /etc/resolv.conf. Questa impostazione viene quindi utilizzata solo se non sono note altre informazioni sul server DNS. Se questa opzione non viene fornita, viene invece utilizzato un elenco compilato di server DNS.

Sembra che il fallback finisca in /run/systemd/resolve/resolv.conf nel mio caso.

EDIT: Non ero sicuro di quale fosse il problema, e ad essere sincero, non so ancora esattamente come funzioni, ma almeno si è scoperto che la soluzione nel mio caso era disabilitare il systemd-resolvedservizio. Ho pensato che fosse richiesto il servizio, che fosse il componente che forniva il servizio DNS a tutte le applicazioni locali, ma apparentemente c'è qualcos'altro lì dentro che fa quel lavoro.

Ho riscontrato problemi simili, ad esempio con l'aggiunta di un dongle USB USB aggiuntivo. Per prima cosa ho disabilitato dnsmasq nel gestore delle reti come descritto sopra e ho interrotto dnsmasq (servizio dnsmasq stop)

Ho notato che durante la risoluzione si è interrotto durante la connessione VPN, la tabella di routing sembra leggermente diversa (output del comando route). Il nome del gateway è DD-WRT nel caso in cui non funzioni e semplicemente "gateway" quando funziona. L'output di questo non è cambiato:

nmcli device show wlp1s0 | grep IP4.DNS

Continuava a mostrare il mio IP router. Una soluzione alternativa per farlo funzionare per un po 'è riavviare systemd-resolvd:

sudo service systemd-resolved restart

Poiché dnsmasq non è compreso nell'equazione, è la causa del problema o systemd-resolvd o qualsiasi cosa cambi la tabella di routing.

Quindi questa è l'unica differenza che vedo:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    601    0        0 

che funziona. E questo quando NON funziona:

ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         DD-WRT          0.0.0.0         UG    601    0        0 wlp1s0

E la stessa differenza di nome sulla linea VPN:

vpn-dns.name gateway         255.255.255.255 UGH   0      0        0 wlp1s0

Chi sa cosa può influenzare la tabella di routing? Sarebbe bello se riuscissimo a identificarlo in modo da poter presentare una segnalazione di bug. Mi sto davvero ammalando e stanco di perseguire tutti questi bug, ma vorrei risolverli in modo che i futuri utenti e noi saremo felici :).

[aggiornamento] Sembra che l'arresto di systemd-risolto possa risolvere questo problema e non influire negativamente su altre cose. Puoi provarlo e fargli sapere se si rompe roba. Ho visto quando eseguiva systemd-resolvd in debug quando si è rotto:

Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *

Disabilitare:

sudo systemctl disable systemd-resolved.service

Ho aggiornato il rapporto Ubuntu con suggerimenti. [/ update] Aggiungi: Nota: la segnalazione di bug: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317 ha una patch per 17.04 per alcuni problemi. Controlla la segnalazione dei bug e, se possibile, verifica la patch. Grazie!

[aggiornare]

Si prega di controllare la segnalazione di bug sopra menzionata, il problema sembra risolto per 17.10 e con un semplice comando è possibile disabilitare anche la perdita DNS.

[/aggiornare]

Il comportamento DNS durante la connessione OpenVPN è migliorato immediatamente quando ho seguito un suggerimento su ubuntuforums:

1. Apri /etc/NetworkManager/NetworkManager.confin un editor con diritti di root.
2. Elimina (o commenta con un hash #) la riga che leggedns=dnsmasq
3. Riavviare NetworkManager tramite sudo service NetworkManager restart

Ho affrontato lo stesso problema. In qualche modo devo aver installato DNSmasq con qualche applicazione. La semplice rimozione di dnsmasq ha risolto il problema per me.

sudo apt-get remove dnsmasq 

Da allora, non più disconnessioni o alcuni siti non sono più in grado di caricare (ho avuto un problema con il caricamento di Gmail, ovvero all'improvviso non è stato possibile connettersi a Gmail, anche se altri siti hanno funzionato).

Modifica /etc/nsswitch.confe cambia

hosts:          files mdns4_minimal [NOTFOUND=return] dns

a

hosts:          files dns mdns4_minimal [NOTFOUND=return]

Modificare:

Ho avuto gli stessi problemi per un bel po 'di tempo. Sono stato in grado di risolvere i nomi di dominio da VPN ma non sono stato in grado di eseguire il ping o arricciarli o utilizzarli in altre applicazioni. Il cambiamento descritto sopra lo ha risolto per me.