Por sugestão de Joseph Redfern, parece que resolvconf não joga bem com systemd-resolved . Remover o pacote resolvconf corrigiu o problema para mim.
Eu recentemente atualizei de 16.04 para 17.10, e alguns nomes de domínio agora não conseguem resolver em systemd-resolved , mesmo que o meu servidor DNS inicial resolva os nomes de domínio bem.
Meu domínio do local de trabalho é *.cs.bham.ac.uk (Ciência da Computação dentro de um uni) e esses domínios resolvem bem quando estou no trabalho. Mas quando eu vou para casa, esses domínios param de ser resolvidos. O lugar onde estou agora não tem relação com nada .bham.ac.uk .
bgeron@tinker ~> systemd-resolve git.cs.bham.ac.uk
git.cs.bham.ac.uk: resolve call failed: No appropriate name servers or networks for name found
bgeron@tinker ~> host git.cs.bham.ac.uk
Host git.cs.bham.ac.uk not found: 2(SERVFAIL)
bgeron@tinker ~> host git.cs.bham.ac.uk 192.168.1.254
Using domain server:
Name: 192.168.1.254
Address: 192.168.1.254#53
Aliases:
git.cs.bham.ac.uk has address 147.188.203.99
bgeron@tinker ~> systemd-resolve --status
Global
DNS Domain: lan
adf.bham.ac.uk
bham.ac.uk
cs.bham.ac.uk
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 4 (docker0)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Link 3 (wlp4s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.1.254
DNS Domain: lan
Link 2 (enp0s31f6)
Current Scopes: none
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
Não tenho ideia de por que esses domínios DNS estão listados lá. Parece um cache obsoleto de alguns tipos. A execução de systemd-resolve --flush-caches como root não parece ter impacto algum.
Conteúdo de /etc/resolv.conf :
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
search lan adf.bham.ac.uk bham.ac.uk cs.bham.ac.uk
Quando eu removo a linha search , as pesquisas funcionam novamente. Mas obviamente essa não é uma solução permanente.
Acredito que estou usando apenas o NetworkManager. Eu tenho um dispositivo Bluetooth PAN configurado, mas não ativado.
No passado, no uni havia um problema com nomes de hosts locais que não estavam resolvidos: Acredito que *.cs.bham.ac.uk resolveria (conforme determinado pelo host (1)), mas não *.bham.ac.uk . Não me lembro o que systemd-resolve diria para essas situações. Para consertar, eu coloquei o código /etc/nsswitch.conf e coloquei o seguinte conteúdo que encontrei on-line em algum lugar:
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the 'glibc-doc-reference' and 'info' packages installed, try:
# 'info libc "Name Service Switch"' for information about this file.
passwd: compat
group: compat
shadow: compat
hosts: dns [!UNAVAIL=return] files
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
Algumas entradas de log no meu diário que podem ou não estar relacionadas:
Mais:
Nov 05 22:39:59 tinker systemd[1]: Starting Network Name Resolution...
-- Subject: Unit systemd-resolved.service has begun start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- Unit systemd-resolved.service has begun starting up.
Nov 05 22:39:59 tinker systemd-resolved[11818]: Positive Trust Anchors:
Nov 05 22:39:59 tinker systemd-resolved[11818]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Nov 05 22:39:59 tinker systemd-resolved[11818]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Nov 05 22:39:59 tinker systemd-resolved[11818]: Negative trust anchors: 10.in-addr.arpa 16.172.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 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
Nov 05 22:39:59 tinker systemd-resolved[11818]: Using system hostname 'tinker'.
Nov 05 22:39:59 tinker systemd[1]: Started Network Name Resolution.
-- Subject: Unit systemd-resolved.service has finished start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- Unit systemd-resolved.service has finished starting up.
--
-- The start-up result is done.
Nov 05 22:50:52 tinker systemd-resolved[11818]: Flushed all caches.
Qualquer ideia seria muito bem vinda!
editar Esclarecimento: tentar resolver qualquer um desses nomes de host não resulta em nenhum tráfego de rede, ele imediatamente dá um resultado negativo.
Por sugestão de Joseph Redfern, parece que resolvconf não joga bem com systemd-resolved . Remover o pacote resolvconf corrigiu o problema para mim.
Tags systemd-resolved