根域名服務器

根域名服務器

簡介

　　根域名服務器（英語：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）	舊名稱	運做單位	設置地點 #數量（全球性/地區性）	軟件
A	198.41.0.4	2001:503:ba3e::2:30	AS26415	ns.internic.net	VeriSign	以任播技術設置於多處 5/0	BIND
B	192.228.79.201 （2004年1月起生效，舊IP地址爲128.9.0.107）	2001:500:84::b	(none)， AS4	ns1.isi.edu	南加州大學信息學研究所	美國加州馬里納戴爾雷伊 0/1	BIND
C	192.33.4.12	2001:500:2::c	AS2149	c.psi.net	Cogent Communications	以任播技術設置於多處 8/0	BIND
D	199.7.91.13 （2013年起生效，舊IP地址爲128.8.10.90）	2001:500:2d::d	AS27	terp.umd.edu	美國馬里蘭大學學院市分校	以任播技術設置於多處 50/67	BIND
E	192.203.230.10	2001:500:a8::e	AS21556	ns.nasa.gov	美國國家航空航天局	以任播技術設置於多處 1/11	BIND
F	192.5.5.241	2001:500:2f::f	AS3557	ns.isc.org	互聯網系統協會	以任播技術設置於多處 57/0	BIND 9
G	192.112.36.4	2001:500:12::d0d	AS5927	ns.nic.ddn.mil	美國國防部國防信息系統局	以任播技術設置於多處 6/0	BIND
H	198.97.190.53 （2015年12月起生效，舊IP地址128.63.2.53）	2001:500:1::53 （2015年12月起生效，舊IP地址爲2001:500:1::803f:235）	AS1508	aos.arl.army.mil	美國國防部陸軍研究所	美國馬里蘭州阿伯丁（Aberdeen） 2/0	NSD
I	192.36.148.17	2001:500:7fe::53	AS29216	nic.nordu.net	瑞典Netnod（曾經Autonomica）	以任播技術設置於多處 41/0	BIND
J	192.58.128.30 （2002年11月起生效，舊IP地址爲198.41.0.10）	2001:503:c27::2:30	AS26415		VeriSign	以任播技術設置於多處 61/13	BIND
K	193.0.14.129	2001:7fd::1	AS25152		荷蘭RIPE NCC	以任播技術設置於多處 5/12	NSD
L	199.7.83.42 （2007年11月起生效，舊IP地址198.32.64.12）	2001:500:9f::42	AS20144		ICANN	以任播技術設置於多處 157/0	NSD
M	202.12.27.33	2001:dc3::35	AS7500		日本WIDE Project	以任播技術設置於多處 6/1	BIND

根域對外提供服務

任播技術

      任播（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。