【转】EDNS

转自：https://www.cnblogs.com/cobbliu/p/3188632.html　

　随着业务的复杂化和多样化，RFC1035中定义的DNS消息格式和它支持的消息内容已经不足以满足一些DNS服务器的需求，于是，RFC2671中提出了一种扩展DNS机制EDNS(Extension Mechanisms for DNS)，并在其中推荐了一种传递包大小的EDNS0。我将EDNS0中的一些关键内容总结在这篇文章中，以便日后翻阅，同时希望能够帮助到像我这样迷茫过的、探寻EDNS很久才知道其概貌的新人。

    一，什么是EDNS？

     EDNS就是在遵循已有的DNS消息格式的基础上增加一些字段，来支持更多的DNS请求业务。

     需要注意的是，像DNS服务器这样一个大型且广泛应用的系统软件，新增加扩展协议的时候一定要考虑到向后兼容性(backward compatibility)，即你增加了你这个特性的消息传输给未支持该特性的服务器时，后者依然能正确处理。

    二，为什么要有EDNS？

      RFC2671中指出EDNS被提出来的几个理由：

         1）DNS协议头部的第二个16字节中都已经被用的差不多了，需要添加新的返回类型(RCODE)和标记(FLAGS)来支持其他需求；

         2）只为标示domain类型的标签分配了两位，现在已经用掉了两位（00标示字符串类型，11表示压缩类型），后面如果有更多的标签类型则无法支持；

         3）当初DNS协议中设计的用UDP包传输时包大小限制为512字节，现在很多主机已经具备重组大数据包的能力，所以要有一种机制来允许DNS请求方通知DNS服务器让其返回大包；

        以后我们会看到，DNSSEC机制和edns-client-subnet机制等都需要有EDNS的支持。

     三，EDNS的内容是什么？

        怎样在DNS消息协议的基础上再增加一些字段呢？为了保持向后兼容性，更改已有的DNS协议格式是不可能的，所以只能在DNS协议的数据部分中做文章。

        所以，EDNS中引入了一种新的伪资源记录OPT（Resource Record），之所以叫做伪资源记录是因为它不包含任何DNS数据，OPT RR不能被cache、不能被转发、不能被存储在zone文件中。OPT被放在DNS通信双方（requestor和responsor）DNS消息的Additional data区域中。

        1，OPT伪资源记录中的内容有哪些呢？

          OPT pseudo-RR中的内容包含固定部分和可变部分。它的结构如下：

                图1 OPT内容

 

    图1中最下面的RDATA是可变部分，其余的部分都是固定部分：Name字段目前为空；TYPE字段是OPT RR的类型编号，IANA为其分配的是41（0x29）；TTL中是扩展的DNS消息头部，下面会有介绍；RDLEN是可变部分RDATA的长度；RDATA是KV类型的可变部分。

     原来的TTL字段被用来存储扩展消息头部中的RCODE和flags，它的格式如下：

        

                           图2 extended RCODE and flags Detail

     图2中高位8个bit是扩展RCODE（返回状态码），这8个bit加上DNS头部的4bit总共有12bit（8bit在高位），这样就可以表示更多的返回类型；

      VERSOION字段表示EDNS的版本（EDNS根据支持不同的扩展内容会有很多版本），这篇文章提到的内容的VERSION=0

      RFC2671中Z一般情况下被发送者设置为0，接收方可以忽略它。但是后续的扩展协议中会用到这16bit。

 

       OPT RR中可变部分RDATA的结构如下图所示：

图3 RDATA格式

    图3中OPTION-CODE由IANA分配；OPTION-LENGTH是OPTION-DATA的长度；OPTION-DATA是具体长度。

      上面三个图之间的关系用下图看或许会清晰一点：

　　 需要注意的是，每个DNS 消息中只能有一个OPT伪资源记录，当有多中EDNS扩展协议时，各个{attribute, value}对一个紧接一个存储在RDATA中。如下图所示

   

可以看到当有NSID和CSUBNET的时候，两个RDATA紧密排列在OPT的RDATA字段中，它们两的总长度由Data length指定。

        2，example

       好苦涩的理论啊，我们拿一个实例看看EDNS0的格式吧！

       我在自己的机器上用bind-9.8.1-p1中的dig请求Google首页，并把包大小参数设置为768:

                        ./dig www.google.com.hk +bufsize=768

       用tcpdump抓包，然后用ethereal查看UDP包的内容，下图是请求包的详细内容：

图4 request message

   图4中蓝色的是请求消息中的Additional data中的所有内容，我们可以看到有一个OPT RR，需要注意的是：

      1）TTL字段中的extended RCODE、VERSION和Z被ethereal拆分来显示了；

      2）RDATA length为0说明没有可变消息RDATA，从下面的消息中可以看到确实没有RDATA(...)

 

 下图是响应消息：

图5 response message

图5中可以看出，Additional data中除了四个google权威域名服务器详细信息外还有OPT RR，响应消息包的大小为4096字节。

      3，Others

      RFC2671中还包含了很多EDNS0实现时请求方和响应方注意的事项，以及EDNS0带来的问题，对它们感兴趣的可以移步这里。

     四，参考文献

      1，RFC2671

      2，维基百科  http://en.wikipedia.org/wiki/EDNS