RFC 1591-域名系統的結構和授權

本文的狀態

本文為網路社群提供資訊。本文未指定任何類型的網路標準。本文的散佈不受限制。

1. 前言

本文提供了有關域名系統（DNS）中域名結構的一些資訊，特別是頂級域名和域名管理。網際網路號碼分配局（IANA）是管理國際網際網路中使用IP位址、域名和許多其它參數的機構。分配IP位址、自治系統編號以及大多數頂級和二級域名的日常職責由網際網路位址註冊管理機構（IR）和區域網際網路註冊管理機構處理。

2. 域名結構的頂層

在計算機的域名系統（DNS）命名中，採用層次結構的名稱。系統的根域是沒有名稱的。有一層稱作頂級域名（top-level domain names，TLDs），含通用頂級域名（EDU、COM、NET、ORG、GOV、MIL 和 INT）以及ISO-3166的二位字母國家代碼。其他頂級域名被創建的可能性極小。

在每個頂級域名下可以創建層次結構名稱。通常在通用頂級域名下的結構非常扁平，也就是說許多組織機構直接在頂級域名下註冊，任何頂級域名下一層的結構都會取決於該機構。

在國家頂級域名中，結構形式差異很大，一些國家的國家頂級域名結構非常扁平，而另一些國家則有實質的組織結構。某些國家頂級域名下的二級域名是通用的（例如 AC、CO、GO 和 RE），有一些是基於行政區劃分，還有一些直接將機構名稱列於國家頂級域名之下。RFC 1480文件中描述美國的域名結構。 

通用頂級域名都是由那類別的組織機構所創建的。國家頂級域名（例如，FR、NL、KR、US）均由該國家的管理組織負責。這些管理組織可以進一步委派域名樹的管理職責。這些管理組織是服務公共網際網路社群的角色。通用頂級域名和美國國家頂級域名的描述如下。

在通用頂級域名中，有五個是國際化頂級域名，有兩個僅限於美國實體機構使用。

國際通用頂級域名：

COM – 此域名適用於經濟實體，即企業。這個域名增長得非常龐大，如果持續增長，就要擔心工作管理負載和系統執行效率。正在考慮劃分COM 域名，並且規定將來的經濟實體只允許在其子域中進行註冊。

EDU – 此域最初是為所有教育機構。許多大學、學院、學校、教育服務機構和教育公會都在此域名註冊。最近，決定進一步限制註冊實體為四年制大學和綜合大學。學校和兩年制大學將在國家頂級域名中註冊（參見下面US域名，特別是不滿四年制學校和社區大學）。

NET – 此域名僅提供網路服務供應商的計算機註冊，即NIC和NOC計算機主機、管理計算機和網路節點計算機。網路服務供應商的客戶可以擁有自己的獨立域名（不在NET頂級域名下）。

ORG – 此域名提供不屬於其他通用頂級域名類別的組織。一些非政府組織適合在此域名註冊。

INT – 此域名適用於根據國際公約或國際資料庫建立的組織機構。

僅限美國通用頂級域名：

GOV – 此域名最初用於任何類型的政府部門或機構。最近，決定只有美國聯邦政府的部門才能註冊。州和地方政府部門機構註冊於國家頂級域名中（參見下面US域名）。

MIL – 此域名由美國軍方使用。

國家頂級域名範例：

US – 作為國家頂級域名的範例，US域名基於行政區劃分的基礎提供各類實體機構註冊，即<實體名>.<地區>.<州代碼>.US的層次結構。例如，「IBM.Armonk.NY.US」。此外，提供美國頂級域的域名分支給各州各類實體機構，包括學校（K12）、社區大學（CC）、技術學校（TEC）、州政府部門機構（STATE）、政府委員會（COG）、圖書館（LIB），博物館 （MUS）和其他類型的實體機構（詳見RFC 1480）。

查詢並聯繫頂級域名，請使用「whois」服務存取rs.internic.net主機上的資料庫。附加「-dom」到您感興趣的頂級域名後面。例如：

whois -h rs.internic.net us-dom

或者

whois -h rs.internic.net edu-dom

3. 管理授權

網際網路號碼分配局 (IANA) 負責域名系統 (DNS) 的整體協調和管理，特別是頂級域名這部分的授權。這些頂級域名中的大多數都是取自ISO-3166標準的二位字母國家代碼。

IANA會指定一個網際網路位址註冊管理機構（IR）來處理域名系統的大部分日常管理工作。新的頂級域名（例如國家頂級域名）申請由IR與IANA一同處理協商。國際的中央IR域名是INTERNIC.NET。在COM、EDU、ORG、NET和GOV域名中的二級域向InterNIC註冊。MIL域名中的二級域在NIC.DDN.MIL域名中的DDN註冊。INT域名中的二級域在ISI.EDU域名中的PVM註冊。

雖然新的頂級域名申請都必須發送到InterNIC（hostmaster@internic.net），但區域網際網路註冊管理機構經常會被召集一起管理域名系統，特別是需要解決國家頂級域名管理問題的時候。目前，歐洲網路資訊中心（RIPE NCC）是歐洲的區域網際網路註冊管理機構，亞太網路資訊中心（APNIC）是亞太地區的區域網際網路註冊管理機構，而美國網際網路資訊中心（InterNIC）管理北美以及其他尚未授權的地區。

這些區域網際網路註冊管理機構的聯繫電子信箱是：

InterNIC hostmaster@internic.net

APNIC   hostmaster@apnic.net

RIPE NCC ncc@ripe.net

下面敘述關於建立新的頂級域名時所涉及的策略問題，以及必須將已建立的域，變更管理權從一方更改為另一方的相關問題。

通常創建一個新的頂級域名時，會將其管理權授予一個「指定管理機構」（designated manager）。

