DNS入门到结构

DNS介绍

 

目录

1.DNS的由来 1

2.域名结构 1

3.域名解析过程 2

4.DNS的报文结构 3

5.报文压缩 7

 

1.DNS的由来

DNS(Domain Name System)域名系统，是域名和IP地址相互映射的一个分布式数据库。它起源于美国 是跟随着 Internet 的发展而生的，一开始通过一个HOSTS.TXT文件可以很好的维护主机名到地址的解析，当时的HOSTS.TXT是由一个网络信息中心(NIC)维护的，需要定期从服务器获取最新的HOSTS.TXT文件。当发生变化时，会通过邮件通知你更新地址。但是随着主机数量的增加，维护该文件变得愈发的困难。比如产生如下问题：

在传输HOSTS.TXT文件的过程中产生的网络流量和处理负载，使传输变得困难；

NIC只能保证分配地址的唯一性，没有管理主机名称的权利，无法阻止有人添加一台重复的主机；

由于主机数量的不断增加以及庞大的基数，可能在你拉取HOSTS文件的同时，又有一台新的主机加入或者有的主机地址已经发生了变化；

为了解决上述的问题，南加州大学的 Paul Mockapetris 负责设计这个新系统的体系架构。起初发布了RFCs882和883用以描述DNS。这些RFC后来被RFC1034和RFC1035所取代，也就是现代的DNS规范。当然，现在该规范已经被许多其他的RFC所补充，包括DNS潜在的安全问题，实现问题，管理缺陷，名称服务器的动态更新机制以及保证区域数据的安全性等。

 

1. 域名结构

 

域名结构，域就如文件系统的目录，可以将根域划出com,cn,org等子域。又可以将com划分出更多的子域，如baidu.com中的baidu域，当然还可以继续往下划分。我们平时说的域名就是将各个域用 . 连接起来。如news.baidu.com. (最后的 . 是默认存在的，代表root节点 )。

在网络上的每台主机都有一个域名，它指向该主机的相关信息。这些信息中可能包含IP地址，邮件路由信息等。此外，主机也可以拥有一个或多个域名别名，在域名记录中叫cname，这些域名别名是从某个域名指向另一个域名的指针。如上图的mail.berkeley.edu和amail.news.berkeley.edu，这样设计的原因是为了消除名称冲突的问题。

 

1. 域名解析过程

域名解析是互联网上非常重要的一项服务，上网伴随着大量的DNS服务来支撑的，那么DNS的域名解析经历了一个怎样的过程？我们先来熟悉些概念性名词，如右：

因为DNS是一个分布式的数据库，这允许对整体数据库的各个部分进行本地控制，并且各个部分采用的是客户端/服务器模式。名称服务器就是该机制的服务器端。名称服务器包含了数据库中的部分信息，并使得这些信息能被解析器(resolver)的客户端使用。

熟悉了概念名词后，我们来看下DNS的解析过程如上：

1. 客户机提出域名解析请求，并将该请求发送给本地的域名服务器。
2. 当本地的域名服务器收到请求后，就先查询本地的缓存，如果有该纪录项，则本地的域名服务器就直接把查询的结果返回。
3. 如果本地的缓存中没有该纪录，则本地域名服务器就直接把请求发给根域名服务器，然后根域名服务器再返回给本地域名服务器一个所查询域 (根的子域) 的主域名服务器的地址。
4. 本地服务器再向上一步返回的域名服务器发送请求，然后接受请求的服务器查询自己的缓存，如果没有该纪录，则返回相关的下级的域名服务器的地址。
5. 重复第四步，直到找到正确的纪录。
6. 本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时还将结果返回给客户机。

 

 

1. DNS的报文结构

DNS进行报文的发送与接收需要遵循DNS协议，RFC1035介绍了域名系统与协议的实施及规范。我们参考RFC1035文本对DNS报文结构进行概述。

协议内部的所有通信采用的是单一格式，称作Message，完整的报文结构分成5部分(在某些情况下，它们中一些是空的)。

 

Header 总是存在，其中包括一些字段，字段规定其余部分中哪些部分存在，也规定消息是查询还是响应，是标准查询还是某个其他的操作码，下面我们一一介绍这五个部分如何组成。

 

4.1  Header部分

ID：16 bit，程序生成查询请求的ID与响应ID必须相同，这样我们就能知道哪个响应对应着哪个请求

QR：1bit，定义数据包是查询（0）或者响应（1）数据包

OPCODE：4 bit，表示查询种类，需要复制到响应中：通常值为0

