.int或者 international頂級域名或許是互聯(lián)網(wǎng)上提供的最“高檔”的一個擴展。

子域名的數(shù)量太少，根據(jù)維基百科的信息，截止 2012 年 6 月，其一共有 166 個子域名。根據(jù)介紹，大約 27 年前，這個域名的主要目的還是為國際條約組織服務(wù)。對 .int域名的要求列在互聯(lián)網(wǎng)數(shù)字分配機構(gòu)（IANA）的網(wǎng)站上，摘錄如下：

必須是各國政府之間締結(jié)的一項國際條約。我們應(yīng)該可以在聯(lián)合國的國際條約數(shù)據(jù)庫中查詢得到，或者你應(yīng)該給我們一個實際條約的可核實副本。請確保你提供的是一個條約，而不是某個組織的章程或內(nèi)部規(guī)章細(xì)則。我們認(rèn)識到在.int頂級域名下的子域名應(yīng)該是合格的機構(gòu)，尤其是聯(lián)合國的專門機構(gòu)，這個組織應(yīng)該在聯(lián)合國大會有觀察員地位。條約必須建立一個組織來提交對 .int域名的申請。這個組織必須由條約本身確立，而不是類似理事會等機構(gòu)的決定。所建立的組織必須根據(jù)國際法主體，被廣泛認(rèn)為是具有獨立的國際法律法人。宣言或條約必須創(chuàng)建組織。如果這個組織是由秘書處創(chuàng)建的，它必須要有法人。例如，它必須能夠簽訂合同、成為法律訴訟的一方。

這些要求都不低，就算某個國家極度渴望，也不可能有單一的國家可以對 .int域名進(jìn)行注冊。盡管如此，也有一些例外情況。如 YMCA （基督教青年會）就擁有 .int域名，由于它在有這些條件限制之前就擁有了這個域名。但是對于未來的組織，想擁有 .int域名就必須遵守以上條件。

用 dig 對 .int 域名進(jìn)行 DNS 查詢

我們來看看 .int頂級域名的 DNS 結(jié)構(gòu)。首先要得到一份 .int區(qū)域文件的拷貝，這份文件將會包含所有現(xiàn)存的 .int 域名的列表和他們的權(quán)威服務(wù)器。奇怪的是，在維基百科上的 .int域名列表只有一個引用源和這個鏈接。這個區(qū)域文件似乎是準(zhǔn)確的，但是為什么它托管在一個隨機的域名上，像 statdns.com。他們是怎么得到的呢？為了找到答案，我們要調(diào)查一下 .int域名服務(wù)器。

所以，讓我們來看看 .int域名服務(wù)器。首先，這些服務(wù)器是什么？

mandatory@Matthews-MacBook-Pro-4 ~/Desktop> dig NS int.

;<<>> DiG 9.8.3-P1 <<>> NS int.

;;global options: +cmd

;;Got answer:

;;->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48321

;;flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;;QUESTION SECTION:

;int. IN NS

;;ANSWER SECTION:

int. 16208 IN NS ns.icann.org.

int. 16208 IN NS sec2.authdns.ripe.net.

int. 16208 IN NS ns.uu.net.

int. 16208 IN NS ns0.ja.net.

int. 16208 IN NS ns1.cs.ucl.ac.uk.

;;Query time: 25 msec

;;SERVER: 172.16.0.1#53(172.16.0.1)

;;WHEN: Sat Jun 11 16:43:46 2016

;;MSG SIZE rcvd: 153

看起來，有五個 .int域名服務(wù)器。這些服務(wù)器都知道每個單獨的 .int域名。那我們?yōu)槭裁床幌蛩麄冋埱笠粋€副本？我們可以采用被用于 DNS 域傳送的 AXFR DNS 請求。通常， AXFR 請求只允許從受信任的從服務(wù)器向主服務(wù)器發(fā)起，當(dāng)從服務(wù)器需要復(fù)制主服務(wù)器的 DNS 信息時。但是，偶然情況下你會幸運地得到一個服務(wù)器，這個服務(wù)器將會被配置為允許任何人執(zhí)行區(qū)域傳送（AXFR）請求。使用以下命令，我們可以請求每一個域服務(wù)器，從而得到 .int頂級域名的域文件拷貝。

dig @ns.icann.org. AXFR int.

dig @sec2.authdns.ripe.net. AXFR int.

dig @ns.uu.net. AXFR int.

