EDNS 扩展的DNS

文章正文
发布时间:2024-11-03 18:01

 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带来的问题,对它们感兴趣的可以移步这里。