DNS的扩展机制
DNS扩展机制（EDNS）是用于扩展域名系统（DNS）协议的几个参数的大小的规范，该参数具有Internet工程界认为对于增加协议功能而言过于受限的大小限制。第一组扩展由Internet工程任务组于1999年发布，名称为RFC 2671，也称为EDNS0 [1]，由RFC 6891在2013年进行了更新，将缩写略微更改为EDNS（0）。[2]
动机[编辑]
该域名系统最早是在20世纪80年代初开发。从那时起，它一直在使用新功能逐步增强，同时保持了与该协议早期版本的兼容性。
基本DNS协议中可用的几个标志字段，返回代码和标签类型的大小限制阻止了某些所需功能的支持。此外，UDP承载的DNS消息被限制为512字节，而不考虑Internet协议（IP）和传输层标头。[3]使用传输控制协议（TCP）进行虚拟电路传输将大大增加开销。这是向DNS添加新功能的主要障碍。1999年，保罗·维克西（Paul Vixie） 建议扩展DNS以允许新的标志和响应代码，并在与以前的实现向后兼容的框架中为更长的响应提供支持。
机制[编辑]
由于无法在DNS标头中添加新标志，因此EDNS以DNS消息的“其他数据”部分中包含的伪资源记录（“ pseudo-RR”）的形式向DNS消息添加信息。请注意，此部分同时存在于请求和响应中。
EDNS引入了一种伪RR类型：OPT。
作为伪RR，OPT类型的RR永远不会出现在任何区域文件中。它们仅存在于由DNS参与者伪造的消息中。
该机制是向后兼容的，因为较旧的DNS响应者会忽略请求中任何未知OPT类型的RR，而较新的DNS响应者则永远不会在响应中包含OPT，除非请求中没有OPT。请求中存在OPT表示一个较新的请求者，该请求者知道如何处理响应中的OPT。
OPT伪记录提供最多16个标志的空间，并扩展了响应代码的空间。UDP数据包的总体大小和版本号（当前为0）包含在OPT记录中。可变长度数据字段允许在协议的未来版本中注册更多信息。原始DNS协议提供了两种标签类型，它们由DNS数据包（RFC 1035）的前两位定义：00（标准标签）和11（压缩标签）。EDNS引入了标签类型01作为扩展标签。第一个字节的低6位可用于定义多达63个新的扩展标签。
例子[编辑]
域信息Groper（dig）实用工具显示的OPT伪记录的示例：
;; OPT拟断面： ; EDNS：版本：0，标志：做；udp：4096
“ EDNS：版本：0”的结果表示完全符合EDNS0。[4]结果“标志：做”表示已设置“ DNSSEC OK”。[5]
应用程序[编辑]
EDNS对于实施DNS安全扩展（DNSSEC）是必不可少的。[6] EDNS还用于以EDNS客户端子网（ECS）选项的形式从解析器向名称服务器发送有关客户端地理位置的常规信息。[7]
有一些建议使用EDNS来设置DNS消息周围应填充的填充量[8]，并指出TCP连接应保持多长时间。[9]
问题[编辑]
实际上，使用EDNS穿越防火墙时可能会遇到困难，因为某些防火墙假定DNS消息的最大长度为512字节，并阻止更长的DNS数据包。
EDNS的引入使DNS放大攻击变得可行，这是一种反映性的拒绝服务攻击，因为与相对较小的请求数据包相比，EDNS可以处理非常大的响应数据包。
IETF DNS扩展工作组（dnsext）已完成对EDNS0的改进，该版本已发布为RFC 6891。
参考[编辑]
- ^ 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 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、其它
RFC2671中还包含了很多EDNS0实现时请求方和响应方注意的事项，以及EDNS0带来的问题，对它们感兴趣的可以移步这里。