ujued
commented
4 years ago 在最早设计DNS方案时，DNS在互联网以外的其他网络中的应用也被考虑到了，而Class就是用来识别网络的信息。不过，如今除了互联网并没有其他的网络了，因此Class的值永远是代表互联网的IN
Open opencodesp opened 4 years ago
ujued
commented
4 years ago 在最早设计DNS方案时，DNS在互联网以外的其他网络中的应用也被考虑到了，而Class就是用来识别网络的信息。不过，如今除了互联网并没有其他的网络了，因此Class的值永远是代表互联网的IN
DNS如何工作
应用程序在需要知道与之通信的计算机IP时，便会如图1所示，请求想要的信息。
从表现上看，就是客户端问，DNS服务器答，事实上，DNS服务器获取具体记录值时是和分布式系统交互的。
图1中DNS服务器用的什么数据库来保存IP与域名的对应关系，可以防止单点故障又方便扩展呢？事实上，DNS采用了分布式的设计方案！它并不存储这份关系数据，从某种角度看，这个
ISP的本地DNS服务器是使用了DNS的分布式数据库来响应客户端的请求。正如图2所示，这些关系分层次并以分布式的方式分开存储，没有任何一台DNS服务器存储所有关系数据。
暂且略过数据存储。先来谈谈如何对这个分布式层次数据库做数据检索。
图1和图3构成的整个DNS信息查询流程。
图1中的本地
ISP提供的DNS服务器，实质上可以有多台，（考虑到一些缓存策略等因素）离客户端最新的那台服务器如果找不到记录会递归的往上游服务器查找！所以我们说：客户端到本地服务商发起的这次查询为递归查询。当ISP的最上游DNS服务器也没有任何记录时，就会按照图3所示，进行
迭代查询。它首先查询已经配置好的root DNS-Server得到tld DNS-Server信息，再查询tld DNS-Server得到authority DNS-Server信息后，接着再对authority DNS-Server发起DNS查询，这是最后一次查询，如果没找到，则直接给客户端返回DNS Error。这是个层次数据库，是按什么划分层次的呢？
tld是Top Level Domain的缩写，就是用一系列顶级域来划分tld DNS-Server，用客户注册词组划分authority DNS-Server。如netcv.cn，cn即为顶级域，区分顶级域DNS服务器，netcv为用户注册词，区分权威DNS服务器。所以，
root db按顶级域存储了所有tld db主机信息，tld db按用户注册的词组存储了所有authority db主机信息。这样，在上面的迭代查询过程就可以通过域名来定位到最终记录值。那，再说说数据存储。是的，仅有权威DNS服务器存储了最终的域名记录值。
现在有很多域名注册商，承接各种顶级域的域名注册，他们一般都有自己的权威DNS服务器，他们的服务器信息全部存在顶级域DNS服务器中。当用户在域名注册商注册了域名，那该注册商就会请求在顶级域DNS服务器中存储
用户词组与该注册商权威DNS服务器的关系数据。当用户在注册商添加解析记录时，就会在其权威DNS服务器中保存这些解析记录。最终，我要查询
netcv.cn的A记录时，一个最长的DNS查询路径是：DNS请求 --> （本地）DNS服务器 --> root DNS-Server --> tld DNS-Server --> authority DNS-Server --> DNS响应
这是是最长查询路径。一般来说，本地DNS服务器会缓存根DNS服务器和顶级域DNS服务器相关数据。那真实的查询路径可能就会变，一个DNS查询会经本地DNS服务器直接转发到权威DNS服务器，有时，本地DNS服务器会直接返回记录，因为某些域名的查询频率很高。
理论上来说 1) 当有新的顶级域应用时，才需要和根DNS服务器通信获取新的顶级域DNS服务器信息。 2) 当有新的域名注册时才需要和顶级域DNS服务器通信获取新的域名信息。
现实中的DNS
现实中有
13台根域名DNS服务器，每台根域名DNS服务器又有许多镜像，每台顶级域DNS服务器也是有许多镜像，有BGP协议提供的AnyCast机制，可以很快定位到离自己最新的根DNS服务器和顶级域DNS服务器，从而更快的找到记录值。从 https://root-servers.org/ 可以看到这13台根DNS服务器的相关信息和新闻。