Почему systemd-resolved не использует мой локальный DNS-сервер?

Я использую локальный сервер BIND9 для размещения некоторых локальных записей DNS. При попытке найти локальное доменное имя я не могу его найти, если явно не скажу dig использовать мой локальный сервер BIND9.

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

Ubuntu 17.04 и systemd-resolved используются. Это содержимое моего / 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

И вывод из systemd-разрешения --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

Раздел DNS-серверы, по-видимому, правильно настроил 192.168.1.7 в качестве основного DNS-сервера (мой локальный экземпляр BIND9). Я не могу понять, почему это не используется ...?

Таким образом, изменение моего проводного интерфейса eth0 для управления решило эту проблему для меня.

Изменение ifupdown на managed = true в /etc/NetworkManager/NetworkManager.conf

[ifupdown]
managed=true

Затем перезапустите NetworkManager

sudo systemctl restart NetworkManager

После этого все работает без нареканий ..

Это не было 100%. Я также применил эти изменения, чтобы попытаться убить распознаватель

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

Большое спасибо за этот пост в блоге на эту тему: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/

Давайте помолимся, это работает .. Весь этот системно-разрешающий бизнес просто ужасен.

Я предполагаю, что ваш systemd-resolvedсервис настроен правильно, но он никогда не увидит запрос. .localДомен специально обрабатываются с помощью систем , работающих под управлением MDNS . avahi-daemon, который предоставляет службы mDNS / DNS-SD (также называемые «Bonjour» в продуктах Apple), может быть настроен на приоритет над DNS во время разрешения имен; похоже, что Ubuntu делает это.

Есть несколько вариантов, которые вы можете выбрать:

1. Переименуйте свой .localдомен во что-то другое (возможно, .internalили .lan). Это может быть проще всего сделать на практике, потому что вам просто нужно изменить пару вещей на вашем DNS-сервере, и это лучше всего работает с Avahi. Я бы порекомендовал этот метод.

2. Измените ваш /etc/nsswitch.confфайл , поместив dnsзапись перед mdnsзаписями.

3. Измените конфигурацию Avahi, чтобы изменить домен mDNS с .localчего-либо другого путем редактирования /etc/avahi/avahi-daemon.confи изменения (или добавления) domain-name=.something(находится в [server]разделе). Это необходимо сделать на каждом компьютере, использующем mDNS, чтобы они по-прежнему работали вместе.

Кажется, это будет лучше в качестве комментария, но недостаточно репутации ....

Самоотдача Кейвинга соответствовала тому, что я хотел.

Я также должен был добавить dns=noneв [main]раздел /etc/NetworkManager/NetworkManager.conf, так что это выглядит так:

[main]
plugins=ifupdown,keyfile
dns=none

Я только что обновил xubuntu 18.04, начиная с 14.04, и у меня есть локальная сеть, которая старше этой, со многими небольшими изменениями, накопленными за эти годы. Поэтому я хочу, чтобы мой DNS делал то, что я хочу (да, я приобрел много копий книги Крикета Лиуса за эти годы, начиная со второго издания).

Кроме того, я ранее добавлял информацию разрешения DNS, которую я хочу видеть в файл /etc/resolvconf/resolv.conf.d/head.

В двух словах, когда-то у меня был рабочий /etc/resolv.conf от имени root:

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

Но сейчас я просто редактирую /etc/resolv.conf напрямую, и он остается на месте. Посетители моей локальной сети, которые используют systemd / resolvconf, являются SOOL. Их не существует.

Чтение man 8 resolvconfпомогло. Много. Я не следовал инструкциям по размещению вещей там, где их могла найти программа ifup. Главным образом потому, что в графическом интерфейсе есть целая надстройка, которая уже игнорировалась тем, что было сделано во время обновления. Это кажется более серьезной проблемой (WTF, Ubuntu?).

Так что это бесполезно, и есть еще проблема, что то, что я (давно) ввел в GUI панели управления сетью, не подчинялось недавно обновленной системе, но это совершенно другой вопрос, как только я выясню, как спроси это.

Для меня, запустив недавно установленную 18.04, я сделал первое изменение, упомянутое @Civing:

[ifupdown]
managed=true

затем, заметив, что /etc/resolv.conf всегда указывает stub-resolv.conf и что создается разумный resolv.conf с соответствующим DNS-сервером локальной сети, изменил символическую ссылку:

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

а затем локальные все имена хостов, разрешенные с помощью ping.

Еще неизвестно, как долго это продолжает работать.

Когда я первоначально установил, настройка беспроводной сети не удалась, и я не могу не задаться вопросом, оставила ли установка /etc/resolv.conf в этом начальном состоянии.

Итак, одно из предложений - посмотреть, что порождает решенное; у вас уже может быть рабочая база.