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

一，什么是EDNS？

EDNS（Extension Mechanisms for DNS）是一种DNS扩展协议，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，应用场景

RFC 7871“DNS 查询中的客户端子网”和 RFC 7873“域名系统 （DNS） Cookie”。

2，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指定。

3，example

好苦涩的理论啊，我们拿一个实例看看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字节。

4，Others

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

5，如何验证

$ dig jwlchina.cn @119.29.29.29 +client=67.220.91.30; <<>> DiG 9.9.3 <<>> jwlchina.cn @119.29.29.29 +client=67.220.91.30;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24076;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 4096; CLIENT-SUBNET: 67.220.91.30/32/24;; QUESTION SECTION:;jwlchina.cn.			IN	A;; ANSWER SECTION:jwlchina.cn.		600	IN	CNAME	jwlchina.cn.cdn.dnsv1.com.jwlchina.cn.cdn.dnsv1.com. 600	IN	CNAME	689259.p23.tc.cdntip.com.689259.p23.tc.cdntip.com. 180	IN	A	220.194.87.190689259.p23.tc.cdntip.com. 180	IN	A	58.251.150.72689259.p23.tc.cdntip.com. 180	IN	A	14.204.144.140689259.p23.tc.cdntip.com. 180	IN	A	42.56.79.189689259.p23.tc.cdntip.com. 180	IN	A	113.59.43.98;; Query time: 13 msec;; SERVER: 119.29.29.29#53(119.29.29.29);; WHEN: Tue Feb 04 21:05:53 CST 2020;; MSG SIZE  rcvd: 206

1，rfc4033《DNS Security Introduction and Requirements》

rfc4034《Resource Records for the DNS Security Extensions》

rfc4035《Protocol Modifications for the DNS Security Extensions》

rfc5155《DNS Security (DNSSEC) Hashed Authenticated Denial of Existence》

rfc5011《Automated Updates of DNS Security (DNSSEC) Trust Anchors》

rfc3225 《Indicating Resolver Support of DNSSEC》

rfc3008 《Domain Name System Security (DNSSEC) Signing Authority》

2，维基百科

3，DNS Flag Day官方检测 工具链接：https:dnsflagday.net/

4，DNS Capture: UDP, TCP, IP-Fragmentation, EDNS, ECS, Cookie | Weberblog.net