Perché il sistema risolto non utilizza il mio server DNS locale?

Sto usando un server BIND9 locale per ospitare alcuni record DNS locali. Quando provo a cercare un nome di dominio locale non riesco a trovarlo se non dico esplicitamente a dig di utilizzare il mio server BIND9 locale.

user@heimdal:~$ dig +short heimdal.lan.se
user@heimdal:~$ dig +short @192.168.1.7 heimdal.lan.se
192.168.1.2

Vengono utilizzati Ubuntu 17.04 e systemd-resolved. Questo è il contenuto del mio / etc / risolto

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

E l'output di systemd-resolve --status

Global
         DNS Servers: 192.168.1.7
                      192.168.1.1
          DNSSEC NTA: 10.in-addr.arpa
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp
                      d.f.ip6.arpa
                      home
                      internal
                      intranet
                      lan
                      local
                      private
                      test

La sezione Server DNS sembra aver correttamente configurato 192.168.1.7 come server DNS principale (la mia istanza BIND9 locale). Non riesco a capire perché non sia usato ...?

Quindi, cambiando la mia interfaccia cablata eth0 per essere gestito ho risolto questo problema per me.

Modifica ifupdown su managed = true in /etc/NetworkManager/NetworkManager.conf

[ifupdown]
managed=true

Quindi riavviare NetworkManager

sudo systemctl restart NetworkManager

Dopodiché funziona perfettamente ..

Questo non era al 100%. Ho anche applicato queste modifiche per cercare di uccidere il risolutore

sudo service resolvconf disable-updates
sudo update-rc.d resolvconf disable
sudo service resolvconf stop

Un grande ringraziamento a questo post sul blog sull'argomento: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/

Preghiamo che funzioni ... Tutta questa faccenda della risoluzione dei sistemi è così brutta.

Suppongo che il tuo systemd-resolvedservizio sia configurato correttamente, ma non riesca mai a vedere la richiesta. Il .localdominio è trattato appositamente dai sistemi che eseguono mDNS . avahi-daemon, che fornisce servizi mDNS / DNS-SD (alias "Bonjour" sui prodotti Apple) può essere configurato per avere la precedenza sul DNS durante la risoluzione dei nomi; sembra che Ubuntu lo faccia.

Ci sono alcune opzioni tra cui puoi scegliere:

1. Rinomina il tuo .localdominio in qualcosa di diverso (possibilmente .internalo .lan). Questo potrebbe essere il modo più semplice da fare in pratica perché devi solo cambiare un paio di cose sul tuo server DNS e funziona meglio con Avahi. Consiglierei questo metodo.

2. Modifica il tuo /etc/nsswitch.conffile mettendo la dnsvoce davanti alle mdnsvoci.

3. Modifica la configurazione di Avahi per cambiare il dominio mDNS da .localqualcos'altro modificando /etc/avahi/avahi-daemon.confe cambiando (o aggiungendo) domain-name=.something(situato nella [server]sezione). Dovrai farlo su ogni computer che utilizza mDNS in modo che funzionino ancora insieme.

Sembra che sarebbe meglio come commento, ma non abbastanza reputazione ....

L'autosufficienza di Civing era in linea con ciò che volevo.

Ho anche dovuto aggiungere dns=nonealla [main]sezione di /etc/NetworkManager/NetworkManager.conf, quindi sembra che questo:

[main]
plugins=ifupdown,keyfile
dns=none

Ho appena aggiornato a xubuntu 18.04, dal 14.04, e ho una LAN più vecchia di così, con molti piccoli aggiustamenti accumulati nel corso degli anni. Quindi voglio che il mio DNS faccia quello che voglio (sì, ho acquistato molte copie del libro di Cricket Lius nel corso degli anni, a partire dalla seconda edizione).

Per inciso, in precedenza avevo aggiunto le informazioni di risoluzione DNS che voglio vedere nel file /etc/resolvconf/resolv.conf.d/head.

In breve, una volta ho avuto un /etc/resolv.conf funzionante, come root:

cat /etc/resolv.conf >> /etc/resolvconf/resolv.conf.d/head

Ma ora, modifico direttamente /etc/resolv.conf e rimane attivo. I visitatori della mia LAN, che utilizzano systemd / resolvconf, sono SOOL. Non esistono.

La lettura ha man 8 resolvconfaiutato. Un sacco. Ho fatto non seguire le istruzioni per mettere le cose in cui il programma ifup poteva trovare. Soprattutto perché nella GUI c'è un'intera sovrastruttura che era già stata ignorata da tutto ciò che è stato fatto durante l'aggiornamento. Questo sembra essere un problema più grande (WTF, Ubuntu?).

Quindi questo è fugace, e c'è ancora il problema che ciò che avevo (molto tempo fa) inserito nella GUI del pannello di controllo della rete non era stato obbedito dal sistema appena aggiornato, ma questa è una domanda completamente diversa, una volta che ho capito come Chiedilo.

Per me, eseguendo un 18.04 installato di recente, ho apportato la prima modifica citata da @Civing:

[ifupdown]
managed=true

quindi, notando che /etc/resolv.conf puntava sempre stub-resolv.conf e che veniva generato un resolv.conf ragionevole con il server DNS LAN appropriato, cambiava il link simbolico:

/etc/resolv.conf -> /run/systemd/resolve/resolv.conf

e quindi tutti i nomi host locali risolti tramite ping.

Resta da vedere per quanto tempo continuerà a funzionare.

Quando ho installato inizialmente, l'installazione della rete wireless non è riuscita e non posso fare a meno di chiedermi se l'installazione abbia lasciato /etc/resolv.conf in questo stato iniziale.

Quindi, un suggerimento è quello di guardare a ciò che sta risolvendo; potresti avere già una base di lavoro.