DNS в systemd 127.0.0.53 игнорирует некоторые поиски
DNS systemd с любовью на 127.0.0.53 работает, кроме случаев, когда я запрашиваю локальные машины по имени. Но если я запрашиваю их и специально указываю локальный DNS-сервер (мой маршрутизатор), я получаю правильный ответ. Но файл конфигурации говорит, что он также использует маршрутизатор в качестве адреса поиска. Какие-нибудь мысли?
Я использую Ubuntu 18.04 на своем ноутбуке Dell.
Неверные результаты:
$ nslookup web1
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find web1: SERVFAIL
Также терпит неудачу
$ nslookup -i wlp3s0 web1
nslookup: couldn't get address for 'web1': not found
Правильные результаты:
$ nslookup web1 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Name: web1
Address: 192.168.1.107
Информация о конфигурации
$ systemd-resolve --status
Global
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
Link 3 (wlp3s0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.1.1
DNS Domain: wp.comcast.net
Link 2 (enp2s0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Информация о конфигурации NetworkManager
$ cat /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=no
Так как же заставить nslookup вернуть правильный ответ? Ссылка 3 представляется правильной информацией (мое соединение Wi-Fi), и мой DNS на маршрутизаторе возвращает правильный ответ, но локальный кэш никогда не пытается найти адрес (или так кажется).
3 ответа
Ваш файл resolv.conf не указывал на неправильное место - ../run/systemd/resolve/stub-resolv.conf где он должен указывать по умолчанию.
Проблема в том, что systemd-resolved не передает без точек имена на DNS. Видимо, это работает "как задумано". Посмотрите эту проблему github, которая гласит, что "решено, никогда не будет разрешать поиск с одной меткой на одноадресный DNS".
Независимо от того, согласны ли вы с обоснованием этой проблемы GitHub, есть способ исправить это. Это даже не требует внесения каких-либо изменений в настройки по умолчанию на вашем компьютере с Ubuntu:
Во-первых, DNS вашей локальной сети должен иметь доменное имя.
Если вы используете dnsmasq, добавьте следующее в
/etc/dnsmasq.confна вашем DNS-сервере:expand-hosts domain=your-domain # replace "your-domain" with domain of your choiceТеперь вы сможете разрешить имена хостов в локальной сети, если добавите домен:
nslookup web1.your-domainВо-вторых, убедитесь, что имя домена вашей локальной сети также задано на вашем DHCP-сервере, если оно отличается от вашего DNS-сервера. На моем DHCP-сервере (мой маршрутизатор) этот параметр называется просто "Доменное имя".
Если вы затем продлите аренду DHCP на вашем Ubuntu, вы должны увидеть директиву поиска в
/run/systemd/resolve/stub-resolv.conf:nameserver 127.0.0.53 search your-domain
Сейчас смотрю web1 расширит его до web1.your-domain, который затем разрешит с помощью DNS.
$ nslookup web1
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: web1.your-domain
Address: 192.168.1.107
Обратите внимание, что если вы используете dig вместо nslookup, dig не использует путь поиска по умолчанию - используйте его +search возможность включить это.
Я нашел исправление, которое работало для меня.
мой файл resolv.conf указывал на неправильное место. Это похоже на ошибку в Ubuntu, поскольку это произошло на моем ноутбуке (на машине, на которой я впервые заметил эту проблему) и на новой установке Ubuntu 18.04 Server.
По умолчанию
$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Apr 26 12:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
Я удалил это и указал на правильный файл. После перезагрузки это решило мою проблему. И я даже мог переключать сети на своем ноутбуке, и DNS переключался правильно. Конечно, когда во внешних сетях я не могу разрешить ни одну из своих локальных машин, но это ожидается. Как только я переключаюсь обратно в свою локальную сеть, все локальные машины распознаются правильно, потому что мой маршрутизатор - это DNS.
Исправление
$ sudo rm -f /etc/resolv.conf
$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 32 May 29 08:48 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf
$ sudo reboot
После этого все заработало как я ожидал и 127.0.0.53 больше не используется вообще.
Правильные результаты
$ nslookup web1
Server: 192.168.1.1
Address: 192.168.1.1#53
Name: web1
Address: 192.168.1.107
$ nslookup google.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.217.7.174
Name: google.com
Address: 2607:f8b0:4004:80e::200e
Иногда удаление символической ссылки на
Недавно я перенес наш авторитетный DNS-сервер на недавно построенный хост, на котором (в отличие от предыдущего) был установлен systemd.
Результаты были ужасны.
Хотя остальной мир увидит правильные результаты, резолвер systemd будет передавать устаревшие результаты результатов локальным службам, что приведет к беспорядку в этих других службах, в частности, во внутренней пересылке почты.
Бег
Редактирование
По крайней мере, теперь традиционные сервисы на самом деле получат правильные ответы, но те, которые созданы для поиска имен по DBUS, безнадежно сломаны.
Теперь я понимаю, почему так много людей ненавидели systemd; он мешает другим подсистемам, к которым у него нет причин прикасаться, и нет эффективного способа помешать ему это сделать. Даже NIS не был так сильно сломан; почему systemd нужно было изменить его и сделать еще хуже?