![进一步阅读](https://linux22.com/image/173303/%E8%BF%9B%E4%B8%80%E6%AD%A5%E9%98%85%E8%AF%BB.png)
我想知道为什么平无法检索 ipv4dk
顶级域名在我的 Debian 10 上。有效域名,我所知道的地球上最短的域名服务器(有A
记录)。很好测试网络连接。
当我使用挖,一切都按预期运行:
dig A +short dk
193.163.102.58
但是当我使用平,dk
位于我拥有的域前面,并启用了通配符。比方说example.org
, 所以 :
ping -c1 dk
PING dk.example.org (x.x.x.x) 56(84) bytes of data.
64 bytes from x.x.x.x-reverse-dns (x.x.x.x): icmp_seq=1 ttl=57 time=3.72 ms
--- dk.example.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.716/3.716/3.716/0.000 ms
但如果我附加一个点,它就会起作用:
ping -c1 dk.
PING dk (193.163.102.58) 56(84) bytes of data.
64 bytes from static3.prod.dkhm.dk (193.163.102.58): icmp_seq=1 ttl=51 time=24.6 ms
--- dk ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.569/24.569/24.569/0.000 ms
通过DoT
/stubby
和通过一些公共静态 DNS 解析器进行了测试/etc/resolv.conf
(结果相同)。
我没有像unbound
nor这样的本地解析器bind
。
目录和 IP 地址example.org
中没有任何有趣的匹配。/etc
我的/etc/nsswitch.conf
如果配置不正确:
[...]
hosts: files mdns4_minimal [NOTFOUND=return] dns
networks: files
[...]
有人知道发生了什么事吗?
答案1
最短的域名是.
.这很重要,dk
因为不是完全合格的域名。它的人类可读形式不会以句号结束。以句号结尾表示(人类可读形式)完全限定的域名。
DNS 本身就完全合格的域名而言是有效的,您的 DNS 客户端库(链接到类似 的程序ping
)必须变成dk
,通过附加一个或多个后缀。您的 DNS 客户端正在附加您看到的后缀。对于大多数 C 库中包含的 BIND DNS 客户端库,后缀列表来自 中的指令/etc/resolv.conf
,回退到馈送到操作系统的动态域名后缀(以各种方式)。
dk.
相比之下是完全限定的域名,并且 DNS 客户端库不会通过名称限定传递它。
这里实际上没有什么问题。
进一步阅读
- 乔纳森·德博因·波拉德 (2017)。 ”完全限定名称的概念”。什么是 DNS 名称资格。经常给出的答案。
答案2
正在解析的dig A dk
是使用 R A 定义的域,该域可能是也可能不是 DNS 服务器;它没有被定义为询问域的权威服务器的方式。在 MX 时代之前,它曾被用来指向响应该域的电子邮件服务器的地址,该功能现在已被弃用。
要获取负责 TLD 的权威名称服务器的 IP 地址dk
,最好向根名称服务器询问 NS 记录。
$ dig -t NS dk @a.root-servers.net. | sed "s/^/ /"
; <<>> DiG 9.10.6 <<>> -t NS dk @a.root-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2109
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 15
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;dk. IN NS
;; AUTHORITY SECTION:
dk. 172800 IN NS a.nic.dk.
dk. 172800 IN NS b.nic.dk.
dk. 172800 IN NS c.nic.dk.
dk. 172800 IN NS d.nic.dk.
dk. 172800 IN NS l.nic.dk.
dk. 172800 IN NS p.nic.dk.
dk. 172800 IN NS s.nic.dk.
;; ADDITIONAL SECTION:
a.nic.dk. 172800 IN A 212.88.78.122
b.nic.dk. 172800 IN A 193.163.102.222
c.nic.dk. 172800 IN A 194.0.46.53
d.nic.dk. 172800 IN A 185.159.198.45
l.nic.dk. 172800 IN A 192.38.7.242
p.nic.dk. 172800 IN A 194.0.47.42
s.nic.dk. 172800 IN A 193.176.144.15
a.nic.dk. 172800 IN AAAA 2001:1580:0:180d::122
b.nic.dk. 172800 IN AAAA 2a01:630:0:80::53
c.nic.dk. 172800 IN AAAA 2001:678:74::53
d.nic.dk. 172800 IN AAAA 2620:10a:80ab::45
l.nic.dk. 172800 IN AAAA 2001:7f8:1f::1835:242:0
p.nic.dk. 172800 IN AAAA 2001:678:78:42:ad::53
s.nic.dk. 172800 IN AAAA 2a00:d78:0:102:193:176:144:15
;; Query time: 38 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Jun 01 08:26:00 WEST 2020
;; MSG SIZE rcvd: 455
dk
为了方便网络访问者,还可以看到资源记录指向该 A 记录中该域的 Web 服务器。在这种情况下,RR Adk.
似乎不是指向 DNS 服务器,而是指向 ngINX 服务器 ( eksempel.dk
),该服务器以 HTML 重定向到www.dk-hostmaster.dk
/217.70.186.102 进行应答。
至于ping
显示另一个名称,这是因为对于不带点的名称请求(例如 dk),它将附加 DNS 解析器使用的域的后缀列表(如@JdeBP 所说)并解析为 RR A,然后解析为关联的 PTR DNS 记录。
或者使用带有的点 (dk.) ping
,它会解析为 193.163.102.58 的 A RR dk.
,然后获取 193.163.102.58 的 PTR/反向 RR static3.prod.dkhm.dk
。
static3.prod.dkhm.dk
是负责 dk 域的组织为生产网络默认生成的名称。
$ nslookup
> set type=A
> dk.
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: dk
Address: 193.163.102.58
> 193.163.102.58
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
58.102.163.193.in-addr.arpa name = static3.prod.dkhm.dk.
或者监控 ping:
ping -c1 dk.
使用 tcpdump:
$ sudo tcpdump -n port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:44:04.742533 IP 192.168.5.143.46424 > 192.168.5.2.53: 12659+ A? dk. (20)
12:44:04.744365 IP 192.168.5.2.53 > 192.168.5.143.46424: 12659*- 1/0/0 A 193.163.102.58 (48)
12:44:04.849969 IP 192.168.5.143.46424 > 192.168.5.2.53: 37304+ PTR? 58.102.163.193.in-addr.arpa. (45)
12:44:04.893196 IP 192.168.5.2.53 > 192.168.5.143.46424: 37304 1/0/1 PTR static3.prod.dkhm.dk. (117)
PS 在 BIND 语言中,您将上述 RR A 定义为:
$ORIGIN dk.
@ IN A 193.163.102.58
RR = 资源记录
TLDR 这不是一个错误的 DNS 答案,它是有记录的和预期的行为。
“题外话”评论:奇怪的是,它eksempel.dk
似乎是一个文档/培训/开发服务器,它使用让我们加密的证书进一步证实了这一点。