一种简单的设计方式是在因特网上使用一个DNS服务器，该服务器包含所有的映射。在这种集中式设计中，客户端将所有的查询发往同一台的DNS服务器。但是，这种设计方式的问题如下：

单点故障
通信容量：必须处理所有查询
远距离的集中式数据库：如果将单台DNS服务器放在纽约，那么在澳大利亚的的查询必须传播到地球的另一端，中间也许还要经过拥塞的链路。
维护

基于以上几点，DNS采用分布式设计方案。

分布式、层次数据库

为了处理规模问题，DNS使用了大量的DNS服务器，他们以层次方式组织，并且分布在全世界的范围内。大致来说，有三种类型的DNS服务器：

根DNS服务器：有13个，编号为A到M。尽管我们将这13台DNS服务器中的每个都视为单台服务器，但是实际上他们都是冗余服务器，以提供安全性和可靠性。
顶级域DNS服务器：负责顶级域名（com,org,net等）和所有国家的顶级域名(jp,cn,uk)
权威DNS服务器：在因特网上具有公共可访问主机（如Web服务器和邮件服务器）的每个组织机构必须提供公共可访问的DNS记录，这些记录将主机名字映射为IP地址。由组织机构的权威DNS服务器负责保护这些DNS记录。组织机构可以选择实现他自己的权威DNS服务器来保持这些记录，另一种方法是支付费用将这些记录存储在某个服务提供商的权威DNS服务器中。

根，TLD和权威DNS服务器都处在DNS层级结构中，还有另外一种重要的DNS，叫作本地DNS服务器。本地DNS服务器严格来说并不属于DNS服务器的层级结构，但是它对DNS层级结构是很重要的。主机的本地DNS服务器通常邻近本主机。对于机构ISP而言，本地DNS服务器可能就与主机在同一个局域网中，对于居民区ISP来说，本地DNS服务器通常与主机相隔不超过几个路由器。当主机发出DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并将该请求转发到DNS服务器层级结构中。

举个如上图的例子，主机cis.poly.edu想要知道主机gais.cs.umass.edu的IP地址，主机先向本地DNS服务器发送查询报文，本地DNS服务器将报文转发到根DNS服务器，根DNS服务器注意到edu前缀并向本地DNS服务器返回负责edu的TLD的IP地址列表。本地DNS服务器再次向这些TLD服务器发送查询报文，该TLD服务器注意到umass.edu前缀，并用权威DNS服务器的IP地址进行响应，我们先假设权威服务器的IP地址是dns.umass.edu。最后，本地DNS服务器直接向权威服务器重发查询报文，并获得目的主机的IP。在此过程中，共发送8份报文：4份查询报文和4份回答报文。

在上面的分析过程中，我们假设TLD服务器知道每台主机的权威DNS服务器的IP地址，但是一般情况下不是这样的。相反，TLD服务器只知道中间的某个DNS服务器，该中间的DNS服务器依次才能知道用于该主机的权威DNS服务器的IP地址。同样是上面的例子，当中间的DNS服务器收到对某主机的请求时，该主机名是以cs.umass.edu结尾的，它向本地DNS服务器返回dns.cs.umass.edu的IP地址（上面的例子是dns.umass.edu），后者是所有以cs.umass.edu结尾的主机的权威DNS服务器。本地DNS服务器再向dns.cs.umass.edu发送查询，获得结果。再这个例子中，共发送10份报文。

上面的例子运用了迭代查询和递归查询。从请求主机到本地DNS是递归，后继3个查询都是迭代查询。理论上讲，任何查询既可以是迭代也可以是递归。下图的查询都是递归查询。

实际中，查询通常是请求主机到本地DNS是递归，其余是迭代。

DNS缓存

为了改善性能并减少在因特网上到处传输的DNS报文数量，DNS广泛的使用了缓存技术。在请求链中，当一个DNS服务器收到一个DNS回答，DNS服务器能将回答中的信息缓存在本地存储器。DNS服务器会在一段时间后（通常设置为2天）将丢弃缓存的信息。

DNS记录

实现DNS分布式数据库的所有DNS服务器共同存储着资源记录(Resource Record,RR)。RR提供了主机名到IP地址的映射，每个DNS回答报文包含了一条或者多条资源记录。

资源记录是一个包含了下列字段的4元组：

(Name,Value,Type,TTL)

TTL是该记录的生存时间，决定了资源记录应当从缓存中删除的时间下面给出的例子中我们先忽略TTL字段。Name和Value取决于Type：

