根域名服务器
根域名服务器
简介
根域名服务器（英语：root name server）是互联网域名解析系统（DNS）中最高级别的域名服务器，负责返回顶级域名的权威域名服务器的地址。截至2014年10月，全球有504台根服务器，被编号为A到M共13个标号。
大部分借由任播（Anycast）技术，编号相同的根服务器使用同一个IP，504台根服务器总共只使用13个IP，因此可以抵抗针对其所进行的分布式拒绝服务攻击（DDoS）。
中国大陆在北京有三台编号为L的镜像，编号为F、I、J的镜像各一台，共6台；香港有编号为D、J的镜像各2台，编号为A、F、I、L的镜像各一台，共8台；台湾则有编号为F、I、J各一台，共3台。
根域文件
所有根域名服务器都是以同一份根域文件返回顶级域名权威服务器（包括通用顶级域和国家顶级域），文件只有550KB[30]大小。截至2004年12月12日，一共记录了258个顶级域和773个不同的顶级域权威服务器。对于没被收录的顶级域，通过根域名服务器是没法查出相应的权威服务器。
顶级域
顶级域分为国家及地区顶级域、通用顶级域、基础建设顶级域(.arpa(用于反向查询))和国际顶级域(IDN)
国家及地区顶级域（Country Code top-level domain,ccTLD）简称国家顶级域，是用两字母的国家或地区名缩写代称的顶级域，其域名的指定及分配，政治因素考量在技术和商业因素之上。这些顶级域均由两个字母组成，大部分使用ISO 3166-1标准。2002年时共有243个国家及地区顶级域。2010年起，互联网号码分配局开始分配国际化国家及地区顶级域，这项改变使得国码域名可以使用当地文字，例如增加了中文国码域名(.中国及.中國、.香港、.台湾及.台灣)，国际化国码域名也不限于两个字（例如.新加坡是三个字）。到2016年4月为止，共有303个国家及地区顶级域。
通用顶级域（英语：Generic top-level domain, gTLD）是互联网名称与数字地址分配机构（IANA）管理的顶级域（TLD）之一。该机构专门负责互联网的域名系统。如.com;.info;.net及.org
域维护
域维护是指通过DNS协议来在主域名服务器和从域名服务器之间维护同一个zone文件。
DNS中有两种域维护手段，一种是全量传输AXFR(full zone transfer)，另一种是增量传输IXFR(incremental zone transfer)。
1．全量传输AXFR
全量传输时，从域名服务器从主域名服务器上请求zone文件，poll的时间间隔由SOA(Start of Authority)记录中的refresh标签定义。请求zone文件的过程是从域名服务器向主域名服务器发送查询来实现，如果主域名服务器中SOA记录中的序列号(serial number标签定义)大于从域名服务器SOA记录的序列号，从域名服务器就会向主域名服务器发送全量传输请求。所以主域名服务器一旦改变了zone文件，则需要增加它该zone中的序列号。整个SOA记录的完整格式见下图：
通常情况下，序列号sn遵循“年+月+日+编号”的格式，如图中的2003080803表示该zone是2003年8月8日的第三次更新。
全量传输时在TCP的53端口上进行。
2．增量传输(IXFR)
传递非常大的zone文件是非常耗资源的（时间、带宽等），尤其是只有zone中的一个记录改变的时候，没有必要传递整个zone文件，增量传输是允许主域名服务器和从域名服务器之间只传输那些改变的记录。
需要注意的是，不是所有的域名服务器都支持增量传输，当不支持增量传输时，主从间就采用全量传输的方式。
3．通告(NOTIFY)
从上面的分析中可以看出，从服务器每隔refresh时间向主服务器发送请求，只有主服务器的SOA中的序列号大于从服务器的序列号才传输，但是如果这个时间间隔比较大的话（比如12个小时），快速变化的网络环境可能不允许有如此大时间的差异。
所以在实现了通告消息的DNS集群中，DNS主服务器的zone文件发生改变后，它立即向从服务器发送一个NOTIFY消息，告诉从服务器我的zone文件发生改变了，接着从服务器马上对比两者的序列号，再采用上面介绍的全量传输或者增量传输的方法请求zone文件。
BIND本身支持通告，通告的配置是在named.conf中的zone中的option中配置，配置指令是notify, also-notify和notify-source，具体见这里。
4．动态更新
每次需要更新zone文件的时候都需要停止域名服务器并重启，这样当zone文件很多的时候域名服务器重启时加载zone文件需要很多的时间。所以需要有一种不停止查询服务而且快速更新zone文件地方机制，这种机制主要有两种：
一种是允许外部进程在服务器运行的时候更新zone文件；
另外一种是将zone中的资源记录RR存储在数据库中，每次查找zone中记录的时候动态读取。
DNS服务器安全
像其他的任何公共服务一样，DNS也会受到各种各样的安全威胁。这节看看DNS服务器会受到什么样的安全威胁？聪明的人们又是怎么应对这些威胁的。
为了了解DNS受到的安全威胁和响应的应对措施，首先需要了解一下DNS的正常数据流。如下图所示：
上图中的每个数据流都会受到响应的安全威胁：
1）zone文件受到的威胁可能有：文件被无意或有意篡改或删除。这种威胁是较好应对的，最主要的方法是制定很好的系统管理策略，zone文件和其他的配置文件需要严格而安全的读写权限。
2）3）动态更新和域传输受到的威胁可能有：未授权的更新、zone文件在传输过程中被篡改（经常是把域名篡改为别的IP）。这种威胁通常的应对方法是TSIG(Transaction SIGnature)策略（这个策略定义在RFC2845中）。TSIG策略中会计算出一个key，这个key是通过单向散列(能轻松地从输入得出值，但很难通过值猜出输入)计算出来的，然后传输zone文件的双方在传输过程中都带上这个key，如果key不对就拒绝传输。
4）5）远程查询受到的威胁可能有：cache污染（IP欺骗、数据拦截或错误的master主机地址）。cache污染是指cache中内容可能将您的域名重定向到了一个错误的服务器。这种威胁通常的应对方法是域名系统安全扩展（DNSSEC, Domain Name System Security Extensions），它是为DNS客户端（解析器）提供的的DNS数据来源，数据完整性验证，但不提供或机密性和认证的拒绝存在扩展集。
服务器列表
全球13组根域名服务器以英文字母A到M依序命名，网域名称格式为“字母.root-servers.org”。其中有11个是以任播技术在全球多个地点设立镜像站。以下信息截至2017年4月26日。其中北京有F/I/J/L,杭州有J。
|
字母 |
IPv4地址 |
IPv6地址 |
（AS-number） |
旧名称 |
运作单位 |
设置地点 |
软件 |
|
198.41.0.4 |
2001:503:ba3e::2:30 |
AS26415 |
ns.internic.net |
以任播技术设置于多处 5/0 |
|||
|
192.228.79.201 |
2001:500:84::b |
(none)， AS4 |
ns1.isi.edu |
||||
|
192.33.4.12 |
2001:500:2::c |
AS2149 |
c.psi.net |
以任播技术设置于多处 |
|||
|
199.7.91.13 |
2001:500:2d::d |
AS27 |
terp.umd.edu |
以任播技术设置于多处 |
|||
|
192.203.230.10 |
2001:500:a8::e |
AS21556 |
ns.nasa.gov |
以任播技术设置于多处 |
|||
|
192.5.5.241 |
2001:500:2f::f |
AS3557 |
ns.isc.org |
以任播技术设置于多处 |
|||
|
192.112.36.4 |
2001:500:12::d0d |
AS5927 |
ns.nic.ddn.mil |
以任播技术设置于多处 |
|||
|
198.97.190.53 |
2001:500:1::53 |
AS1508 |
aos.arl.army.mil |
美国国防部陆军研究所 |
|||
|
192.36.148.17 |
2001:500:7fe::53 |
AS29216 |
nic.nordu.net |
以任播技术设置于多处 |
|||
|
192.58.128.30 |
2001:503:c27::2:30 |
AS26415 |
以任播技术设置于多处 |
||||
|
193.0.14.129 |
2001:7fd::1 |
AS25152 |
以任播技术设置于多处 |
||||
|
199.7.83.42 |
2001:500:9f::42 |
AS20144 |
以任播技术设置于多处 |
||||
|
202.12.27.33 |
2001:dc3::35 |
AS7500 |
以任播技术设置于多处 |
根域对外提供服务
任播技术
任播（anycast）是一种网络定址和路由的策略，使得资料可以根据路由拓扑来决定送到“最近”或“最好”的目的地。
任播是与单播、广播和多播不同的方式。
在单播中，在网络位址和网络节点之间存在一一对应的关系。
在广播和多播中，在网络位址和网络节点之间存在一对多的关系：每一个目的位址对应一群接收可以复制资讯的节点。
在任播中，在网络位址和网络节点之间存在一对多的关系：每一个位址对应一群接收节点，但在任何给定时间，只有其中之一可以接收到传送端来的资讯。
在互联网中，通常使用边界网关协议(Border Gateway Protocol,BGP,)来实现任播。
在过去，任播适合无连线协议（通常建立在用户数据报协议）多于连线导向协议（如会记录状态的传输控制协议）。然而，也有很多情况是传输控制协议使用任播的，包含运载网络如Prolexic使用传输控制协议任播。
因此，任播通常用于提供高可靠性和负载平衡。
边界网关协议
边界网关协议（Border Gateway Protocol, BGP）是互联网上一个核心的去中心化自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统（AS）之间的可达性，属于矢量路由协议。BGP不使用传统的内部网关协议（IGP）的指标，而使用基于路径、网络策略或规则集来决定路由。因此，它更适合被称为矢量性协议，而不是路由协议。
BGP是为了取代外部网关协议（EGP）协议而创建的，允许运行一个完全分散的路由系统，从ARPANET模型的核心路由系统过渡到包括NSFNET骨干网及其相关区域网络的分散系统。这使得互联网成为一个真正的分权制度。自1994年以来，第四版本的BGP在互联网上使用，所有以前的版本现在已经过时不可用。在第4版主要的增强功能是通过支持无类别域间路由和路由聚合来减少路由表的大小。第4版是在早期的 RFC 1771 第4版的基础上编纂，通过20多个草案修改，最终在2006年1月通过形成 RFC 4271。RFC 4271版本纠正了一些错误，澄清模糊之处，带来了更接近工业级应用标准的RFC行业惯例。
大多数互联网服务提供商（ISP）必须使用BGP来与其他ISP创建路由连接（尤其是当它们采取多宿主连接时）。因此，即使大多数互联网用户不直接使用它，但是与7号信令系统（SS7）相比，即通过PSTN的跨供应商核心响应设置协议，BGP仍然是互联网最重要的协议之一。特大型的私有IP网络也可以使用BGP。例如当需要将若干个大型的开放最短路径优先（OSPF）网络进行合并，而开放最短路径优先协议本身又无法提供这种可扩展性时。使用BGP的另一个原因是其能为多宿主的单个ISP（RFC 1998）或多个ISP网络提供更好的冗余网络
DNS查询
DNS中的域名服务器最主要的功能就是响应域名解析器的查询请求（这个域名解析器可能是PC端的解析器，也可能是具有解析功能的另一台域名服务器）。域名解析器是安装在PC端的软件，它负责向本地DNS（local DNS）发起域名解析请求。
DNS系统中有三类查询：
1，递归查询
域名服务器将代替请求的客户机（下级DNS服务器）进行域名查询，如果域名服务器不能直接回答，则域名服务器会在域各树种的各个分支的上下进行递归查询，最终将查询结果返回给客户机，在域名查询期间，客户机始终处于等待状态。递归解析的过程如下图所示：
上图中需要注意的是，许多授权域名服务器都不会提供递归查询的功能（为什么？），比如根域名服务器.和二级域名服务器.com都不提供递归查询的功能，所以真正意义上的递归查询是由Local DNS来完成的。
一般情况下，递归查询的时候会收到以下三种可能的返回结果：
1），一个或若干个A记录，或者带有CNAME链的A记录。A记录即要请求的域名的IP地址，带有CNAME链的A记录就像上一篇博客“DNS开源服务器BIND最小配置详解”里面请求ftp.cobb.com时会先将ftp.cobb.com CNAME到 ljx.cobb.com，然后返回ljx.cobb.com的A记录。
2），一个标示域或主机不存在的错误信息。需要注意的是这个错误信息也可能含有CNAME记录。例如我要请求ftp.cobb.com，而我的域名服务器将ftp.cobb.com CNAME到了ljx.cobb.com，但是ljx.cobb.com这个主机不存在，这个时候就返回CNAME记录和错误信息。
3），暂时性的错误信息。它主要是因为网络不可达该主机，网络不可达不一定表明该主机不存在。
2，迭代查询
域名服务器在返回一些下一次查询的指引或者主机IP地址，域名解析器在收到指引后会再次向这些指引发起查询请求，直到收到主机IP地址。迭代解析的过程如下图所示：
一般情况下，递归查询的时候会收到以下三种可能的返回结果：
1），A记录或者带有CNAME链的A记录。
2），标示域或主机不存在的错误信息。
3），暂时性错误。可能因为网络不可达。
4），可以给出下一步域名解析的域名服务器（包括它的IP地址）的列表。告诉解析器再去哪里进一步解析。
3，反向查询
反向查询是根据一个资源记录查询域名。这个资源记录可能是A记录，CNAME记录或者MX记录（见“DNS开源服务器BIND最小配置详解”）。
为了实现反向查询，DNS中有一个特殊的域名IN-ADDR.ARPA来专门作反向查询定义。详情见RFC3425。
