.int 或者 international 頂級域名或許是互聯網上提供的最“高檔”的一個擴展。子域名的數量太少，根據維基百科的信息，截止 2012 年 6 月，其一共有 166 個子域名。
根據介紹，大約 27 年前，這個域名的主要目的還是爲國際條約組織服務。對 .int 域名的要求列在互聯網數字分配機構（IANA）的網站上，摘錄如下：
必須是各國政府之間締結的一項國際條約。我們應該可以在聯合國的國際條約數據庫中查詢得到，或者你應該給我們一個實際條約的可覈實副本。請確保你提供的是一個條約，而不是某個組織的章程或內部規章細則。我們認識到在
.int頂級域名下的子域名應該是合格的機構，尤其是聯合國的專門機構，這個組織應該在聯合國大會有觀察員地位。
條約必須建立一個組織來提交對.int域名的申請。這個組織必須由條約本身確立，而不是類似理事會等機構的決定。
所建立的組織必須根據國際法主體，被廣泛認爲是具有獨立的國際法律法人。宣言或條約必須創建組織。如果這個組織是由祕書處創建的，它必須要有法人。例如，它必須能夠簽訂合同、成爲法律訴訟的一方。
這些要求都不低，就算某個國家極度渴望，也不可能有單一的國家可以對 .int 域名進行註冊。儘管如此，也有一些例外情況。如 YMCA （基督教青年會）就擁有 .int 域名，由於它在有這些條件限制之前就擁有了這個域名。但是對於未來的組織，想擁有 .int 域名就必須遵守以上條件。
用 dig 對 .int 域名進行 DNS 查詢
我們來看看 .int 頂級域名的 DNS 結構。首先要得到一份 .int 區域文件的拷貝，這份文件將會包含所有現存的 .int 域名的列表和他們的權威服務器。奇怪的是，在維基百科上的 .int 域名列表只有一個引用源和這個鏈接。這個區域文件似乎是準確的，但是爲什麼它託管在一個隨機的域名上，像 statdns.com。他們是怎麼得到的呢？爲了找到答案，我們要調查一下 .int 域名服務器。
所以，讓我們來看看 .int 域名服務器。首先，這些服務器是什麼？
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 域名服務器。這些服務器都知道每個單獨的 .int 域名。那我們爲什麼不向他們請求一個副本？我們可以採用被用於 DNS 域傳送的 AXFR DNS 請求。通常， AXFR 請求只允許從受信任的從服務器向主服務器發起，當從服務器需要複製主服務器的 DNS 信息時。但是，偶然情況下你會幸運地得到一個服務器，這個服務器將會被配置爲允許任何人執行區域傳送（AXFR）請求。使用以下命令，我們可以請求每一個域服務器，從而得到 .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 可以給我們提供相關信息
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...天吶！這樣就可以得到這份列表了，一個頂級域名服務器竟然允許全局 DNS 域傳送。這個服務器剛剛傳遞給我們一份全 .int 域的拷貝。
現在我們有了全部 .int 域名的列表。我們將解析域到一個文件中，然後運行 NS 對其進行查詢，以便知道他們擁有哪個域名服務器。
dig NS -f int_domains.txt
這很有趣，因爲 .int 域名只能由 IANA 創建，但是域名服務器可以設置爲任意域名。在分析完以上的查詢結果後，當請求它的域名服務器時域名 maris.int 返回了狀態碼 SERVFAIL。這在 DNS 請求中是一個很模糊的錯誤，通常意味着在域名的權威域名服務器上出了問題。真奇怪，爲什麼是這些域名服務器？我們將會發起一個 dig 請求來查詢 a.int 域名服務器來找出原因：
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 域名有兩個域名服務器，www.ispo.cec.be 和 cobalt.aliis.be。讓我們來檢查一下第一個域名服務器，看看是否能發現什麼問題。我們可以用 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 查詢來判斷基礎域名是否存在，還是說這只是個子域名。
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顯然基礎域名存在，但是沒有子域名記錄。這個域名服務器的把柄被我們逮到了，對 cobalt.aliis.be 的從屬服務器的全部 DNS 請求都應該失敗。讓我們來看看下一個，我們再次執行一個 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 錯誤。那麼基礎域名呢？
; <<>> 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哇！基礎域名也不存在！但是，等一下，這其實是一個超糟糕的事情，因爲任何人都可以註冊 .be 域名。這意味着，任何人都可以註冊 aliis.be 然後接管 maris.int，因爲 aliis.be 是它的權威解析服務器。正因爲這樣，我們花費 13 美元購買了 aliis.be 域名。我們現在有了 maris.int 的完全控制權，但是更重要的是，我們阻止了其他人爲了自己惡毒的意圖接管它。那我們接下來要做什麼呢？
恢復 maris.int 往日的榮光
maris.int 在他們的域名服務器到期之前做了些什麼？我們可以去 Archive.org 查找存檔。看這個網站肯定有復古的感覺，特別是頁面底部的圖標“使用 Netscape 瀏覽器獲得最佳體驗”。
我們可以使用 Archive 下載器 來得到這個網站的本地副本。我們現在已經有了恢復這個網站的一切！
我們要做的第一件事兒就是設置 aliis.be 的 DNS。我們會爲根域名添加一個 A 記錄，這個根域名指向我們在亞馬遜雲主機上部署的一個實例。我們還將添加一個通配子域名記錄，這個記錄將會重定向全部對子域名的 CNAME 請求到根域名 A 記錄默認的 IP 地址。現在的權威域名解析服務器已經被設置成我們部署的 AWS 實例。下一步我們就要安裝 BIND DNS 服務器並且配置它作爲 maris.int 域的權威主機。然後我們就可以設置全部對 maris.int 子域名的請求都指向 AWS 服務器了。因此，現在任何對 maris.int 的任何請求，包括其子域名，都會被指向我們的服務器。
隨着部署的完成，我們現在可以使用 Python 來重開原始網站（基於 Archive 提供的快照）。
最後，因爲我認爲有些人可能會問發生了什麼？這裏已經是 Archive 對現在我持有的這個網站的快照了。
披露時間線
- 2016.6.10 最初與 [email protected] 發郵件溝通，其允許我們完成對一個 .int 域名的完全託管。一個關於披露責任信息的鏈接和一個我的 PGP 的鏈接被提供出來。
- 2016.6.13 IANA 證實存在問題
- 2016.6.13 和 IANA 溝通協商這個問題
- 2016.6.15 後續與 IANA 的電子郵件溝通一切正常，並且提供了原始報告中不清楚的進一步細節。
- 2016.6.21 IANA 驗證了這個問題，並且指出他們在嘗試與 MARIS 的人進行聯繫。但是這個域名服務器並沒有被改變。
- 2016.7.9 由於自從這個域名被我購買下來後沒有進一步利用的可能性，這個問題已經公開披露。我將會繼續更新這個域名直到漏洞被 MARIS 或 IANA 的人修復（我也將會繼續維護他們的原始網站，除非他們不希望我這樣做），來防止被其他人惡意利用。
對受限制的頂級域名存在的問題思考
一個有趣的人才會擁有一個受限制的頂級域名的想法。.int 頂級域名只是許多有限制的頂級域名之一。許多其他的頂級域名也有限制，如 .gov、.edu、.mil。試圖限制誰可以訪問一個特定的頂級域名的問題，DNS 和網站都建立在指向第三方的基礎上。例如， CNAME 的 DNS 記錄可以被用於將一個子域名指向另一個完全受限的域名（FQDN）。另一個明顯的例子是 NS 的 DNS 記錄也可以指向 FQDN。這就是我們爲什麼可以結果 maris.int。任何一個指向我們限制的頂級域名空間外的域名的 DNS 記錄都會到期，之後可以由第三方註冊。IP 地址也與之類似，你是否把 A 記錄指向了第三方的主機？如果主機提供商突然倒閉了，或者有些人接管了這個 IP，他們就擁有了一個你受限的頂級域名下的子域名或者域名。
更糟的是，你仍然被限制着你的頂級域名空間。你決定全部的 DNS 必須都指向你所擁有的 IP 地址和域名。所以你必須在管理 DNS 和你的頂級域名下的每個域名服務器。你可以防止任何人入侵你的頂級域名空間嗎？聽起來，好像不能。
一旦我們將協議鏈向上移動一個比特，我們就會暴露在網絡風險中。在這些協議水平下，你呈現給你的訪問者的頁面在 example.restrictedtld 並且服務器和 DNS 都在你的控制下。
但是，現在就遇到了一個有趣的問題。網絡的本質也是複雜的。你就不想在 CDN 上拉取一個 JavaScript 腳本嗎？拉取 CSS 和 JavaScript 又有什麼區別呢？所有這些必須都由你自己來管理，否則主機、域名都有可能過期，儘量做到離開你能和你在時一樣。
總而言之，這是一個相當困難的問題，這違背了互聯網內聯的設計。對於一個攻擊者而言，只需要進行少量的研究和掃描就能獲得你受限頂級域名的子域名或者域名的控制，這並不困難 。