Ubuntu 18.04: поиск DNS для домена .local не работает.

Question 1

Я использую 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 # по умолчанию
hosts: files dns
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
hosts: dns
еще несколько других вариантов

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

sudo systemctl disable avahi-daemon

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

с моими текущими настройками в hosts (files dns) я получил ответ:

dig login.name.local # не настоящее имя

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> login.name.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local зарезервирован для Multicast DNS
;; Вы сейчас проверяете, что происходит, когда запрос mDNS утек в 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

;; Время запроса: 2 мсек
;; 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 сервер найден)
;; глобальные опции: +cmd
;; Got answer:
;; ПРЕДУПРЕЖДЕНИЕ: .local зарезервирован для Multicast DNS
;; Вы в данный момент проверяете, что происходит, когда запрос mDNS утек в DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57866
;; флаги: 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

;; Время запроса: 2 мсек
;; SERVER: dnsIP#53(dnsIP)
;; Время: Thu Aug 23 10:51:50 CEST 2018
;; Размер MSG получен: 56

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

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

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

Question 2

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

Настоящая проблема заключается в том, что Ubuntu 18.04 имеет resolv.conf символически связанным с заглушечным файлом, указывающим на localhost для разрешения имен. Разрешение имен DNS на localhost означает, что система отказывается проверять предоставленный 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
 .. удалены комментарии..
nameserver 127.0.0.53
    search reddog.microsoft.com

настоящий resolv.conf имеет корректные настройки DNS (из DHCP):

cat /run/systemd/resolve/resolv.conf

..удалены комментарии..
nameserver 10.168.200.250 # Это мой сервер, который может разрешать .local
nameserver 208.67.220.220 # это опциональные, резервные DNS-серверы
nameserver 208.67.222.222
# Слишком много настроено DNS серверов, следующие записи могут быть игнорированы.
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 начало работать. Нет необходимости перезагружать или перезапускать какие-либо службы.

Question 3

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

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

hosts:          files dns myhostname

ссылка: https://unix.stackexchange.com/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

ссылка: https://askubuntu.com/a/1031271/872881

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

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

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

ссылка: https://askubuntu.com/a/938703/872881

После этого все начало работать идеально и так, как ожидалось!

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

Question 4

Для меня рабочий способ на Ubuntu 18.04:

Отредактируйте конфигурацию avahi:

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

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

[server]
domain-name=.alocal

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

sudo vim /etc/systemd/resolved.conf

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

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

и, наконец, перезапустите службы:

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

Question 5

Это помогло мне на нескольких системах Ubuntu:

https://github.com/lathiat/nss-mdns#etcmdnsallow

Фактически добавьте две строки в /etc/mdns.allow:

.local.
.local

И, возможно, вам придется изменить /etc/nsswitch.conf, чтобы использовать модуль mdns4 вместо mdns4_minimal. Особенно это необходимо на сервере Ubuntu, но не на моем рабочем столе Kubuntu.

Question 6

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

Установите пакет resolvconf.
```
sudo apt install resolvconf
```
Отредактируйте /etc/resolvconf/resolv.conf.d/head и добавьте следующее:
```
nameserver 8.8.4.4  
nameserver 8.8.8.8  
```
Перезапустите сервис resolvconf.
```
sudo service resolvconf restart
```

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

Question 7

Для 20.04:

Я обновил настройки DNS для использования локального DNS-сервера (конфигурация ‘wired settings’ в Gnome)
Я добавил локальный домен в: /etc/systemd/resolved.conf & Domains=domain.local
Затем перезапустил сервис: service systemd-resolved restart

Спасибо этому форуму за помощь в решении проблемы.

Question 8

На Ubuntu Server 18.04/20.04 мы не могли разрешить имена хостов в нашем corpname.local домене, несмотря на то, что другие разрешения имен выполнялись через наш DNS-сервер AD. То, что помогло мне, это редактирование /etc/systemd/resolved.conf и добавление:

DNS=x.x.x.x
Domains=corpname.local

где x.x.x.x это IP нашего DNS-сервера AD. Затем выполните service systemd-resolved restart.

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

Question 9

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

$ ping myserver.mycompany.local
ping: myserver.mycompany.local: Имя или служба неизвестны

