什么时候会使用TCP53端口

Q: 平时用Sniffer观察到的DNS报文都在使用53/UDP,什么时候会用到53/TCP?

A: 对于DNS服务器,递归解析时用53/UDP,区传输因需要可靠传输,必须使用53/TCP。DNS服务器的标准实现必须同时支持53/TCP和53/UDP。    对于DNS客户端,默认使用53/UDP进行A记录查询。nslookup进行A记录查询时,可以强制使用53/TCP。用Sniffer观察下述操作引发的通信报文:

nslookup
> set vc

> www.anydomain.cn


    RFC 1035中指出,53/UDP上的UDP数据区(不包括UDP首部)不得超过512字节,发送时如果超过512字节,将被截断成512字节,同时DNS协议Flags字段Truncated位置位。   

    53/TCP上的数据区最前面是big-endian序的2字节长度域,不包括自身这2字节,指明了后续数据长度。    

    更多细节参看"http://www.ietf.org/rfc/rfc1035.txt"。   

    网上曾经流行过这样一个说法,当DNS服务产生的响应数据大于512字节(指UDP数据区)时会自动改用53/TCP。注意,RFC 1035从来没有给出过这种说法,即使确有其事那也是DNS服务实现相关的,不是标准行为。


参看<<TCP/IP Illustrated, Volume 1>> 14.8节。    

    名字解析器(DNS Client或递归解析中的DNS Server)发出UDP请求报文,名字服务器(必然是DNS Server)产生的UDP响应数据大于512字节时,只会向名字解析器发送前512字节,同时TC位置位。名字解析器通过TC位得知响应数据没有全部返回,一般实现会选择用TCP重新请求,名字服务器将用TCP返回完整的响应数据。   

    何时用TCP是由名字解析器决定的,也就是说,名字解析器用TCP发送请求,名字服务器才会用TCP发送响应,正常情况下决不会出现请求报文是UDP而响应报文是TCP的情形。之所以强调正常情况下,是因为有一些非正常情况。


以BIND 8.3.3为例。我曾搭建过如下测试环境:


                                    Server B(xxx.org.)
                                /
Client A    -   Server A(org.)
                                \

                                    Fake Server B


    Client A向Server A发送UDP请求报文进行A记录查询(1.xxx.org)。Server A进行递归解析,向Server B发送UDP请求报文,源端口不是53/UDP。    

    Client A向Server A发送TCP请求报文进行A记录查询(1.xxx.org)。Server A进行递归解析,仍然向Server B发送UDP请求报文而不是TCP请求报文,源端口不是53/UDP。   

    Server B收到来自Server A的UDP请求报文后,一般会发送UDP响应报文。现在用FakeServer B换掉Server B,同样是处理来自Server A的UDP请求报文。Fake Server B可以向Server A的53/TCP主动发起连接请求,并在此TCP连接上发送DNS响应数据,源端口不要求是53/TCP。而Server A居然接受来自Fake Server B的异常TCP响应。    

    不知道正常通信中会出现此类现象否。总之,BIND 8.3.3曾经支持这种异常行为。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值