Dlaczego systemd rozwiązany nie używa mojego lokalnego serwera DNS?

Korzystam z lokalnego serwera BIND9 do obsługi niektórych lokalnych rekordów dns. Podczas próby wykopania lokalnej nazwy domeny nie mogę jej znaleźć, jeśli nie powiem jednoznacznie, aby kopać w celu korzystania z mojego lokalnego serwera BIND9.

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

Używane są Ubuntu 17.04 i systemd-resolved. To jest treść mojego / etc / resolved

# 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

I dane wyjściowe z systemd-resolver --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

Wygląda na to, że sekcja Serwery DNS poprawnie skonfigurowała 192.168.1.7 jako główny serwer DNS (moja lokalna instancja BIND9). Nie rozumiem, dlaczego nie jest używany ...?

Tak więc zmiana mojego przewodowego interfejsu eth0 do zarządzania rozwiązała dla mnie ten problem.

Zmiana ifupdown na managed = true w /etc/NetworkManager/NetworkManager.conf

[ifupdown]
managed=true

Następnie uruchom ponownie NetworkManager

sudo systemctl restart NetworkManager

Po tym działa bezbłędnie ..

To nie było 100%. Zastosowałem również te zmiany, aby spróbować zabić resolvera

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

Ogromne podziękowania dla tego postu na blogu na ten temat: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/

Módlmy się, żeby to zadziałało. Cały ten biznes rozwiązany jest tak brzydki.

Domyślam się, że twoja systemd-resolvedusługa jest poprawnie skonfigurowana, ale nigdy nie zobaczy żądania. .localDomena jest traktowany specjalnie przez systemach mDNS . avahi-daemon, który zapewnia usługi mDNS / DNS-SD (alias „Bonjour” w produktach Apple), można skonfigurować tak, aby miały pierwszeństwo przed DNS podczas rozpoznawania nazw; wygląda na to, że Ubuntu to robi.

Istnieje kilka opcji do wyboru:

1. Zmień nazwę .localdomeny na inną (ewentualnie .internallub .lan). Może to być najłatwiejsze w praktyce, ponieważ wystarczy zmienić kilka rzeczy na serwerze DNS i działa najlepiej z Avahi. Poleciłbym tę metodę.

2. Zmień /etc/nsswitch.confplik , umieszczając dnswpis przed mdnswpisami.

3. Zmień konfigurację Avahi, aby zmienić domenę mDNS .localna inną, edytując /etc/avahi/avahi-daemon.confi zmieniając (lub dodając) domain-name=.something(znajdujące się w [server]sekcji). Musisz to zrobić na każdym komputerze, który korzysta z mDNS, aby nadal współpracowały.

Wydaje się, że byłoby to lepsze jako komentarz, ale niewystarczająca reputacja ....

Odpowiedź Civinga była najbardziej zbliżona do tego, czego chciałem.

Musiałem również dodać dns=nonedo [main]sekcji /etc/NetworkManager/NetworkManager.conf, więc wygląda to tak:

[main]
plugins=ifupdown,keyfile
dns=none

Właśnie zaktualizowałem Xubuntu 18.04 od 14.04 i mam starszą sieć LAN, z wieloma drobnymi poprawkami naliczanymi przez lata. Dlatego chcę, aby mój DNS robił to, co chcę (tak, kupiłem wiele kopii książki Cricket Lius na przestrzeni lat, począwszy od drugiej edycji).

Na marginesie, wcześniej dodałem do pliku informacje dotyczące rozstrzygania DNS, które chcę zobaczyć /etc/resolvconf/resolv.conf.d/head.

Krótko mówiąc, kiedy miałem już działający plik /etc/resolv.conf jako root:

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

Ale teraz po prostu edytuję /etc/resolv.conf bezpośrednio i pozostaje on na swoim miejscu. Odwiedzający moją sieć LAN, którzy używają systemd / resolvconf, są SOOL. Oni nie istnieją.

Czytanie man 8 resolvconfpomogło. Dużo. I nie nie postępuj zgodnie z instrukcjami na oddanie rzeczy gdzie program ifup mógł ich znaleźć. Głównie dlatego, że w GUI znajduje się cała nadbudowa, która była już ignorowana przez to, co zrobiono podczas aktualizacji. To wydaje się być większym problemem (WTF, Ubuntu?).

Jest to więc dość kłopotliwe i nadal istnieje problem, że to, co (dawno temu) wprowadziłem do GUI panelu sterowania siecią, nie było przestrzegane przez nowo zaktualizowany system, ale to zupełnie inne pytanie, kiedy wymyślę, jak to zrobić Zapytaj to.

Dla mnie, w niedawno zainstalowanym 18.04, dokonałem pierwszej zmiany cytowanej przez @Civing:

[ifupdown]
managed=true

następnie zauważając, że /etc/resolv.conf zawsze wskazuje stub-resolv.conf i że generowany jest rozsądny resolv.conf z odpowiednim serwerem DNS DNS LAN, zmienił dowiązanie symboliczne:

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

a następnie lokalne wszystkie nazwy hostów rozwiązane przez ping.

Dopiero okaże się, jak długo to działa.

Podczas pierwszej instalacji konfiguracja sieci bezprzewodowej nie powiodła się i nie mogę przestać się zastanawiać, czy instalacja nie opuściła /etc/resolv.conf w tym stanie początkowym.

Jedną z sugestii jest przyjrzenie się temu, co rozwiązuje problem; możesz mieć już podstawy do pracy.