dig @ns0.ja.net. AXFR int.

dig @ns1.cs.ucl.ac.uk. AXFR int.

在完成查詢之后，事實證明只有 ns1.cs.ucl.ac.uk可以給我們提供相關(guān)信息

mandatory@Matthews-MacBook-Pro-4 ~/Desktop> dig @ns1.cs.ucl.ac.uk. AXFR int.

;<<>> DiG 9.8.3-P1 <<>> @ns1.cs.ucl.ac.uk. AXFR int.

;(1 server found)

;;global options: +cmd

int. 86400 IN SOA sns.dns.icann.org. noc.dns.icann.org. 2016061000 3600 1800 604800 86400

int. 86400 IN NS ns.uu.net.

int. 86400 IN NS ns.icann.org.

int. 86400 IN NS ns0.ja.net.

int. 86400 IN NS ns1.cs.ucl.ac.uk.

int. 86400 IN NS sec2.authdns.ripe.net.

int. 60 IN TXT "$Id: int 5232 2016-06-10 23:02:24Z cjackson $"

ippc.int. 86400 IN NS dnsext01.fao.org.

ippc.int. 86400 IN NS dnsext02.fao.org.

ices.int. 86400 IN NS ns1.hosting2.dk.

ices.int. 86400 IN NS ns2.hosting2.dk.

ices.int. 86400 IN NS ns3.hosting2.dk.

eumetsat.int. 86400 IN NS ns1.p21.dynect.net. ...trimmed for brevity...

天吶！這樣就可以得到這份列表了，一個頂級域名服務(wù)器竟然允許全局 DNS 域傳送。這個服務(wù)器剛剛傳遞給我們一份全 .int域的拷貝。現(xiàn)在我們有了全部 .int域名的列表。我們將解析域到一個文件中，然后運行 NS 對其進(jìn)行查詢，以便知道他們擁有哪個域名服務(wù)器。dig NS -f int_domains.txt這很有趣，因為 .int域名只能由 IANA 創(chuàng)建，但是域名服務(wù)器可以設(shè)置為任意域名。在分析完以上的查詢結(jié)果后，當(dāng)請求它的域名服務(wù)器時域名 maris.int返回了狀態(tài)碼 SERVFAIL。這在 DNS 請求中是一個很模糊的錯誤，通常意味著在域名的權(quán)威域名服務(wù)器上出了問題。真奇怪，為什么是這些域名服務(wù)器？我們將會發(fā)起一個 dig 請求來查詢 a.int域名服務(wù)器來找出原因：

mandatory@Matthews-MacBook-Pro-4 ~/Desktop> dig @ns.icann.org. NS maris.int

;<<>> DiG 9.8.3-P1 <<>> @ns.icann.org. NS maris.int

;(1 server found)

;;global options: +cmd

;;Got answer:

;;->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16832

;;flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;;WARNING: recursion requested but not available

;;QUESTION SECTION:

;maris.int. IN NS

;;AUTHORITY SECTION:

maris.int. 86400 IN NS www.ispo.cec.be.

maris.int. 86400 IN NS cobalt.aliis.be.

;;Query time: 30 msec

;;SERVER: 199.4.138.53#53(199.4.138.53)

;;WHEN: Sat Jun 11 18:02:19 2016

;;MSG SIZE rcvd: 83

由此得知， maris.int域名有兩個域名服務(wù)器，www.ispo.cec.be和 cobalt.aliis.be。讓我們來檢查一下第一個域名服務(wù)器，看看是否能發(fā)現(xiàn)什么問題。我們可以用 dig 做一個快速的 A 記錄查詢來完成需要

mandatory@Matthews-MacBook-Pro-4 ~/Desktop> dig A www.ispo.cec.be

;<<>> DiG 9.8.3-P1 <<>> A www.ispo.cec.be

;;global options: +cmd

;;Got answer:

;;->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32301

;;flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;;QUESTION SECTION:

;www.ispo.cec.be. IN A

;;AUTHORITY SECTION:

cec.be. 1799 IN SOA tclux1.cec.lu. di-cox.cec.eu.int. 2013062501 3600 600 604800 3600

;;Query time: 443 msec

;;SERVER: 172.16.0.1#53(172.16.0.1)

;;WHEN: Sat Jun 11 18:05:36 2016

;;MSG SIZE rcvd: 99

