Ubuntu 18.04. Поиск домена DNS не работает


18

Я использую Raspberry Pi 3 с Ubuntu 18.04. В моей компании есть DNS-сервер и пара доменов с «.local». Я знаю, что технически это не правильно, и вместо этого это должен быть «.lan», потому что .local зарезервирован для многоадресных DNS. Но так оно и есть, и его нельзя легко изменить. Поэтому на моей машине с Windows я могу без проблем пинговать и просматривать эти доменные имена. На моем Ubuntu однако я не могу.

Я не могу использовать IP-адреса, потому что некоторые домены находятся на одной и той же машине, а веб-сервер IIS выясняет, что и куда идет.

Я искал, и это приходит довольно часто:

Однако изменение /etc/nsswitch.conf не поможет мне. Я старался

  • hosts: files mdns4_minimal [NOTFOUND = return] dns myhostname # default
  • хосты: файлы днс
  • hosts: files mdns4_minimal [NOTFOUND = continue] dns myhostname
  • hosts: files mdns4 [NOTFOUND = return] dns myhostname
  • hosts: files mdns4 [NOTFOUND = continue] dns myhostname
  • hosts: files dns mdsn4_minimal myhostname
  • хосты: днс
  • несколько других

Ни один из которых не работал. Я попытался перезагрузиться после изменения тоже. Я пытался сказать avahi, что имя домена = alocal в /etc/avahi/avahi-daemon.conf не работает после перезапуска службы, не работает после перезагрузки. После того, как это не сработало, я попытался полностью отключить службу avahi-daemon.

sudo systemctl disable avahi-daemon

После перезагрузки я снова попробовал несколько перестановок в /etc/nsswitch.conf, но безрезультатно.

с моими текущими настройками в hosts (файлы днс) я получаю такой ответ:

dig login.name.local # not the actual name

; <<>> Dig 9.11.3-1ubuntu1.1-Ubuntu <<>> login.name.local
;; global options: +cmd
;; Got answer:
;; WARNING .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33538
;; flags: qr rd ra; QUERY: 1, ANSWER:0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;login.name.local. 0     IN     A

;; Query time: 2msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Aug 23 10:51:50 CEST 2018
;; MSG SIZE  rcvd: 56

Однако, когда я даю команду dig для прямого запроса к серверу, я получаю правильный ответ:

dig @dnsIP login.name.local
; <<>> Dig 9.11.3-1ubuntu1.1-Ubuntu <<>> login.name.local
; (1 server found)
;; global options: +cmd
;; Got answer:
;; WARNING .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57866
;; flags: qr aa rd ra; QUERY: 1, ANSWER:1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;login.name.local. 0     IN     A

;; ANSWER SECTION:
login.name.local. 3600 IN    A        serverIP

;; Query time: 2msec
;; SERVER: dnsIP#53(dnsIP)
;; WHEN: Thu Aug 23 10:51:50 CEST 2018
;; MSG SIZE  rcvd: 56

Эта версия Ubuntu использует netplan с сетевым менеджером. Правильный DNS-IP определенно есть в списке. (на самом деле это основной DNS.) Также dnsIp такой же, как serverIP, но это не должно быть проблемой.

Пинг или подключение через браузер, и такие не работают, конечно. Никто не использует запрос DNS.

Я в недоумении, что делать. Конечно, мы не можем переключиться на другое доменное имя. Я поместил имя сервера в / etc / hosts, но это только временное решение.


изменение resolv.conf, как предлагал jeremfg, сработало для меня после нескольких часов погони за этим хвостом. Tnx.
— user3529828

Ответы:


14

Я столкнулся с очень похожей проблемой (если не точно такой же) в Linux Mint 19 (Tara). Мне удалось решить эту проблему, объединив 3 разных элемента информации. Кажется, все это связано с недавними изменениями в systemd-resolved.

Во-первых, да, мне нужно было настроить /etc/nsswitch.conf, как вы и ожидали. Пока днс приходит раньше, ты должен быть хорошим. Я закончил просто:

hosts:          files dns myhostname

ссылка: /unix//a/457172/271210

До перехода на эту версию Mint это единственное, что мне нужно было сделать. Теперь я также сделал два других изменения, чтобы заставить его работать ...


После этого я настроил свой поисковый домен так, чтобы systemd-resolved работал так, как я хотел. Поэтому я отредактировал файл /etc/systemd/resolved.conf , параметр Domains в разделе [resolve] . В моем случае это выглядело так:

[Resolve]
#DNS=
#FallbackDNS=
Domains=trilliant.local
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
#Cache=yes
#DNSStubListener=yes

ссылка: /ubuntu//a/1031271/872881

Я также изменил конфигурацию avahi на что-то другое («mdns», если я правильно помню, но это не имеет значения). Это не должно требоваться, однако, из моего понимания. Просто добавлю для полноты.


Но ничего из этого не работало, пока я не назвал следующее:

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

ссылка: /ubuntu//a/938703/872881

После звонка все стало работать отлично и как положено!

Поэтому, возможно, мне не нужно было менять файл /etc/systemd/resolved.conf, но я сохранил это изменение, поскольку оно имело смысл и позволяло мне вводить только имя машины без полного доменного имени, чтобы разрешение DNS работало ,


Вы могли бы просто поставить последнюю строку в начале, и я думаю, что вы получите больше голосов, сделав это.
— ХунбоЖу

