DNS на 127.0.0.53 systemd игнорирует некоторые запросы.

Система DNS systemd, расположенная по адресу 127.0.0.53, кажется, работает, за исключением случаев, когда я запрашиваю локальные машины по имени. Но если я запрашиваю их и специально указываю локальный DNS-сервер (мой маршрутизатор), то получаю правильный ответ. Однако в конфигурационном файле указано, что он также использует маршрутизатор в качестве адреса поиска. Есть мысли?

Я использую Ubuntu 18.04 на своем ноутбуке Dell.

Неправильные результаты:

$ nslookup web1

Сервер:     127.0.0.53
Адрес:      127.0.0.53#53

** сервер не может найти web1: SERVFAIL

Также неудачно

$ nslookup -i wlp3s0 web1
nslookup: не удалось получить адрес для 'web1': не найдено

Правильные результаты:

$ nslookup web1 192.168.1.1

Сервер:     192.168.1.1
Адрес:      192.168.1.1#53

Имя:   web1
Адрес: 192.168.1.107

Информация о конфигурации systemd-resolve

$ systemd-resolve --status

Глобальные
          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

Ссылка 3 (wlp3s0)
      Текущие области: DNS
       Установка LLMNR: да
Установка MulticastDNS: нет
      Установка DNSSEC: нет
    Поддержка DNSSEC: нет
         DNS-серверы: 192.168.1.1
          DNS-домен: wp.comcast.net

Ссылка 2 (enp2s0)
      Текущие области: нет
       Установка LLMNR: да
Установка MulticastDNS: нет
      Установка DNSSEC: нет
    Поддержка DNSSEC: нет

Информация о конфигурации 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 на маршрутизаторе возвращает правильный ответ, но локальный кэш, похоже, никогда не пытается искать адрес.

Я нашел решение, которое сработало для меня.

Мой файл 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 unlink /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

Сервер:     192.168.1.1
Адрес:      192.168.1.1#53

Имя:   web1
Адрес: 192.168.1.107

$ nslookup google.com

Сервер:     192.168.1.1
Адрес:      192.168.1.1#53

Неавторитетный ответ:
Имя:   google.com
Адрес: 172.217.7.174
Имя:   google.com
Адрес: 2607:f8b0:4004:80e::200e

Ваш файл resolv.conf не указывал на неправильное место — ../run/systemd/resolve/stub-resolv.conf является тем местом, на которое он должен указывать по умолчанию.

Проблема в том, что systemd-resolved не передает имена без точки на DNS. Очевидно, это работает “как задумано”. См. эту проблему на github, в которой говорится, что “resolved никогда не позволит запросам односложных имен утечь в униicast DNS”.

Согласны вы или нет с аргументацией в этой проблеме на github, существует способ это исправить. Это даже не требует изменений в стандартной настройке на вашем компьютере с Ubuntu:

1. Во-первых, DNS вашего локального сегмента сети должен иметь доменное имя.

   Если вы используете dnsmasq, добавьте следующее в /etc/dnsmasq.conf на вашем DNS-сервере:

   expand-hosts
   domain=your-domain # замените "your-domain" на домен по вашему выбору
   

   Теперь вы должны иметь возможность разрешать имена хостов локального сегмента сети, если добавите домен:

   nslookup web1.your-domain
   

2. Во-вторых, убедитесь, что имя для домена вашего локального сегмента сети также установлено на вашем 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
Сервер:         127.0.0.53
Адрес:          127.0.0.53#53

Неавторитетный ответ:
Имя:   web1.your-domain
Адрес: 192.168.1.107

Обратите внимание, что если вы используете dig вместо nslookup, dig по умолчанию не использует путь поиска — используйте его опцию +search для активации этой функции.

Иногда удаление символьной ссылки по адресу /etc/resolv.conf является правильным решением.

Недавно я мигрировал наш авторитетный DNS-сервер на новосозданный хост, который (в отличие от предыдущего) имел установленный systemd.

Результаты были ужасными.

Хотя остальной мир видел правильные результаты, резолвер systemd возвращал устаревшие данные местным сервисам, и это нарушало работу других сервисов, в частности внутреннего почтового пересылки.

dig @127.0.0.53 показывал, что он время от времени увеличивает TTL, так что его кэш никогда не истекал; я подозреваю, что он фактически запрашивал себя, так как NS указывает на этот хост.

Запуск systemd-resolve --flush-caches ничего не дал.

Редактирование /etc/systemd/resolved.conf и установка DNSStubListener=no в конечном итоге остановило работу резолвера, хотя, кажется, он появляется на несколько секунд время от времени.

По крайней мере, теперь традиционные сервисы действительно получали правильные ответы, но те, которые были созданы для выполнения запросов имен через DBUS, безнадежно сломаны.

Теперь я понимаю, почему так много людей ненавидели systemd; он вмешивается в другие подсистемы, к которым у него нет причин прикасаться, и нет эффективного способа остановить его от этого. Даже NIS не был сломан так сильно; почему systemd нужно было это изменить и сделать хуже?

Лучший вариант — переустановить ваш systemd

sudo apt-get install -y systemd

Недавно я столкнулся с проблемой: у меня не работал интернет из-за некоторого
❌ lookup api.github.com на [::1]:53: read udp [::1]:58911->[::1]:53: read: connection refused

После переустановки systemd все заработало нормально.