如上面的輸出，我們收到了一個 NXDOMAIN 錯誤。這意味著記錄不存在，我們可以運行另一個 NS 查詢來判斷基礎(chǔ)域名是否存在，還是說這只是個子域名。

mandatory@Matthews-MacBook-Pro-4 ~/Desktop> dig ns cec.be ;<<>> DiG 9.8.3-P1 <<>> ns cec.be

;;global options: +cmd

;;Got answer:

;;->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35109

;;flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 0

;;QUESTION SECTION:

;cec.be. IN NS

;;ANSWER SECTION:

cec.be. 3599 IN NS ns1bru.europa.eu.

cec.be. 3599 IN NS tclux17.cec.eu.int.

cec.be. 3599 IN NS tcbru22.cec.eu.int.

cec.be. 3599 IN NS ns1lux.europa.eu.

cec.be. 3599 IN NS auth00.ns.be.uu.net.

cec.be. 3599 IN NS tclux1.cec.eu.int.

cec.be. 3599 IN NS ns2bru.europa.eu.

cec.be. 3599 IN NS ns2lux.europa.eu.

cec.be. 3599 IN NS auth50.ns.be.uu.net.

cec.be. 3599 IN NS tcbru25.cec.eu.int.

;;Query time: 550 msec

;;SERVER: 172.16.0.1#53(172.16.0.1)

;;WHEN: Sat Jun 11 18:09:28 2016

;;MSG SIZE rcvd: 268

顯然基礎(chǔ)域名存在，但是沒有子域名記錄。這個域名服務(wù)器的把柄被我們逮到了，對 cobalt.aliis.be的從屬服務(wù)器的全部 DNS 請求都應(yīng)該失敗。讓我們來看看下一個，我們再次執(zhí)行一個 A 記錄查詢：

;<<>> DiG 9.8.3-P1 <<>> A cobalt.aliis.be

;;global options: +cmd

;;Got answer:

;;->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51336

;;flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;;QUESTION SECTION:

;cobalt.aliis.be. IN A

;;AUTHORITY SECTION:

be. 599 IN SOA a.ns.dns.be. tech.dns.be. 1015004648 3600 1800 2419200 600

;;Query time: 176 msec

;;SERVER: 172.16.0.1#53(172.16.0.1)

;;WHEN: Sat Jun 11 18:16:10 2016

;;MSG SIZE rcvd: 101

因垂絲汀，這個請求也返回了 NXDOMAIN 錯誤。那么基礎(chǔ)域名呢？

;<<>> DiG 9.8.3-P1 <<>> A aliis.be

;;global options: +cmd

;;Got answer:

;;->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52102

;;flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;;QUESTION SECTION:

;aliis.be. IN A

;;AUTHORITY SECTION:

be. 565 IN SOA a.ns.dns.be. tech.dns.be. 1015004648 3600 1800 2419200 600

;;Query time: 21 msec

;;SERVER: 172.16.0.1#53(172.16.0.1)

;;WHEN: Sat Jun 11 18:16:43 2016

;;MSG SIZE rcvd: 101

哇！基礎(chǔ)域名也不存在！但是，等一下，這其實是一個超糟糕的事情，因為任何人都可以注冊.be域名。這意味著，任何人都可以注冊 aliis.be然后接管 maris.int，因為 aliis.be是它的權(quán)威解析服務(wù)器。正因為這樣，我們花費 13 美元購買了 aliis.be域名。我們現(xiàn)在有了 maris.int的完全控制權(quán)，但是更重要的是，我們阻止了其他人為了自己惡毒的意圖接管它。那我們接下來要做什么呢？

恢復(fù) maris.int往日的榮光

maris.int在他們的域名服務(wù)器到期之前做了些什么？我們可以去 Archive.org查找存檔?？催@個網(wǎng)站肯定有復(fù)古的感覺，特別是頁面底部的圖標(biāo)“使用 Netscape 瀏覽器獲得最佳體驗”。我們可以使用 Archive 下載器來得到這個網(wǎng)站的本地副本。我們現(xiàn)在已經(jīng)有了恢復(fù)這個網(wǎng)站的一切！我們要做的第一件事兒就是設(shè)置 aliis.be的 DNS。我們會為根域名添加一個 A 記錄，這個根域名指向我們在亞馬遜云主機上部署的一個實例。我們還將添加一個通配子域名記錄，這個記錄將會重定向全部對子域名的 CNAME 請求到根域名 A 記錄默認(rèn)的 IP 地址?，F(xiàn)在的權(quán)威域名解析服務(wù)器已經(jīng)被設(shè)置成我們部署的 AWS 實例。下一步我們就要安裝 BIND DNS 服務(wù)器并且配置它作為 maris.int域的權(quán)威主機。然后我們就可以設(shè)置全部對 maris.int子域名的請求都指向 AWS 服務(wù)器了。因此，現(xiàn)在任何對 maris.int的任何請求，包括其子域名，都會被指向我們的服務(wù)器。隨著部署的完成，我們現(xiàn)在可以使用 Python 來重開原始網(wǎng)站（基于 Archive 提供的快照）。