@HongboZhu Я бы знал, что это единственное изменение, необходимое для работы локальных доменов. Я почти уверен, что вы все равно должны предпочесть dns, а не mdns в конфигурации распознавателя. Я полагаю, ваш комментарий относится к конфигурации домена в середине? Если так, да, я полагаю, я мог бы поставить это в конце как необязательное изменение. Но остальные две штуки требуются ИМХО.
— jeremfg

1
На моей новой установке 18.04.2, просто измените порядок "hosts" в nsswitch.conf уже работает.
— Томофуми

17

Принятый ответ не решил мою проблему. Это не имело ничего общего с avahi - у меня не был установлен сервис avahi. У меня есть система, настроенная на получение IP-адреса и параметров DNS-сервера от DHCP. Однако DNS, предоставленный dhcp, не проверялся на запросы с использованием .local

Реальная проблема заключается в том, что Ubuntu 18.4 имеет свой syv-файл resolv.conf, связанный с заглушкой, которая указывает на локальный хост для разрешения имен. Разрешение имен localhost dns означает, что система отказывается проверять предоставленный DNS-сервер на наличие имен .local, полагая (неправильно), что такие имена являются недействительными. Это настройка по умолчанию /etc/resolv.conf:

ls -la /etc/resolv.conf
lrwxrwxrwx 1 root root 39 Jan 22 13:26 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Содержимое заглушки (комментарии удалены):

 cat /run/systemd/resolve/stub-resolv.conf
 .. removed comments..  
nameserver 127.0.0.53
    search reddog.microsoft.com

«real» resol-conf имеет «правильную» настройку dns (из dhcp):

cat /run/systemd/resolve/resolv.conf

..removed comments..
nameserver 10.168.200.250 # This is my server that can resolve .local
nameserver 208.67.220.220 # these are optional, fallback dns servers
nameserver 208.67.222.222
# Too many DNS servers configured, the following entries may be ignored.
nameserver 8.8.8.8
search reddog.microsoft.com

Чтобы система использовала предпочитаемый DNS-преобразователь вместо localhost, вы должны изменить символическую ссылку, указав /run/systemd/resolve/resolv.conf вместо /run/systemd/resolve/stub-resolv.conf:

sudo rm -f /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Сразу после этого разрешение .local начало работать. нет необходимости перезагружать или перезапускать какой-либо сервис.


Я удалил Avahi и затем следовал твоим шагам. Это сделало это для меня. Спасибо, сэр. (Использование Ubuntu 18.04 Desktop).
— Хосе Л. Патиньо

Спасибо. Это был ответ для меня. Почему это не «просто работает» из коробки?
— Adampski

В чем разница между вашим решением и принятым ответом? Для обоих можно пропустить первые 2/3 ответа - даже это одно и то же :-)
— HongboZhu

Это единственный ответ, который я видел до сих пор, который повторяет поведение в предыдущих версиях Ubuntu (и других linux), то есть список DNS-серверов предоставляется DHCP, а разрешение адресов никогда не кэшируется локально.
— нарезанный

2

Для меня рабочий путь для Ubuntu 18.04 - это:

Редактировать avahi conf:

sudo vim /etc/avahi/avahi-daemon.conf

и измените .local на .alocal:

[server]
domain-name=.alocal

затем откройте resolved.conf:

sudo vim /etc/systemd/resolved.conf

и раскомментируйте и отредактируйте домены:

[Resolve]
...
Domains=yourdomain.local
...

и наконец перезапустите сервисы:

sudo service systemd-resolved restart
sudo service avahi-daemon restart

В моем случае я только нужно изменить Domainsв /etc/systemd/resolved.conf(и перезапустить службу).
— Токош

2
Это не сделало это для меня. все еще ничего
— FalcoGer

Та же версия Ubuntu. Использование openvpn. Это решение хорошо работает с VPN на многих машинах в моей команде.
— разваноне

2

Для меня работало добавление локального DNS в качестве сервера имен /etc/resolvconf/resolv.conf.d/head(как описано здесь ).

  1. Установите пакет resolvconf.

    sudo apt install resolvconf
    
  2. Отредактируйте /etc/resolvconf/resolv.conf.d/headи добавьте следующее:

    nameserver 8.8.4.4  
    nameserver 8.8.8.8  
    
  3. Перезапустите службу resolvconf.

    sudo service resolvconf restart
    

Исправление должно быть постоянным.


Заголовочный файл содержит предупреждение не редактировать файл, потому что он генерируется resolvconf?
— Джон Ми

@JohnMee headФайл является источником, используемым для генерации /run/resolvconf/resolv.conf. Однако я бы не стал редактировать и этот файл.
— Мелебиус

0

Моя ситуация была похожа, но несколько отличалась: мы используем имена серверов, как myserverв Windows, но это не работало в Ubuntu 16.04, и мне пришлось использовать myserver.mycompany.local. После обновления до 18.04 я получил следующее поведение:

$ ping myserver.mycompany.local
ping: myserver.mycompany.local: Name or service not known

$ ping myserver
PING myserver.mycompany.local (192.168.x.y) 56(84) bytes of data.
64 bytes from myserver.mycompany.local (192.168.x.y): icmp_seq=1 ttl=62 time=3.05 ms
...

Я просто должен был заменить myserver.mycompany.localс myserverв своих приложениях.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.