RFC 2671， DNS的扩展机制（EDNS0）， P。Vixie，互联网协会（1999年8月）
RFC 6891， DNS的扩展机制（EDNS（0）），J.Damas，M.Graff，P.Vixie，（2013年4月）
RFC 1035，域名-实现和规范，P。Mockapetris（1987年11月）
IETF的网络工作组，1999年8月，RFC 2671：DNS的扩展机制（EDNS0），第3页，与该规范的完全符合由版本“ 0”指示。
IETF的网络工作组，2001年12月，RFC 3225：指示DNSSEC的解析器支持，第3页，为显式通知客户端接受（如果不理解）DNSSEC安全RR能力而选择的机制使用的最多。查询中EDNS0 OPT标头上Z字段的有效位。该位称为“ DNSSEC OK”（DNS）位。
RFC 4035， DNS安全扩展的协议修改，R。Arends，Telematica研究所，2005年。第4.1节EDNS支持
Contavalli，卡洛。“ RFC 7871：DNS查询中的客户端子网”。tools.ietf.org 。检索2018-02-02。
Mayrhofer，亚历山大。“ RFC 7830：EDNS（0）填充选项”。tools.ietf.org 。检索2018-02-02。
Wouters，保罗。“ RFC 7828：edns-tcp-keepalive EDNS0选项”。tools.ietf.org 。检索2018-02-02。
EDNS 机制详解随着业务的复杂化和多样化，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、举个栗子好枯燥的理论啊，我们拿一个实例看看EDNS0的格式吧！
我在自己的机器上用bind-9.8.1-p1中的dig请求Google首页，并把包大小参数设置为768:
./dig +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、其它RFC2671中还包含了很多EDNS0实现时请求方和响应方注意的事项，以及EDNS0带来的问题，对它们感兴趣的可以移步这里。
