DNS в systemd 127.0.0.53 игнорирует некоторые поиски


14

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



У меня нет dns = dnsmasq в моем конфигурационном файле. Я обновляю свой вопрос, чтобы показать это.
Шворак

Какую версию Ubuntu вы используете и можете ли вы обновить свой пост с помощью конфигурации IP?

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

Не могли бы вы попробоватьnslookup -i wlp3s0 web1
cmak.fr

Ответы:


9

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

Проблема в том, что systemd-resolvedне пропускает не пунктирные имена в DNS. Видимо, это работает "как задумано". Посмотрите эту проблему github, которая гласит, что «решено, никогда не позволят поиски с одной меткой просочиться в одноадресный DNS».

Согласны ли вы или нет с доводами в этом вопросе GitHub, там есть способ это исправить. Это даже не требует внесения каких-либо изменений в настройки по умолчанию на вашем компьютере с Ubuntu:

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

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

    expand-hosts
    domain=your-domain # replace "your-domain" with domain of your choice
    

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

    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
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опцию, чтобы включить это.


Перед перезагрузкой посмотрел web1.mydomain.com просто отлично. Но, конечно, поиск только web1 не сработал. Итак, я перезагрузился, и на всю жизнь я понятия не имею, где он забирает домен Comcast, но теперь, если я смотрю web1, он отвечает с правильным IP, но показывает домен comcast вместо моего домена. Это решает, так что я не слишком беспокоюсь, но какого черта ????
Шворак

@schworak Странно! Является ли ваш DHCP-сервер также модемом Comcast? Вы видите , что домен появляется в /etc/resolv.confили на выходе либо nmcli -g allили systemd-resolve --status? Может быть, попробуйте посмотреть, что находится в вашей аренде DHCP ?
Лоуренс Гонсалвес

Это не Comcast модем. У меня есть маршрутизатор SysLink с запущенным DDWRT. Настройки comcast полностью заменены. Имя comcast отображается в файле resolv.conf, который создается автоматически при загрузке. Я не слишком беспокоюсь об этом, но это странно.
Шворак

@LaurenceGonsalves Большое спасибо за ссылку на выпуск github. Я нашел обходные пути к проблеме, но на самом деле это помогло мне разобраться в коренной проблеме.
Григорий

19

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

мой файл 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

Пожалуйста, сообщите об этой ошибке, используя ubuntu-bug resolvconf.
Чай Т. Рекс

Когда я начинаю отправлять, он говорит resolvconf (не установлен). Resolvconf и systemd-resolv одно и то же?
Шворак

systemd-resolveпредоставляется systemdпакетом , поэтому, пожалуйста, попробуйте ubuntu-bug systemdвместо этого.
Чай Т. Рекс

Благодарность! Я никогда не использовал эту функцию сообщения об ошибках раньше. Очень хорошо.
Schworak

1
Вау, это безумие Спасибо. Исправлена ​​ли эта ошибка? Это специфичная для Docker ошибка? Я думаю, что resolv.confнастроен этот путь для DNS-сервера Docker Bridge, верно?
void.pointer
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.