原文:Why 13 DNS root servers?
根据自己的理解和查到的资料翻译,本文对原文有删改,如有不当之处,希望指正,谢谢。
为什么根DNS服务器只有13个?
《计算机网络 自顶向下方法》看到91页,上面一句“在因特网上有13个根DNS服务器(标号为A-M)”让我感到疑惑,百度上找了一番大多都是简单一句“受限于 UDP Package 512Bytes大小”,并没有具体的说到“13”这个数字具体是怎么来的。
启动查询是域名服务器启动时获取的根域名服务器IP地址列表执行的查询。 这样做是为了验证(或者更新)它所具有的内置地址列表。 在DNS初期,最大数据包大小被设置为512字节,因此该列表需要适合512字节。
在RFC 791提到最大包长度为576字节。去掉头(headers)之后,剩下512字节有效载荷(payload)。
在这里我只简单举俩例列出{a,b}.root-servers.net发送数据包所占用的字节数,并删除一些现代功能作为AAAA和OPT记录,返回的消息如下:
;; HEADERS
;; QUESTION SECTION:
. IN NS
;; ANSWER SECTION:
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
;; ADDITIONAL SECTION:
a.root-servers.net. 3600000 IN A 198.41.0.4
b.root-servers.net. 3600000 IN A 192.228.79.201
这条消息占用了多少字节呢?
1. HEADERS [共12字节]
首先DNS包的头占用了12字节
2. QUESTION SECTION [共5字节]
- QNAME: 1字节 # 要让DNS服务器解析的域名
- QCLASS: 2字节 (IN) # 2个字节表示查询的协议类
# 比如:IN代表Internet、CS代表CSNET、CH代表CHAOS、HS代表HESIOD、*代表任意类
- QTYPE: 2字节 (NS) # 2个字节表示查询类型
# 比如:NS代表权威域名服务器、A代表主机地址、CNAME代表别名、MX代表邮件交换
# TXT代表文本字符串、*代表所有记录
3. ANSWER SECTION (有两种情况)
第一条Resource Record组成部分如下:
3.1 第一条[共31字节]
- NAME: 1字节
- TTL: 4字节 (518400) # 资源记录被丢弃前的缓存时间,单位为秒
- CLASS: 2字节 (IN) # 同QUESTION 的QCLASS中的CLASS子集
- TYPE: 2字节 (NS) # 同QUESTION 的QTYPE中的TYPE子集
- RDLENGTH: 2字节 # RDATA长度
- RDATA: <1>a<12>root-servers<3>net<0>
: 20字节
其它Resource Record可以使用DNS压缩(DNS Compression),因此后续记录组成部分如下:
3.2 剩余其它条(从第二条开始)[共15字节]
- NAME: 1字节
- TTL: 4字节 (518400)
- CLASS: 2字节 (IN)
- TYPE: 2字节 (NS)
- RDLENGTH: 2字节 (A)
- RDATA: <1><letter><compression pointer>
:4字节 (可以使用DNS压缩,比之前节省16个字节)
4. ADDITIONAL SECTION [共16字节]
- NAME: <1>a<12>root-servers<3>net<0>
: 2字节
- TTL: 4字节 (3600000)
- CLASS: 2字节 (IN)
- TYPE: 2字节 (A)
- RDLENGTH: 2字节
- RDATA: 4字节 # 不定长字符串来表示记录,格式根TYPE和CLASS有关。
# 比如,TYPE是A,CLASS 是 IN,那么RDATA就是一个4个字节的ARPA网络地址。
这里的NAME可以完全压缩,使用2字节压缩指针指向之前出现的位置,所以一条ADDITIONAL SECTION总共占16字节
所以合计如下:
Bytes | Section |
---|---|
12 | ->>HEADER<<- |
5 | QUESTION SECTION |
31 + 15n | ANSWER SECTION |
16n | ADDITIONAL SECTION |
所以等式如下:
12 + 5 + 31 + 15n + 16n = 512
n = 464/31 = 14.967741
emmmm,突然懵圈???为啥是14不是13
博主猜测,多出来一个没用可能是预留备用的。
讨论
更新1
The original list didn’t use the root-servers.net suffix, but was smaller than 512 bytes anyhow. When the list was extended the root-servers.net suffix was created to save space (compression) and made it possible to have 14 root servers, of which 13 have been allocated. This predates anycast so a large® number of servers was needed, according to Bill Maning:
… this predates anycast, so it was thought prudent to wait to select all the remaining operators. as it turns out, the realignment did not go according to plan, VSGN has two and ICANN has one. the original idea was a second operator in asia and on in south america…
Also the step going from a mishmash of names to the ones with a common suffix and the 512-byte calculation was done in one step.
更新2
old root hints file from BIND 4.9.2-940221.
;
; This file holds the information on root name servers needed to
; initialize cache of Internet domain name servers
; (e.g. reference this file in the "cache . <file>"
; configuration file of BIND domain name servers).
;
; This file is made available by InterNIC registration services
; under anonymous FTP as
; file /domain/named.root
; on server FTP.RS.INTERNIC.NET
; -OR- under Gopher at RS.INTERNIC.NET
; under menu InterNIC Registration Services (NSI)
; submenu InterNIC Registration Archives
; file named.root
;
; last update: April 21, 1993
; related version of root zone: 930421
;
. 99999999 IN NS NS.INTERNIC.NET.
NS.INTERNIC.NET. 99999999 A 198.41.0.4
. 99999999 NS KAVA.NISC.SRI.COM.
KAVA.NISC.SRI.COM. 99999999 A 192.33.33.24
. 99999999 NS C.NYSER.NET.
C.NYSER.NET. 99999999 A 192.33.4.12
. 99999999 NS TERP.UMD.EDU.
TERP.UMD.EDU. 99999999 A 128.8.10.90
. 99999999 NS NS.NASA.GOV.
NS.NASA.GOV. 99999999 A 128.102.16.10
99999999 A 192.52.195.10
. 99999999 NS NS.NIC.DDN.MIL.
NS.NIC.DDN.MIL. 99999999 A 192.112.36.4
. 99999999 NS AOS.ARL.ARMY.MIL.
AOS.ARL.ARMY.MIL. 99999999 A 128.63.4.82
99999999 A 192.5.25.82
. 99999999 NS NIC.NORDU.NET.
NIC.NORDU.NET. 99999999 A 192.36.148.17