大家好，如果您还对听说DNS根服务器只有13台，科学吗？-dns根服务器为啥13个不太了解，没有关系，今天就由本站为大家分享听说DNS根服务器只有13台，科学吗？-dns根服务器为啥13个的知识，包括的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！
继续上一篇文章《DNS中有哪些值得学习的优秀设计》，最后还有两个问题。
DNS基于UDP协议
• 从抓包中可以看出，DNS在传输层使用UDP协议。它只使用UDP吗？
• DNS的IPV4根域名仅有13个，其中很多实际部署在美丽的国家。那是不是意味着只要他们不高兴，切断我们的访问权限，我们的网络就会瘫痪？
我们来扩展一下今天的话题。
DNS是基于UDP的应用层协议吗？
当我们执行dig www.baidu.com时，操作系统会发出dns请求，询问www.baidu.com域名对应的IP是什么。
$ 挖掘www.baidu.com
;DiG9.10.6www.baidu.com
;全局选项：+cmd
;得到答案：
;-头操作码：QUERY，状态：NOERROR，id:61559
;flags:qr rd ra;查询：1，答案：3，权威：0，附加：1
;选择伪节：
;EDNS:版本：0，标志：udp:4000
;问题部分：
;www.baidu.com.INA
;答案第： 节
www.baidu.com.298INCNAME www.a.shifen.com。
www.a.shifen.com.298INA180.101.49.12
www.a.shifen.com.298INA180.101.49.11 此时，从抓包的角度来看，DNS是应用层协议，在传输层确实使用了UDP协议。
传输层采用UDP协议
然而，它实际上在RFC 5966 中提到过。
#https://www.rfceditor.org/rfc/rfc5966
本文档更新了DNS 实施支持TCPasa 传输协议的要求。换句话说，虽然我们在大多数情况下看到DNS使用UDP，但DNS实际上也支持TCP。
当我们在dig命令中添加+tcp选项时，我们可以强制DNS查询使用TCP协议进行数据传输。
$ dig+tcp www.baidu.com
;DiG9.10.6+tcp www.baidu.com
;全局选项：+cmd
;得到答案：
;-HEADER-操作码：QUERY，状态：NOERROR，id:28411
;flags:qr rd ra;查询：1，答案：3，权威：0，附加：1
;选择伪节：
;EDNS:版本：0，标志：udp:4000
;问题部分：
;www.baidu.com.INA
;答案第： 节
www.baidu.com.600INCNAME www.a.shifen.com。
www.a.shifen.com.600INA180.101.49.11
www.a.shifen.com.600INA180.101.49.12 此时再次抓包。
传输层采用TCP协议
可以发现，在传输层，DNS采用的是TCP协议。
那么问题就出现了。
为什么有UDP了还要用到TCP？我们知道网络传输就像在某个管道中传输数据包。这种管道有一定的厚度，称为MTU。如果超过MTU，则会在发送端网络层进行分段，然后在接收端网络层重新组装。重组需要缓冲。该缓冲区的大小有一个最小值，即576Byte。
IP层分片后传输会增加丢包的概率，而IP层本身不具备重传功能，因此需要尽可能避免IP层分片。
如果传输过程中确实出现了分片，那么需要尽力保证在接收端能够顺利重组，所以在最安全的情况下，将MTU设置为576。（有点太谨慎了，现在大多数场景下MTU=1500） ）。
基于这个前提，从这个MTU长度中排除IP头和UDP头后，大约还剩下512Byte。
这就是为什么RFC1035中提到，在UDP场景下，DNS消息长度不能超过512Byte。
如果超过，就会被截断。那么数据包就会不完整，可能会导致下游无法正常解析数据。
但不可避免的，总会存在需要传输大量数据的场景。
该怎么办？然后改用TCP。
因为TCP本身会被分段，所以分段后的长度恰好小于或等于MTU的长度。并且丢包后会进行重传，保证数据的正常传输。
因此，当数据包长度大于512时，DNS需要使用TCP协议进行传输。
那既然TCP那么好，为什么不全用TCP？我们可以对比上面UDP和TCP的两张图，会发现TCP场景中除了DNS请求和响应这两个数据包之外，还多了3个握手包和4个挥手包。
乍一看，似乎不多。
我们回过头来看看通过DNS协议查询某个域名对应的IP的过程。
如果对查询过程进行细分，可以分为迭代查询和递归查询。
迭代查询和递归查询是什么迭代查询是指下发DNS后，如果对方不知道该域名的IP，它就会告诉我可能知道此事的机器的IP，我再去询问可能知道此事的机器知道事情的经过，重复一遍，直到问出结果。
递归查询是指发出DNS请求后，要求对方检查后直接提供最终结果。
看起来递归查询很方便，但实际上它把查询过程转移到了其他DNS服务器上。很多时候，两者是同时存在的。
举个例子。
迭代和递归查询
例如查询www.baidu.com对应的IP。
当本机发出DNS 请求时，它会要求最近的DNS 服务器检查结果，然后将结果返回到本机（步骤1），因此这就是所需的递归查询。
这台机器很轻松，但最近的DNS 服务器（可能是您的家庭路由器）需要繁忙。需要使用迭代查询。在最坏的情况下，它需要：
step2: 查询根域名服务器
step3: 获取根域名服务器返回的一级域名（com）服务器IP。
步骤4: 然后查询一级域名（com）服务器
步骤5: 获取二级域（baidu）服务器的IP
step6: 查询二级域（baidu）服务器
步骤7: 获取三级域（www）服务器的IP
step8: 查询三级域名（www）服务器
步骤9: 获取www.baidu.com服务器的IP
此时，DNS服务器将结果放入缓存后，会将结果返回给本机（步骤10）。
可以看到，在这个场景中，迭代查询和递归查询实际上是同时存在的。
迭代查询和递归查询的报文特征这也反映在DNS 标头中。
DNS消息
我们需要注意的是Flags字段中的RD和RA字段。
RD（Resursion Desired）是指客户端期望的查询方式。
•0：表示迭代查询
• 1：表示递归查询
RA（RecursionAvailable）是指服务器实际使用的查询方法。它只会出现在响应数据包中。
•0：表示迭代查询• 1：表示递归查询迭代查询和递归查询带来的影响回到为什么DNS不全部使用TCP的问题。
我们可以看到，实际上有很多台服务器参与了DNS请求。
如果使用TCP，则需要三次握手才能建立连接，四次挥手才能断开连接。
对于递归查询端来说，其实还好，因为只会建立一个连接，发送一个请求，接收一个响应，仅此而已。
但对于迭代查询方来说，需要反复与很多服务器建立和断开连接。性能将会产生很大的影响。
这个时候我想大家也会想问。
那是不是意味着TCP连接没有断开，下次可以重用呢？
不太好。
因为大多数URL都涉及不同的域名服务器。例如，www.baidu.com和www.xiaobaidebug.top涉及不同的一级、二级、三级域名服务器。因此，不需要维护TCP长链接。重复利用。
所以相比之下，在数据量较小的场景下，使用UDP可以节省握手和挥手的成本，所以UDP是更好的解决方案。
DNS的IPv4根域只有13个吗？的确。
问题又来了。
为什么是13个IP，不能再加吗？
这纯粹是出于历史原因。上面提到基于UDP的DNS消息不能超过512Byte。排除DNS本身的标头信息，大约可以容纳13个IP（IPV4）。
关于听说DNS根服务器只有13台，科学吗？-dns根服务器为啥13个到此分享完毕，希望能帮助到您。
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/7250.html
用户评论
真的没想过DNS根服务器这么少啊！感觉应该更多多一点才是稳妥的
有11位网友表示赞同！
我觉得数量不多反而更安全一些吧，集中管理更容易维护和防御攻击
有12位网友表示赞同！
13台挺巧合的，是不是有什么特殊含义？
有18位网友表示赞同！
我之前也看过这篇文章，确实很神奇啊。网络这么庞大，竟然只用这么点服务器控制域名解析
有5位网友表示赞同！
感觉跟那些大型公司的核心服务器有点像吧，少数量却非常关键
有5位网友表示赞同！
这么重要的基础设施，想想就觉得压力大！
有11位网友表示赞同！
想问问这些DNS根服务器都是谁管理的？是某个组织还是政府机构吗？
有12位网友表示赞同！
原来DNS解析是这样的运作方式啊，以前从未想过
有5位网友表示赞同！
如果13台服务器出问题的话，整个网络岂不是会瘫痪？！
有13位网友表示赞同！
确实应该加强对这些根服务器的保护，避免遭受攻击
有12位网友表示赞同！
为什么不采用分布式架构呢？这样可以更安全可靠吧
有9位网友表示赞同！
感觉13个还是有点少了，未来网络发展速度这么快
有8位网友表示赞同！
这几个根服务器真的非常重要啊，就像国家的“心脏”一样
有14位网友表示赞同！
有没有想过未来会用到更多类型的DNS根服务器呢？
有14位网友表示赞同！
学习一下这些技术的原理，感觉很有意义！说不定以后有机会自己搭建一个域名解析系统
有13位网友表示赞同！
这篇文章让我对网络基础设施有了更深入的了解
有15位网友表示赞同！
感谢作者分享这篇关于DNS根服务器的信息！
有20位网友表示赞同！
这个话题真是太有意思了，可以引发很多探讨
有9位网友表示赞同！