关于dns使用协议的探究

这几天有人问我dns使用协议的问题，之前只知道大概的一个情况，为了详细了解下，google并进行了测试，做下总结：

首先dns是使用tcp + udp的。

使用tcp的场景：

1.区域复制

2.解析返回结果比较大的时候（udp报文内容超过512字节时）

3.rndc 管理dns

4.udp端口不能返回解析，重新使用tcp请求解析（这个和dns的版本有关，bind9是不行的）

使用udp的场景：

用户解析访问。

为什么区域复制时使用tcp而用户访问时使用udp呢？

1.tcp是面向链接的，而且会对数据进行验证，这样区域复制的数据就不会出错，另外由于报文大小的限制也导致区域传送时使用tcp报文

2.正因为tcp是面向连接的，而且建立连接时需要3次握手，用户在使用dns解析时，如果使用tcp报文响应速度会受影响，服务器也会因为维护

大量的tcp连接而产生比较大的压力

3.udp相对来说比较安全些？不多dns的安全还是使用dnssec比较好（dnssec返回的内容会比较大，在超过限制时使用tcp报文，不超过限制时还是使用udp）

那么再思考下：区域复制是否可以使用udp？查询是否可以在不超过限制时使用tcp?

在dig中有几个参数可以方便做下相关的测试：

       +[no]tcp

           Use [do not use] TCP when querying name servers. The default behavior is to use UDP unless an AXFR or IXFR

           query is requested, in which case a TCP connection is used.

       +[no]ignore

           Ignore truncation in UDP responses instead of retrying with TCP. By default, TCP retries are performed.

       +[no]dnssec

           Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO) in the OPT record in the additional

           section of the query.

       +[no]vc

           Use [do not use] TCP when querying name servers. This alternate syntax to +[no]tcp is provided for

           backwards compatibility. The "vc" stands for "virtual circuit".

几个测试结果：

1.区域复制和普通的udp解析就不用说了。

2.dnssec默认使用udp的也比较好测试。

3.普通dns请求也可以使用tcp

dig @server a.vimage2.com  +tcp

标准的tcp解析流程

4.区域复制是否可以使用udp?

dig @180.186.22.61 dnsserver  axfr +notcp  

测试结果：抓包，发现不起作用，还是使用tcp. 不过网上搜到下面一句话，大意是区域复制返回报文内容大小在512字节以内也是可以使用udp的，应该还是和dig的版本有一定关系。。。

Lets say that target system personnel have foolishly decided to prevent DNS Zone transfers by blocking TCP port 53 instead of configuring a list of servers allowed to do zone transfers on the DNS. Everyone knows that zone transfers occur over TCP port 53 and queries occur over UDP port 53. So blocking TCP port 53 should block zone transfers right? Wrong.

Well first of all, if the targets zone file is less than 512 bytes you can transfer it over UDP using DIG with the +notcp option. (Note: dig on my Mac does a TCP transfer regardless of whether or not I specify +notcp. Dig on BT5 works fine.)

5.512限制的测试，主要测试3点，512是指整个报文大小还是去除ip头和udp头之后的大小？超过512时请求是什么样的？超过512时可以使用udp么？

1）构造一个大的返回测试

整个消息报文是533bytes（消息大小为533-20（ip报文头）-8（udp报文头）=505），仍然使用的是udp报文。

结论，只是消息大小，不包括header

rfc1035也明确说明了这一点：

Messages carried by UDP are restricted to 512 bytes (not counting the IP
or UDP headers).  Longer messages are truncated and the TC bit is set in
the header.

2）超过512时的请求流程？

tcpdump抓包测试

可以看到用户首先使用udp进行访问，返回的数据被truncate后，用户在使用标准的tcp请求流程进行请求。

根据RFC 1123的解释：

用户在发起dns请求时，默认是以udp开始的（指定+tcp时，使用tcp），在返回udp truncate的包后，再使用tcp进行请求

Specifically, a DNS resolver or server that is sending a
non-zone-transfer query MUST send a UDP query first. If the
Answer section of the response is truncated and if the
requester supports TCP, it SHOULD try the query again using
TCP.

3）超过512时可以使用udp么？

网上看到下面的一句话：

说是通过在dnsserver端进行设置，可以改变这种行为，不过我的dns版本没有测试成功，后面有环境的话再进行测试。。。

One of the key issues mentioned is that DNSSEC can cause DNS replies to be larger than 512 bytes. DNSSEC (Defined in RFC 4033, RFC 4034, and RFC 4035) requires the ability to transmit larger DNS messages because of the extra key information contained in the query responses. TCP port 53 can be used in the cases where the DNS responses greater than 512 bytes. However, using UDP messages are preferable to using TCP for large DNS messages is due to the fact that TCP connections can consume computing resources for each connection. DNS servers get numerous connections per second and using TCP can add too much overhead. To address this issue, the IETF RFC 2671 "Extension Mechanisms for DNS (EDNS0)" defines a method to extend the UDP buffer size to 4096 bytes to allow for DNSSEC and larger query responses. To enable EDNS0 on your BIND 9 configuration you can use the following BIND operations statement
edns-udp-size 4096 ;

6.另外看到一句话，说是在udp不能正常响应时，会使用tcp重试。

使用iptables墙掉udp 53测试。

dig @server  a.vimage2.com  +time=1  +tries=2

结果：

两次重试后，没有数据返回。

20:03:39.177810 IP (tos 0x0, ttl 64, id 625, offset 0, flags [none], proto UDP (17), length 59)

    server.60301 > server.domain: [bad udp cksum 39f!] 39449+ A? a.vimage2.com. (31)

20:03:40.178088 IP (tos 0x0, ttl 64, id 626, offset 0, flags [none], proto UDP (17), length 59)

    server.60301 > server.domain: [bad udp cksum 39f!] 39449+ A? a.vimage2.com. (31)

看到别人说了一句话。这个行为应该和dns的不同版本有关：

Different DNS resolvers may handle it differently. It is well known that Microsoft DNS resolvers will query with TCP if the UDP response didn't come back in time. However, some other resolvers may not requery with TCP if the UDP queries don't come  back and this is perfectly within the standard as well.

没了。。。额，说了这么多还是要告诉大家，有些细节方面的东西还是需要自己动手做测试的。

参考文档：

http://www.ietf.org/rfc/rfc2671.txt

http://www.ietf.org/rfc/rfc1034.txt

http://www.ietf.org/rfc/rfc1035.txt