$ ping myserver
PING myserver.mycompany.local (192.168.x.y) 56(84) байтов данных.
64 байта от myserver.mycompany.local (192.168.x.y): icmp_seq=1 ttl=62 время=3.05 мс
...

Мне просто пришлось заменить myserver.mycompany.local на myserver в моих приложениях.

Question 10

Получив отличную информацию из нескольких других ответов я смог сделать все так, как хотел, чтобы работало на моем компьютере. Вот несколько вещей, которые я сделал…

#1: Исправить символьную ссылку на файл resolv.conf

Для этого мне нужно было сначала изменить права доступа к файлу с помощью…

sudo chattr -a -i /etc/resolv.conf

Затем я смог удалить существующий файл и перевыложить символьную ссылку, используя…

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

#2: Проверьте настройки DNS, чтобы убедиться, что серверы используются в нужном порядке

Чтобы проверить текущие настройки DNS, вы можете использовать…

resolvectl status

В моем случае я запутал настройки DNS, отредактировав файл /etc/systemd/resolved.conf. Из-за этого моя команда отображения настроек DNS показывала мне некоторые вещи в “Глобальных” настройках DNS, от которых я должен был избавиться…

user@server:/$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: foreign
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 8.8.8.8

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 8.8.8.8
        DNS Domain: 8.8.4.4

Чтобы исправить это, мне нужно было отредактировать файл resolved.conf и закомментировать все, что я пытался раскомментировать ранее, используя команду…

sudo nano /etc/systemd/resolved.conf

Вы можете видеть ниже, где я закомментировал такие вещи, как DNS и Domains…

[Resolve]
# Вот примеры DNS-серверов, которые можно использовать для DNS= и FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=8.8.8.8 8.8.4.4
#FallbackDNS=
#Domains=mydomain.local
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
#StaleRetentionSec=0

После этого я сделал перезагрузку sudo reboot, чтобы позволить глобальной информации DNS исчезнуть.

#3: Исправить информацию о DNS-сервере и домене в интерфейсе

Для этого мне нужно было отредактировать мою конфигурацию netplan, которая находится здесь…

cd /etc/netplan

Затем, находясь в этой директории, я мог выполнить команду ls -al, чтобы показать, как называется мой yaml конфигурационный файл. В моем случае он назывался 50-cloud-init.yaml, поэтому я использовал nano для его редактирования…

sudo /etc/netplan/nano 50-cloud-init.yaml

Затем я отредактировал файл, чтобы он выглядел так…

network:
    ethernets:
        eth0:
            addresses:
            - 192.168.2.22/24
            nameservers:
                addresses:
                - 192.168.1.3
                - 1.1.1.1
                - 8.8.8.8
                - 1.0.0.1
                - 8.8.4.4
                search:
                - mydomain.local
            routes:
            -   to: default
                via: 192.168.2.1

Существуют разные способы, более-менее структурированные, для записи адресов как по отдельности с ведущими дефисами, так и в виде массива, например любой из следующих форматов…

nameservers:
    addresses: [ 192.168.1.3]
    addresses: [ 1.1.1.1, 1.0.0.1 ]
    addresses: [8.8.8.8, 8.8.4.4]

Теперь проверка настроек DNS выглядит отлично…

user@server:/$ resolvectl status
Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: uplink

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
       DNS Servers: 192.168.1.3 1.1.1.1 8.8.8.8 1.0.0.1 8.8.4.4
        DNS Domain: mydomain.local

Теперь, пытаясь пинговать, я могу пинговать так…

user@server:~$ ping mypc.mydomain.local
PING mypc.mydomain.local (192.168.1.3) 56(84) bytes of data.
64 bytes from mypc.mydomain.local (192.168.1.3): icmp_seq=1 ttl=127 time=1.01 ms

или даже просто по имени…

user@server:~$ ping mypc
PING mypc.mydomain.local (192.168.1.3) 56(84) bytes of data.
64 bytes from mypc.mydomain.local (192.168.1.3): icmp_seq=1 ttl=127 time=1.01 ms

Ubuntu 18.04: поиск DNS для домена .local не работает.

Вопрос или проблема

Ответ или решение

Теория

Пример

Применение

Дополнительные настройки

Заключение