最后，因為我認(rèn)為有些人可能會問發(fā)生了什么？這里已經(jīng)是 Archive 對現(xiàn)在我持有的這個網(wǎng)站的快照了。

披露時間線

2016.6.10 最初與 int-dom@iana.org 發(fā)郵件溝通，其允許我們完成對一個 .int 域名的完全托管。一個關(guān)于披露責(zé)任信息的鏈接和一個我的 PGP 的鏈接被提供出來。

2016.6.13 IANA 證實存在問題

2016.6.13 和 IANA 溝通協(xié)商這個問題

2016.6.15 后續(xù)與 IANA 的電子郵件溝通一切正常，并且提供了原始報告中不清楚的進(jìn)一步細(xì)節(jié)。

2016.6.21 IANA 驗證了這個問題，并且指出他們在嘗試與 MARIS 的人進(jìn)行聯(lián)系。但是這個域名服務(wù)器并沒有被改變。

2016.7.9 由于自從這個域名被我購買下來后沒有進(jìn)一步利用的可能性，這個問題已經(jīng)公開披露。我將會繼續(xù)更新這個域名直到漏洞被 MARIS 或 IANA 的人修復(fù)（我也將會繼續(xù)維護(hù)他們的原始網(wǎng)站，除非他們不希望我這樣做），來防止被其他人惡意利用。

對受限制的頂級域名存在的問題思考

一個有趣的人才會擁有一個受限制的頂級域名的想法。.int 頂級域名只是許多有限制的頂級域名之一。許多其他的頂級域名也有限制，如 .gov、.edu、.mil。試圖限制誰可以訪問一個特定的頂級域名的問題，DNS 和網(wǎng)站都建立在指向第三方的基礎(chǔ)上。

例如， CNAME 的 DNS 記錄可以被用于將一個子域名指向另一個完全受限的域名（FQDN）。另一個明顯的例子是 NS 的 DNS 記錄也可以指向 FQDN。這就是我們?yōu)槭裁纯梢越Y(jié)果 maris.int。任何一個指向我們限制的頂級域名空間外的域名的 DNS 記錄都會到期，之后可以由第三方注冊。

IP 地址也與之類似，你是否把 A 記錄指向了第三方的主機？如果主機提供商突然倒閉了，或者有些人接管了這個 IP，他們就擁有了一個你受限的頂級域名下的子域名或者域名。更糟的是，你仍然被限制著你的頂級域名空間。你決定全部的 DNS 必須都指向你所擁有的 IP 地址和域名。所以你必須在管理 DNS 和你的頂級域名下的每個域名服務(wù)器。你可以防止任何人入侵你的頂級域名空間嗎？聽起來，好像不能。一旦我們將協(xié)議鏈向上移動一個比特，我們就會暴露在網(wǎng)絡(luò)風(fēng)險中。在這些協(xié)議水平下，你呈現(xiàn)給你的訪問者的頁面在 example.restrictedtld并且服務(wù)器和 DNS 都在你的控制下。

但是，現(xiàn)在就遇到了一個有趣的問題。網(wǎng)絡(luò)的本質(zhì)也是復(fù)雜的。你就不想在 CDN 上拉取一個 JavaScript 腳本嗎？拉取 CSS 和 JavaScript 又有什么區(qū)別呢？所有這些必須都由你自己來管理，否則主機、域名都有可能過期，盡量做到離開你能和你在時一樣。總而言之，這是一個相當(dāng)困難的問題，這違背了互聯(lián)網(wǎng)內(nèi)聯(lián)的設(shè)計。

對于一個攻擊者而言，只需要進(jìn)行少量的研究和掃描就能獲得你受限頂級域名的子域名或者域名的控制，這并不困難 。