如果Type=A,则Name是主机名，Value是主机名的IP地址。因此，一条类型为A的资源记录提供了标准的主机名到IP地址的映射。例如，(relay1.bar.foo.com,145,37,93,126,A)就是一条A记录。
如果Type=NS,则Name是域(如foo.com)，而Value是知道如何获得该域中主机IP地址的权威DNS主机名（也就是用来指定该域名由哪个DNS服务器来进行解析。）。这个记录用于沿着查询链路进一步路由DNS查询。例如，（foo.com,dns.foo.com,NS）就是一条类型为NS是记录。
如果Type=CNAME,则Value是别名为Name的主机对应的规范主机名（有着复杂的主机名的主机可以拥有一个或者多个别名。主机的本名叫作规范主机名。相当于一个人的本名和若干个外号），该记录能够向请求主机提供一个主机名对应的规范主机名。
如果Type=MX,则Value是别名为Name的邮件服务器的规范主机名。例如，(foo.com,mail.bar.foo.com,MX)就是一条MX记录。

如果一台DNS服务器是某特定主机的权威DNS服务器，那么该DNS服务器就会包含一条A型记录。（即使不是DNS服务器,也可能在缓存中有A型记录）。如果DNS服务器不是某个主机名的权威DNS服务器，那么该主机将包含一条NS记录，还将包含一条A记录。例如，edu TLD服务器不是主机gaia.cs.umass.edu的权威DNS服务器，则该服务器将包含一条包括主机cs.umass.edu的域记录，如（umass.edu,dns.umass.edu,NS），还包括一条A记录，如（dns.umass.edu,128.119.40.111,A）。

dig工具

工具软件dig可以显示整个DNS查询过程。

[[email protected] ~]# dig zhidao.baidu.com

输出如下信息：

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6 <<>> zhidao.baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 189
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;zhidao.baidu.com.      IN  A

;; ANSWER SECTION:
zhidao.baidu.com.   5   IN  CNAME   iknow.baidu.com.
iknow.baidu.com.    5   IN  CNAME   iknow.n.shifen.com.
iknow.n.shifen.com. 5   IN  A   123.125.115.90
iknow.n.shifen.com. 5   IN  A   123.125.65.91

;; Query time: 28 msec
;; SERVER: 192.168.183.2#53(192.168.183.2)
;; WHEN: Thu Jul  7 01:44:35 2016
;; MSG SIZE  rcvd: 115

第一段是查询参数和统计：

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6 <<>> zhidao.baidu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 189
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

第二段是查询内容：

;zhidao.baidu.com.      IN  A

查询zhidao.baidu.com的A记录。

第三段是DNS服务器的答复：

;; ANSWER SECTION:
zhidao.baidu.com.   5   IN  CNAME   iknow.baidu.com.
iknow.baidu.com.    5   IN  CNAME   iknow.n.shifen.com.
iknow.n.shifen.com. 5   IN  A   123.125.65.91
iknow.n.shifen.com. 5   IN  A   123.125.115.90

第四段是DNS服务器的一些传输信息：

;; Query time: 29 msec
;; SERVER: 192.168.183.2#53(192.168.183.2)
;; WHEN: Thu Jul  7 02:09:40 2016
;; MSG SIZE  rcvd: 115

上面结果显示，本机的DNS服务器是192.168.183.2，查询端口是53（DNS服务器的默认端口），以及回应长度是115字节。

如果不想看到这么多内容，可以使用+short参数：

[[email protected] ~]# dig +short zhidao.baidu.com
iknow.baidu.com.
iknow.n.shifen.com.
123.125.115.90
123.125.65.91

+trace参数可以显示DNS的整个分级查询过程：

[[email protected] ~]# dig +trace zhidao.baidu.com

第一段列出根域名.的所有NS记录，即所有根域名服务器。

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6 <<>> +trace zhidao.baidu.com
;; global options: +cmd
.           5   IN  NS  l.root-servers.net.
.           5   IN  NS  b.root-servers.net.
.           5   IN  NS  j.root-servers.net.
.           5   IN  NS  m.root-servers.net.
.           5   IN  NS  g.root-servers.net.
.           5   IN  NS  h.root-servers.net.
.           5   IN  NS  c.root-servers.net.
.           5   IN  NS  i.root-servers.net.
.           5   IN  NS  f.root-servers.net.
.           5   IN  NS  d.root-servers.net.
.           5   IN  NS  k.root-servers.net.
.           5   IN  NS  a.root-servers.net.
.           5   IN  NS  e.root-servers.net.
;; Received 228 bytes from 192.168.183.2#53(192.168.183.2) in 1544 ms

根据内置的根域名服务器IP地址，DNS服务器向所有这些IP地址发出查询请求，询问zhidao.baidu.com顶级域名服务器com.的NS记录。最先回复的根域名服务器将被缓存，以后只向这台服务器发请求。

com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
;; Received 494 bytes from 192.112.36.4#53(192.112.36.4) in 3203 ms

上面结果显示.com域名的13条NS记录，同时返回的还有每一条记录对应的IP地址。

