Wyszukiwanie dns domeny Ubuntu 18.04 .local nie działa

Używam Raspberry Pi 3 z Ubuntu 18.04. W mojej firmie mamy serwer DNS i kilka domen z „.local”. Wiem technicznie, że to nie jest poprawne i zamiast tego powinno być „.lan”, ponieważ .local jest zarezerwowany dla dns multiemisji. Ale tak już jest i nie można tego łatwo zmienić. Więc na moim komputerze z systemem Windows mogę bez problemu pingować i przeglądać te nazwy domen. Jednak na moim Ubuntu nie mogę.

Nie mogę używać adresów IP, ponieważ niektóre domeny znajdują się na tym samym komputerze, a serwer IIS porządkuje, co się dzieje.

Szukałem i pojawia się dość często:

• https://smallbusiness.chron.com/resolving-local-ubuntu-38861.html
• Dlaczego żaden z moich lokalnych serwerów nie jest rozpoznawany?
• Serwer Ubuntu nie rozpoznaje nazw hostów LAN

Jednak zmiana pliku /etc/nsswitch.conf nie rozwiązuje problemu. próbowałem

• hosts: pliki mdns4_minimal [NOTFOUND = return] dns nazwa_hosta # domyślna
• hosts: pliki dns
• hosts: pliki mdns4_minimal [NOTFOUND = kontynuuj] dns moja_nazwa_hosta
• hosts: pliki mdns4 [NOTFOUND = return] dns nazwa_hosta
• hosts: pliki mdns4 [NOTFOUND = kontynuuj] dns moja_nazwa_hosta
• hosts: pliki dns mdsn4_minimal mojahostname
• gospodarze: dns
• kilka innych

Żaden z nich nie działał. Próbowałem zrestartować się również po zmianie. Próbowałem powiedzieć avahi, że nazwa domeny = alocal w /etc/avahi/avahi-daemon.conf, nie działa po ponownym uruchomieniu usługi, nie działa po ponownym uruchomieniu. Po tym nie działałem, próbowałem całkowicie wyłączyć usługę demona avahi.

sudo systemctl disable avahi-daemon

Po ponownym uruchomieniu ponownie spróbowałem kilku permutacji w /etc/nsswitch.conf, bez żadnego efektu.

przy moich bieżących ustawieniach na hostach (pliki dns) otrzymuję tę odpowiedź:

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

Jednak gdy polecam wykopowi, aby bezpośrednio zapytał serwer, otrzymuję poprawną odpowiedź:

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

Ta wersja Ubuntu wykorzystuje netplan z menedżerem sieci. Prawidłowy adres IP DNS zdecydowanie znajduje się na liście. (w rzeczywistości jest to podstawowy DNS). Również dnsIp jest taki sam jak serverIP, ale nie powinno to stanowić problemu.

Pingowanie lub łączenie się przez przeglądarkę i takie nie działają oczywiście. Żaden nie używa zapytania dns.

Nie wiem, co robić. Z pewnością nie możemy zmienić nazwy domeny. Umieściłem nazwę serwera w / etc / hosts, ale to tylko tymczasowe rozwiązanie.

W Linux Mint 19 (Tara) napotkałem bardzo podobny problem (jeśli nie dokładnie taki sam). Udało mi się to rozwiązać, łącząc 3 różne informacje. Wydaje się, że wszystko to jest związane z ostatnimi zmianami w rozwiązaniu systemd.

Po pierwsze, tak, musiałem skonfigurować plik /etc/nsswitch.conf, tak jak zrobiłeś i oczekiwałbyś. Tak długo, jak dns pojawia się przed mdns, powinieneś być dobry. Skończyłem po prostu:

hosts:          files dns myhostname

ref: /unix//a/457172/271210

Przed aktualizacją do tej wersji Mint jest to jedyna rzecz, którą musiałem zrobić. Teraz skończyłem też na wprowadzaniu poniższych dwóch innych zmian, aby działało ...

