DNS协议以及报文格式总结

主要参考内容为RFC 1034、1035（简略参考，需要时再去阅读）还有以下博客参考

本文只是简略总结学习DNS协议的要点。

总结下来就是核心是分层式的思想。有以下几个点：

• 分层式结构自然引出树结构，树的每一个父节点只负责管理子节点的信息。
  

• 节点的表示引出域名概念，按照RFC文档的规定，域名是0-63个字节的在指定字符范围内的标签，其中最特殊的0个字节缺省为根节点专属的域名。

• 最终的主机名，是一个从根节点到达叶节点的自顶向下路径，并且路径上相邻父子节点之间通过.分隔，形成对人类友好的字符串形式。

• 在DNS报文中，主机名将其中的点号分割替换为，通过表明域名长度的数字分割。显然结尾是0，以表示到达根节点，在此也可以看出，利用NULL作为根节点表示，是为了方便DNS报文中表示主机名结尾。

• 域名服务器，是域名父节点管理其子节点信息的实际执行者。一般分为根服务器，顶级域名服务器，权威服务器

而DNS协议解析，根据RFC 1034的说法，是通过resolver完成的，实际上过程是这样的。

• 对于迭代查询：
  • 客户端选择代理服务器，让他完成所有查询任务。
  • DNS代理服务器完成如下操作，以下为比喻。
  • DNS代理服务器中预先有根服务器主机名以及其IP地址，因此去到根节点上，在已知需要解析的主机名，因此，我可以推断出下一级的域名，也就是下一个要去子节点的标签，而当前根节点具有的恰好就是所有他管理的子节点信息。
  • 子节点信息主要是，子节点的主机名是什么？子节点的IP地址是什么？这解决了是谁，在哪里的问题。
  • 之后代理服务器就跑去这个查出来的子节点，这时候，根据树是递归定义出来的，当前的节点到达我想到达的最终主机之间又可以看作一棵树，那么我就还让代理服务器按照先前的方式不断地问，知道遇到了叶子节点IP地址。
  • 此时，代理服务器完成任务，就把查出来的IP地址返回给客户端。
• 对于递归查询：
  • 客户端选择代理服务器，让他完成所有查询任务。
  • DNS代理服务器完成如下操作，以下为比喻。
  • 此时，查询就像一个甩锅的过程，先前除了代理服务器，所有服务器都是询问-回答的状态，而递归查询则是，代理服务器把查询任务丢给了根服务器，根服务器认出这是递归查询，就跑到有这个需要解析的路径分析出的子节点所在处（事实上，他只知道他的子节点，他查询时候能管的也只有他的子节点），把任务丢给子节点，然后，就静静等待子节点完成交差，等到子节点完成后，就把这个最终的结果还给代理服务器。
  • 每一级都是如此，把任务甩给下一节点，静静等待下一节点完成后，在还给之前给自己指派任务的服务器，也可以理解为，每一个下一节点的DNS服务器，都被当作了一个代理服务器。

每次这么来一遍，效率很低，考虑到现实中一个地址可能要问好几次，比如，学生选课，期间，选课官网在一段时间内，肯定是高频访问，那么如果代理服务器有存储先前的结果，那就不必大费周章的从头推导，直接背书完了。当然了，每次都要有新知识的流入，比如过一段时间，LOL S赛直播，整个大学就开始需要直播间的地址，所以，就得忘掉旧知识，不然屯的都是旧知识，没有把新知识背住，新知识用起来就很麻烦。这就是DNS服务器缓存服务器的概念，以及TTL的由来。

因特网的协议，重要特色就是报文格式，格式化的交流方式，才可以使得因特网够高效稳定。

头部

• 会话标识（2 bytes）：请求报文与对应的应答报文整个是相同的，区分应答是针对哪一个询问。
• 标志（2 bytes）：是一个标准的bit-wise的标识方法，每一位的意义如下
  • QR (1 BIT): 查询对应0，响应为1
  • opcode(4 bits): 0-标准查询，1-反向查询，2-服务器状态请求
  • AA(1 BIT): 授权回答
  • TC(1 BIT): 可截断
  • RD（1bit）：表示期望递归。
  • RA（1bit）：表示可用递归。
  • Z(3 bits): 全0
  • rcode(4 bits): 应答，类似http的404，200之类的。
    • 0 没有错误。
    • 1 报文格式错误(Format error) - 服务器不能理解请求的报文。
    • 2 服务器失败(Server failure) - 因为服务器的原因导致没办法处理这个请求。
    • 3 名字错误(Name Error) - 只有对授权域名解析服务器有意义，指出解析的域名不存在。
    • 4 没有实现(Not Implemented) - 域名服务器不支持查询类型。
    • 5 拒绝(Refused) - 服务器由于设置的策略拒绝给出应答。比如，服务器不希望对某些请求者给出应答，或者服务器不希望进行某些操作（比如区域传送zone transfer）。
    • 6：本来应该没有的域名，但是有
    • 7：有一个资源记录集存在，本来不应该有
    • 8：有一个资源记录集应该有，但它没有
    • 9：查询的服务器并不权威
    • 10：相关的信息并不是当前域存在的
  • 数量字段，协议报文经常出现的部分。Questions、Answer RRs、Authority RRs、Additional RRs 各自表示后面的四个区域的数目。Questions表示查询问题区域节的数量，Answers表示回答区域的数量，Authoritative namesversers表示授权区域的数量，Additional recoreds表示附加区域的数量。

正文

分为Queries 和 RR部分

Queries

• 查询名NAME: 长度不固定，一般是需要查询的主机名(uestc.edu.cn诸如此类)，如果是反向查询，就是IP地址。格式如前所述，一个字节的数字标识域名的长度，并将整个主机名分割。
  

• 查询类型，这是由RFC定义的RR 类型，起初只定义了一部分，随着IPV6等问题，在之后的RFC文档又定义了新的类型

• 查询类：有chaos,internet，通常选internet，用1表示

资源记录

包含回答，授权，附加三个区域，格式一致。其中回答是对询问的响应，授权是权威服务器端信息，附加是可能有用的信息。

格式如下

• 既然是对于回答的应答，那也该有对应，所以按照此思路设计
• 域名：一种方式就是同Queries所陈述的一样，但是，出现重复的情况，我们可以设置一个指针指向那个域名，节省空间。这种偏移指针的方式，长度为两字节，最高两位指定为11后，就能识别这是一个偏移指针，剩下14位就用于指出偏移地址，以DNS报文开头为0
• 对应Queries的有查询类型，查询类
• 生存时间（TTL)：这就是之前提到的为了缓存服务器而设置的。
• 资源数据：前面铺垫这么多，就需要干货了。如果查询要的是A型RR，那就返回IPV4地址，是一个CNAME的RR，那就返回一个规范主机名。