Eu tenho um servidor conectado à minha LAN e à Internet que não consigo conectar usando seu FQDN. Digamos que o FQDN seja server.com .
Por alguma razão, não consegui chegar ao fim, a resolução de server.com na minha máquina de desenvolvimento (localmente na LAN) sempre resulta em ::1 .
Aqui está o resultado da execução de host -v server.com :
Trying "server.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39898
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;server.com. IN A
;; ANSWER SECTION:
server.com. 6826 IN A 192.168.0.2
Received 47 bytes from 127.0.0.53#53 in 0 ms
Trying "server.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16204
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;server.com. IN AAAA
;; ANSWER SECTION:
server.com. 6826 IN AAAA ::1
Received 59 bytes from 127.0.0.53#53 in 0 ms
Trying "server.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48845
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;server.com. IN MX
Received 31 bytes from 127.0.0.53#53 in 0 ms
Observe a resposta para a segunda pergunta acima.
systemd-resolve realmente produz a resposta correta:
$ systemd-resolve server.com
server.com: 192.168.0.2
-- Information acquired via protocol DNS in 3.3ms.
-- Data is authenticated: no
Eu tentei reiniciar systemd-resolved , bem como --flush-caches , mas sem sucesso.
/etc/resolv.conf contém o seguinte:
# 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 server.com
A resolução de DNS é a indicada (a resolução é atendida por server.com ):
$ nmcli device show enp0s31f6 | grep -n2 IP4.DNS
10-IP4.GATEWAY: 192.168.0.1
11-IP4.ROUTE [1]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
12: IP4.DNS [1]: 192.168.0.2
13-IP4.DOMAIN [1]: server.com
14-IP6.ADDRESS [1]: fe80 :: 9e5c: 8eff: fe86: f30b / 64
Por fim, systemd-resolve --status produz o seguinte:
Global
DNS Domain: server.com
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 2 (enp0s31f6)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 192.168.0.2
DNS Domain: server.com
Eu provavelmente deveria mencionar que os seguintes serviços estão ativos no servidor ( server.com ): DHCP, DNS (bind9, IIRC), SSH, HTTP (s); Ele atua como o resolvedor de DNS para todas as máquinas na LAN. Por fim, estou ciente que eu poderia simplesmente adicionar uma entrada em /etc/hosts e acabar com isso, mas eu realmente gostaria de entender o que está errado, pois pode ser um sintoma de algo mais sério com o.
Como posso diagnosticar o que está acontecendo?
Eu resolvi isso consultando os registros DNS do servidor, que produziram o seguinte:
$ host server.com
server.com has address 192.168.0.2
server.com has IPv6 address ::1
Inspecionar o conteúdo do arquivo de configuração db.server.com do bind9 revelou uma entrada IPv6 furtiva:
@ IN AAAA ::1
Desativando o acima e reiniciando bind9, resolveu-o.
Agradecimentos a Thomas Ward pelos comentários que me permitiram abordar isso de forma diferente e, eventualmente, corrigi-lo.