0  标准查询（QUERY） 

1  反响查询（IQUERY）

2  服务器状态查询（STATUS）

3-15  保留将来使用

AA：1 bit，权威回答（Authoritative Answer），只在响应中有效，规定响应的名称服务器是 Question 部分中域名的权威。注意，由于别名，回答部分的内容可以有多个所有者名称。AA 位对应匹配查询名称的名称，或者 Answer 部分中第一个所有者名称。

TC：1 bit，截断（Truncation），表示这条消息由于长度大于传送通道上准许的长度而被截断。

RD：1 bit，期望递归（Recursion Desired），在查询中这个位可以置 1，并复制进响应中。如果 1，它引导名称服务器递归跟踪查询。支持递归查询是可选项。

RA：1 bit，递归可用（Recursion Available），在响应中这个字段被置 1 或 0，表示名称服务器中是否支持递归查询。

Z：3 bit，保留将来使用。在所有查询和响应中此位必须置 0。

RCODE：4 bit，响应代码（Response code），响应的一部分。其取值：

0  没有出错

1  消息格式错误

2  名称服务器故障

3  名称错误，名称不存在

4  不支持查询种类

5  拒绝，拒绝该操作

6-15  保留将来使用

QDCOUNT：无符号 16 bit，Question 部分中条目的数量

ANCOUNT：无符号 16 bit，Answer 部分中资源记录的数量

NSCOUNT：无符号 16 bit，权威记录部分中名称服务器资源记录的数量。

ARCOUNT：无符号 16 bit，附加记录部分中资源记录的数量。

 

4.2  Question部分

查询请求中携带该字段，大部分响应也会返回，此部分包括 QDCOUNT（通常取 1）条目：

QNAME：变长，用标签序列表示的域名，如：deepzz.com，其中 deepzz长度为 6，故QNAME 的值为（16 进制）：06 64 65 65 70 7a 7a 03 63 6f 6d 00

QTYPE：16 bit，它规定查询的类型。这个字段的值包括所有适用于TYPE字段的代码，以及某些更一般的代码（这些代码可以匹配不止一个RR类型）

QCLASS：16 bit，它规定查询的类。例如，对于互联网，QCLASS字段是IN

 

4.3  Resource record

Answer、Authority和Additional都共享相同的格式：可变数目资源记录，其中记录的数目在首部内相应计数字段中规定。

NAME：变长，该记录匹配的域名

CLASS：16 bit，资源类型，影响 RDATA 的数据含义

TTL：32 bit，缓存时间，单位s，0为不缓存

RELENGTH：16 bit，指定 RDATA 的长度

RDATA：变长，这条信息的格式根据资源记录的 TYPE 和 CALSS 改变。例如，如果TYPE是A和CALSS是IN，此RDATA字段是4byte的ARPA互联网地址，即 IPv4。

 

1. 报文压缩

为了减小消息大小，域系统使用去除消息中域名重复的压缩方案。在这个方案中，整个域名或在域名底部的标签列表被用一个指针取代，该指针指向同一名称的前一个具体值。

每段域名如果在之前有重复，会被缩写为两个字节，其中前两个比特位为11，之后14个比特位表示重复内容距离DNS协议报文头的距离，而重复的长度则为到0x00结束，这个特性很多人都没有注意到，导致很多的DNS解析错误或不被解析。

 

补充

域名：由一系列字母（a～z，不区分大小写）、数字（0～9）和连接符（-）组成以及点号分隔符组成，总长度不大于255。分隔符隔出的每段相当于一个层次的域名，级别低的在左，级别高的在右，每段长度不大于63。如域名daily.wangwang.taobao.com，三段域名分别为daily、wangwang、taobao、com，其中com的级别最高。

传输：很多人认为DNS使用了UDP协议来获取域名对应的IP地址，这个观点虽然没错，但是还是有一些片面，更加准确的说法其实是DNS查询在刚设计时主要使用 UDP 协议进行通信，而 TCP 协议也是在DNS的演进和发展中被加入到规范的。

DNS在设计之初就在区域传输中引入了TCP协议，在查询中使用UDP协议；

当DNS超过了 512 字节的限制，我们第一次在DNS协议中明确了『当 DNS 查询被截断时，应该使用TCP协议进行重试』这一规范；

随后引入的EDNS机制允许我们使用UDP最多传输4096字节的数据，但是由于MTU的限制导致的数据分片以及丢失，使得这一特性不够可靠；

因此我们应该使DNS应该同时支持UDP和TCP协议，TCP协议也不再只是重试时的选择；