當一個子網域被委託時，所有類似的問題都是相關的，下列描述的授權策略內容，同樣可以應用到全網路域名系統命名空間的授權。

要指定一個域名的管理機構，主要條件是它可以承擔必要的職責，並有公平、公正、誠實和稱職的工作能力。

1) 關鍵需求是，每個域都要有一個受指定的管理機構來監督該域的命名空間。在國家頂級域名的情況中，意味著該國家有一個管理機構監督這個域名並營運域名系統。

當然，管理機構必須連接網際網路。使用網際網路協定（IP）連接到名稱伺服器，以及使用電子郵件聯繫其他管理機構和管理人員。

每個域都必須有一個管理聯繫人和一個技術聯繫人。屬於國家頂級域名的管理聯繫人必須居住在其國家內。

2) 這些被指定的權威組織是發配域名的受託人，有服務社群的義務。 

指定的管理機構是國家（在國家頂級域名的情況下）和全球網際網路社群頂級域名的託管人。

託管人只關注在域名的「權利」和「所有權」是不恰當的，應當關心對於網路社群的「責任」和「服務」。

3) 管理機構必須公平對待申請域名的所有組織。

這意味著對所有申請者都應使用相同的規則，所有申請必須以完全公平的方式處理，不論是學術或商業（或其他）性質的用戶都應在平等的基礎上被對待。對於與管理機構有業務往來的申請者，不應認為會有任何特別的待遇。例如，對特定數據網路提供商的客戶沒有優惠。客戶不能要求使用特定的電子信箱系統（或其他應用程式）、協議或產品。

頂級域名的子域所需要的規則並沒有低於頂級域名本身。也就是說，本文中各層級域名的需求關係是息息相關的。特別是所有子域應當被允許營運自己的域名服務，提供子域管理機構認為合適的任何資訊（只要資訊是真實和正確的）。

4) 該領域的利害關係人應同意指定的管理機構是適當的託管人。

IANA通常使競爭關係的各方達成一致的協議，除非在各方都同意的情形之下，否則不會採取行動來改變現況；或在指定管理機構有嚴重不當行為的情況下，IANA才會介入。

然而，利害關係人在選擇指定管理機構時也有一定的發言權。

IANA和中央IR建立一個新的頂級域名，但僅委託出部分的管理權，這可能會發生在以下兩種情況：(1) 競爭的各方無法達成一致；(2) 申請方無法代表或服務整個國家。有時會出現一個國家外的機構試圖幫助這個國家內的網路系統開始運作，這種情況被叫做「代理」域名服務。

由IANA設立的一個委員會，網際網路域名名稱審查委員會（IDNB）將作為一個審查小組負責處理機構間，協調無法達成一致的情況，IDNB的最終決定具有強制執行的效力。

5) 指定的管理機構為所管理域的域名服務工作必須令人滿意。

也就是說，域名分配、委派子域和營運域名服務，這些具體的管理工作必須具備技術能力。包括讓中央IR（在頂級域名的情況下）或其他上層級別的域名管理機構了解域名的狀態，及時回應域名申請，並以準確、耐心和可靠的技術管理資料庫。

管理機構必須有一個主域名伺服器和一個輔助域名伺服器，兩者要具有網際網路IP位址連接，並且易於被IR和IANA檢查運行狀態和資料庫的正確性。

如果域名的運行持續存有問題，則原託管的管理機構將被撤銷委派，並委派給另一個管理機構。

6) 將指定管理機構管理權從原機構轉移到另一個機構時，更高級別的域名管理機構（在頂級域名的情況下為 IANA）必須接收到原機構和新機構之間交流的訊息，以使IANA確保移交管理權的情況是經過雙方同意，且新機構也充分了解職責內容。

此外，IANA接收其他機構間的訊息也是有益的，這些機構可能因為轉移管理權的事務被涉及或影響。 

4. 域名的權力

1) 名稱和商標

如果域名註冊人之間對一特定名稱發生爭議，註冊機構除了提供聯繫資訊給雙方外，沒有其餘義務和責任。

域名註冊時不會顯示任何商標狀態，申請者要自行確認有無侵犯他人商標。

2) 國家代碼

IANA不負責決定與定義某地區是或不是一個國家。

使用ISO-3166內的代碼列表作為國家頂級域名的基礎，因著ISO有相關程序決定那個實體應該或不應該列於該國家代碼列表中。

5. 安全注意事項

本文沒有討論安全問題。

6. 致謝

許多人對本文的草稿版本的描述和程序提供了意見。尤其是Steve Goldstein和John Klensin提供很大的幫助。

7. 作者地址

Jon Postel

SC/Information Sciences Institute

4676 Admiralty Way

Marina del Rey, CA  90292

Phone: 310-822-1511

Fax:   310-823-6714

EMail: Postel@ISI.EDU

8. 參考

[1]   Cooper, A., and J. Postel, “The US Domain”, RFC 1480, USC/Information Sciences Institute, June 1993.

[2]   Reynolds, J., and J. Postel, “Assigned Numbers”, STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.

[3]   Mockapetris, P., “Domain Names – Concepts and Facilities”, STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.

[4]   Mockapetris, P., “Domain Names – Implementation and Specification”, STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[5]   Partridge, C., “Mail Routing and the Domain System”, STD 14, RFC 974, CSNET CIC BBN, January 1986.

[6]   Braden, R., Editor, “Requirements for Internet Hosts — Application and Support”, STD 3, RFC 1123, Internet Engineering Task Force, October 1989.

相關連結：
Postel(1994). Domain Name System Structure and Delegation. datatracker
檢自：
https://datatracker.ietf.org/doc/rfc1591/ (May. 09, 2022)