Następnie skonfigurowałem domenę wyszukiwania, aby systemd rozwiązany działał tak, jak chciałem. Więc zmodyfikowałem plik /etc/systemd/resolved.conf , ustawienie Domeny w sekcji [rozwiązać] . W moim przypadku wyglądało to tak:

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

ref: /ubuntu//a/1031271/872881

Zmieniłem również konfigurację avahi na coś innego („mdns”, jeśli dobrze pamiętam, ale to nie ma znaczenia). Z mojego zrozumienia nie powinno być to jednak wymagane. Po prostu dodaję dla kompletności.

Ale nic z tego nie działało, dopóki nie zadzwoniłem:

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

ref: /ubuntu//a/938703/872881

Po wywołaniu tego wszystko zaczęło działać idealnie i zgodnie z oczekiwaniami!

Możliwe więc, że tak naprawdę nie musiałem zmieniać pliku /etc/systemd/resolved.conf , ale zachowałem tę zmianę, ponieważ ma ona sens i pozwala mi tylko wpisywać nazwę komputera, bez pełnej nazwy FQDN, aby rozpoznawanie DNS działało .

Przyjęta odpowiedź nie rozwiązała mojego problemu. Nie miało to nic wspólnego z avahi - nie miałem zainstalowanej usługi avahi. Mam ustawiony system, aby pobrać jego adres IP ORAZ ustawienia serwera dns z DHCP. Jednak DNS dostarczony przez dhcp nie był sprawdzany pod kątem zapytań przy użyciu .local

Prawdziwym problemem jest to, że Ubuntu 18.4 ma swój resolv.conf połączony symetrycznie z plikiem pośredniczącym, który wskazuje na localhost w celu rozpoznawania nazw. Rozpoznawanie nazw lokalnych hostów dns oznacza, że ​​system odmawia sprawdzenia dostarczonego serwera DNS pod kątem nazw lokalnych, uważając (niepoprawnie), że takie nazwy są nieprawidłowe. To jest domyślna konfiguracja pliku /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

zawartość pliku pośredniczącego jest (komentarze usunięte):

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

„prawdziwe” polecenie conf ma „prawidłowe” ustawienie dns (z 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

Aby system używał preferowanego programu rozpoznawania nazw DNS zamiast localhost, zmień dowiązanie symboliczne tak, aby wskazywało na /run/systemd/resolve/resolv.conf zamiast /run/systemd/resolve/stub-resolv.conf:

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

Natychmiast po tym zaczęła działać rozdzielczość .local. nie trzeba ponownie uruchamiać ani restartować żadnej usługi.

Dla mnie sposób na Ubuntu 18.04 to:

Edytuj avahi conf:

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

i zmień .local na .alocal:

[server]
domain-name=.alocal

następnie otwórz resolved.conf:

sudo vim /etc/systemd/resolved.conf

i odkomentuj i edytuj Domeny:

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

i wreszcie ponownie uruchom usługi:

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

Dla mnie zadziałało dodanie lokalnego DNS jako serwera nazw /etc/resolvconf/resolv.conf.d/head(jak opisano tutaj ).

1. Zainstaluj pakiet resolvconf.

   sudo apt install resolvconf
   

2. Edytuj /etc/resolvconf/resolv.conf.d/headi dodaj następujące elementy:

   nameserver 8.8.4.4  
   nameserver 8.8.8.8  
   

3. Uruchom ponownie usługę resolvconf.

   sudo service resolvconf restart
   

Poprawka powinna być trwała.

Moja sytuacja była podobna, ale nieco inna: używamy nazw serwerów jak myserverw Windows, ale to nie działało na Ubuntu 16.04 i musiałem użyć myserver.mycompany.local. Po uaktualnieniu do 18.04 otrzymałem następujące zachowanie:

$ 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
...

Po prostu musiał wymienić myserver.mycompany.localz myservermoich aplikacji.