然后，DNS服务器向这些顶级域名服务器发出查询请求，询问zhidao.baidu.com的次级域名baidu.com的NS记录。

baidu.com.      172800  IN  NS  dns.baidu.com.
baidu.com.      172800  IN  NS  ns2.baidu.com.
baidu.com.      172800  IN  NS  ns3.baidu.com.
baidu.com.      172800  IN  NS  ns4.baidu.com.
baidu.com.      172800  IN  NS  ns7.baidu.com.
;; Received 204 bytes from 192.43.172.30#53(192.43.172.30) in 692 ms

然后，DNS服务器向上面这四台NS服务器查询math.stackexchange.com的主机名。

zhidao.baidu.com.   1200    IN  CNAME   iknow.baidu.com.
iknow.baidu.com.    1200    IN  CNAME   iknow.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns1.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns3.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns5.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns4.n.shifen.com.
n.shifen.com.       86400   IN  NS  ns2.n.shifen.com.
;; Received 253 bytes from 220.181.38.10#53(220.181.38.10) in 662 ms

dig命令的-x参数用于查询PTR记录（用于从IP地址查询域名）

[[email protected] ~]# dig -x 192.30.252.153

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6 <<>> -x 192.30.252.153
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44848
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;153.252.30.192.in-addr.arpa.   IN  PTR

;; ANSWER SECTION:
153.252.30.192.in-addr.arpa. 5  IN  PTR pages.github.com.

;; Query time: 619 msec
;; SERVER: 192.168.183.2#53(192.168.183.2)
;; WHEN: Thu Jul  7 05:40:10 2016
;; MSG SIZE  rcvd: 75

其他DNS查询工具

host

[[email protected] ~]# host zhidao.baidu.com
zhidao.baidu.com is an alias for iknow.baidu.com.
iknow.baidu.com is an alias for iknow.n.shifen.com.
iknow.n.shifen.com has address 123.125.115.90
iknow.n.shifen.com has address 123.125.65.91

nslookup

用于互动式地查询域名记录。

[[email protected] ~]# nslookup
> www.baidu.com
Server:     192.168.183.2   //连上的DNS服务器
Address:    192.168.183.2#53

Non-authoritative answer:     //没有从权威服务器中寻找答案，即从上连DNS服务器的本地缓存中读取出的值，而非实际去查询到的值
www.baidu.com   canonical name = www.a.shifen.com.
Name:   www.a.shifen.com
Address: 61.135.169.125
Name:   www.a.shifen.com
Address: 61.135.169.121

更详细的使用方法：http://roclinux.cn/?p=2441

DNS报文

DNS有2中报文：查询和回答报文。并且具有相同的格式。

各字段语义如下：

前12个字节是首部区域。
标识符是一个16比特的数字，用于标识该查询，该标识符会被复制到回答报文中，以便让客户机用它来匹配发送的请求和收到的回答。
标志字段中含有若干标志。
- QR(1比特）：查询/响应的标志位，1为响应报文，0为查询报文。
- opcode（4比特）：定义查询或响应的类型（若为0则表示是标准的，若为1则是反向的，若为2则是服务器状态请求）。
- AA（1比特）：当某DNS服务器正好是被请求主机的权威DNS服务器时，1比特的“权威的”标志位被置在回答报文中。
- TC（1比特）：截断标志位。1表示响应已超过512字节并已被截断。
- RD（1比特）：这个比特位被请求设置，应答的时候使用的相同的值返回。如果设置了RD，就建议域名服务器进行递归解析，递归查询的支持是可选的。
- RA（1比特）：这个比特位在应答中设置或取消，用来代表服务器是否支持递归查询。
- zero（3比特）：保留字段。
- rcode（4比特）：返回码，表示响应的差错状态，通常为0和3。
- 0 成功的响应
- 1 格式错误--域名服务器无法解析请求，因为请求消息格式错误
- 2 服务器错误--域名服务器因为内部错误无法解析该请求
- 3 名字错误-- 只在权威域名服务器的响应消息中有效，标示请求中请求的域不存在
- 4 域名服务器不支持请求的类型
- 5 域名服务器因为策略的原因拒绝执行请求的操作。例如域名服务器不会为特定的请求者返回查询结果，或者域名服务器不会为特定的请求返回特定的数据
4个数量字段：表示首部后面的4类数据区域出现的数量。
问题区域包含着正在进行的查询信息。格式如下：

该区域包括：

查询名字段：长度不定，一般为要查询的域名（也会有IP的时候，即反向查询）。此部分由一个或者多个标示符序列组成，每个标示符以首字节数的计数值来说明该标示符长度，每个名字以0结束。计数字节数必须是0~63之间。该字段无需填充字节。例如查询域名名为gemini.tuc.noao.edu的话，查询名字段如下：