什么时候会使用TCP53端口

admin

https://blog.csdn.net/u013541620/article/details/39933277
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曾经支持这种异常行为。





今天观察到有53的连接,就看了看op的后台,发现dnsmasq竟然在监听TCP的53端口
就搜了一下

竟然还有这种知识

admin

https://blog.csdn.net/weixin_51867896/article/details/122691884
DNS分别在什么时候使用53/tcp、53/udp

TCP：可靠的、面向连接的传输控制协议
UDP：不可靠的、无连接的用户数据报协议

53/tcp：区域传输

53/udp：查询、区域传输、DNS主辅复制、DNS主辅同步、域名解析

admin

https://blog.csdn.net/ldw662523/ ... tm_relevant_index=9


DNS在两种情况下使用TCP
1.如果用wireshark、sniffer或古老些的tcpdump抓包分析，会发现几乎所有的情况都是在使用UDP，使用TCP的情况非常罕见。其实当解析器发出一个request后，返回的response中的tc删节标志比特位被置1时，说明反馈报文因为超长而有删节。这是因为UDP的报文最大长度为512字节。解析器发现后，将使用TCP重发request，TCP允许报文长度超过512字节。既然TCP能将data stream分成多个segment，它就能用更多的segment来传送任意长度的数据。
UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志出现删除标志，这时则使用TCP发送。通常传统的UDP报文一般不会大于512字节。
2.另外一种情况是，DNS在进行区域传输的时候使用TCP协议，其它时候则使用UDP协议。
DNS的规范规定了2种类型的DNS服务器，一个叫主DNS服务器，一个叫辅助DNS服务器。在一个区中主DNS服务器从自己本机的数据文件中读取该区的DNS数据信息，而辅助DNS服务器则从区的主DNS服务器中读取该区的DNS数据信息。当一个辅助DNS服务器启动时，它需要与主DNS服务器通信，并加载数据信息，这就叫做区传送（zone transfer）。
辅域名服务器会定时（一般时3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，一是因为数据同步传送的数据量比一个请求和应答的数据量要多得多；二是因为TCP是一种可靠的连接，保证了数据的准确性。
DNS更多情况下使用UDP
客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过TCP三次握手，这样DNS服务器负载更低，响应更快。虽然从理论上说，客户端也可以指定向DNS服务器查询的时候使用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。
————————————————

                            版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
                        
原文链接：https://blog.csdn.net/ldw662523/article/details/79564884