7.6 什么时候会用到53/TCP https://scz.617.cn/network/200604121330.txt Q: 平时用Sniffer观察到的DNS报文都在使用53/UDP，什么时候会用到53/TCP？ A: scz 对于DNS服务器，递归解析时用53/UDP，区传输因需要可靠传输，必须使用53/TCP。 DNS服务器的标准实现必须同时支持53/TCP和53/UDP。 对于DNS客户端，默认使用53/UDP进行A记录查询。nslookup进行A记录查询时，可以 强制使用53/TCP。用Sniffer观察下述操作引发的通信报文: nslookup > set vc > www.netexpert.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服务实现相关的，不是标准行为。 A: W. Richard Stevens 1994 参看<> 14.8节。 名字解析器(DNS Client或递归解析中的DNS Server)发出UDP请求报文，名字服务器( 必然是DNS Server)产生的UDP响应数据大于512字节时，只会向名字解析器发送前512 字节，同时TC位置位。名字解析器通过TC位得知响应数据没有全部返回，一般实现会 选择用TCP重新请求，名字服务器将用TCP返回完整的响应数据。 D: scz@nsfocus 2002-11-13 21:20 何时用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响应报文。现在用Fake Server 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曾经支持这种异常行为。