527.txt

[68] [DFN[[RUBYB[ドメイン]@en[domain]]]]は、[[インターネット]]において[[計算機]]や[[サービス]]を識別する名前として用いられる文字列です。

* ドメイン名とホスト名

[41] 「[DFN[[RUBYB[ホスト名]@en[host name]]]]」と「[[ドメイン名]]」の違いは明確ではありません。
[[RFC 1034]] と [[RFC 1035]] 自体も使い分けられていないと指摘されています [SRC[[[RFC 5890]]]]。
[[IDNA2003]] [SRC[>>39]] や [[IDNA2008]] では特に区別せず、原則的に「[[ドメイン名]]」を使うとしています。

[REFS[
- [39] [CITE@en[RFC 3490 - Internationalizing Domain Names in Applications (IDNA)]] ([TIME[2014-09-14 05:24:23 +09:00]] 版) <http://tools.ietf.org/html/rfc3490#section-2>
- [40] [CITE@en[RFC 6943 - Issues in Identifier Comparison for Security Purposes]]
( ([TIME[2013-11-19 01:20:54 +09:00]] 版))
<http://tools.ietf.org/html/rfc6943#section-3.1>
- [64] [CITE@en[URL Standard]] ([TIME[2015-09-18 15:38:29 +09:00]] 版) <https://url.spec.whatwg.org/#concept-domain>
- [78] [CITE@en[URL Standard]] ([TIME[2016-08-25 16:02:43 +09:00]]) <https://url.spec.whatwg.org/#concept-host-parser>
]REFS]

[42] [[RFC 6943]] は「[[ホスト名]]」の意味は文脈により様々で、次のような用法があると述べています
[SRC[>>40]]。
[FIG(list)[
- [43] [[完全修飾ドメイン名]] ([[FQDN]])
- [44] [[DNS]] で[[番地レコード]]と関連付けられている [[FQDN]]
- [45] [[FQDN]] の[[最左ラベル]]
- [46] [[DNS]] で[[番地レコード]]と関連付けられている [[FQDN]] の[[最左ラベル]]
]FIG]

[47] [[RFC 2965]] は [[FQDN]] のみならず [[IPアドレス]]も[[ホスト名]]と呼んでいます。

;; [[RFC 2109]] はそれを[[完全修飾ホスト名]]と呼んでいました。

[48] [[URL]] では [[authority]] のうち[[userinfo]]と[[ポート]]を除いた部分を[[ホスト]]と呼んでおり、 [[DNS]] の [[FQDN]] に限らず、
不完全な[[ホスト名]]や [[DNS]] 以外で[[解決]]される[[ホスト名]]、
[[IPv4アドレス]]や[[IPv6アドレス]]も含まれています。
[[IPアドレス]]でないものを[[ホスト]]と呼んでおり、
[[ホスト]]と[[ドメイン]]は区別されています。
しかし [[API]] では [CODE(DOMa)@en[[[hostname]]]] が[[ホスト]]を表しており、
[CODE(DOMa)@en[[[host]]]] は [CODE(DOMa)@en[[[hostname]]]] と
[CODE(DOMa)@en[[[port]]]] を組み合わせたものを表しています。
つまり仕様書上の概念と [[API]] とで用語が一貫していません。

[49] [[TLS SNI]] は [[DNS]] の [[FQDN]] で末尾の [CODE[.][末尾の点]] を含まないものを
[DFN[[RUBYB[[[DNSホスト名]]]@en[DNS hostname]]]]と呼んでいます。

** IDNA2003 の定義

[6]

> [[STD 13]] は[DFN[[RUBYB[[[ドメイン名]]] @en[domain name]]]]と[DFN[[RUBYB[[[ホスト名]]] @en[host name]]]]について話していますが、
多くの人はこれらの語を交換可能に用いています。更に、
[[STD 13]] はあまり明瞭ではなかったので、
これらの語それぞれの正確な定義を知っていると思っている多くの人々の間でも定義が食い違っていたりもします。
この[[文書]]では、一般に、[DFN[[RUBYB[[[ドメイン名]]] @en[domain name]]]]という[[用語]]を使います。
[[STD 3]] で定義されている[[ホスト名]]構文の制限に言及する時には、
明示的に [[STD 3]] を[[引用]]します。

;; [[RFC 3490]] 2.

** IDNA2008 の定義

>The base DNS specifications [RFC1034] [RFC1035] discuss "domain
names" and "hostnames", but many people use the terms
interchangeably, as do sections of these specifications.  Lack of
clarity about that terminology has contributed to confusion about
intent in some cases.  These documents generally use the term "domain
name".  When they refer to, e.g., hostname syntax restrictions, they
explicitly cite the relevant defining documents.

;; [21] [CITE@en[RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework]]
<http://tools.ietf.org/html/rfc5890#page-7>

* 構文

[FIG(railroad)[
= [[ラベル]]
= *
== [CODE[.]]
== [[ラベル]]
= ?
== [CODE[.]]
]FIG]

** ASCII ドメイン名の定義

[11]  [SRC[>>12]]
>
[PRE(BNF)[
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
]PRE]

[13] [CODE(BNF)@en[<label>]] については、[[ラベル]]の項を参照してください。

[15] この定義では、 [CODE(example)@en[www.example.com.]] のように [CODE(char)[.][末尾の点]]
で終わるものは [CODE(ABNF)@en[<[[domain]]>]] ではありません。

*** 仕様書

- [18] [CITE@en[RFC 952 - DoD Internet host table specification]]
<http://tools.ietf.org/html/rfc952>
- [12] [[RFC 1034]] <http://tools.ietf.org/html/rfc1034#section-3.5>
- [19] [CITE@en[RFC 1123 - Requirements for Internet Hosts - Application and Support]] 
<http://tools.ietf.org/html/rfc1123#section-2>

** Web での定義

[65] [DFN[[RUBYB[[[ドメイン]]]@en[domain]]]]は、[[ネットワーク]]中の[RUBYB[[[界]]]@en[realm]]を識別するものです
[SRC[>>64]]。

;; [66] 本定義では[[ドメイン]]は[[ホスト]]の一種です。[[ホスト]]には他に
[[IPアドレス]]があります。

[16] [[HTML]] の[[妥当な電子メール・アドレス]]の[[ドメイン名]]部分では、
[CODE(ABNF)@en[[[ldh-str]]]] を [CODE(char)[.][ラベル分離子]] でつなげたものを定義として採用しています。
詳しくは[[妥当な電子メール・アドレス]]の項を参照してください。

[17] この定義は、 >>11 の定義よりも少し緩くて、[[ラベル]]の1文字目に[[数字]]や [CODE(char)[[[-]]]]
が使える点が異なっています。

** HSTS の定義

>
[32] 
:domain name:
is also referred to as "DNS name" and is defined in [RFC1035] to
be represented outside of the DNS protocol itself (and
implementations thereof) as a series of labels separated by dots,
e.g., "example.com" or "yet.another.example.org".  In the context
of this specification, domain names appear in that portion of a
URI satisfying the reg-name production in "Appendix A.  Collected
ABNF for URI" in [RFC3986], and the host component from the Host
HTTP header field production in Section 14.23 of [RFC2616].
>
NOTE:  The domain names appearing in actual URI instances and
matching the aforementioned production components may or
may not be a fully qualified domain name.

[REFS[
- [31] [CITE@en[RFC 6797 - HTTP Strict Transport Security (HSTS)]] ([TIME[2014-06-02 05:16:10 +09:00]] 版) <http://tools.ietf.org/html/rfc6797#section-4>
]REFS]

** IDN での定義

[14] [[国際化ラベル]]を4種類の[[ラベル分離子]] ([[点]]) のいずれかでつなげたものです。[[IDN]] の項を参照。

* 構文解析

[51] [[ホスト構文解析器]]参照。

* レンダリング

[23] [[ASCII文字]]のみからなる[[ドメイン名]]は、[[ラテン文字]]の通常の表記と同じく、 [[ltr]]
に[[レンダリング]]されるのが普通です。[[ラベル]]の順序も[RUBYB[[[ネットワーク順]]]@en[network order]]のまま
[[ltr]] で[[レンダリング]]、つまり[[小エンディアン]]で表記されるのが普通です。

[22] [[ラベル]]に [[rtl]] [[文字]]が含まれる場合、[[ドメイン名]]の一部分が [[rtl]]
に[[レンダリング]]される可能性が生じます。[[ネットワーク順]]が [CODE[ABC.DEF]]
のとき、
[PRE(code example)[
CBA.FED
]PRE]
と
[PRE(code example)[
FED.CBA
]PRE]
... の2種類の[[レンダリング]]が考えられ、どちらも行われているとされています。
このどちらが正しいとも規定はされておらず、[[利用者エージェント]]に委ねられています。
[SRC[>>24]]

** 仕様書

- [24] [CITE@en[RFC 5894 - Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale]] ([TIME[2011-02-05 07:34:29 +09:00]] 版) <http://tools.ietf.org/html/rfc5894#section-4.1>

* ドメイン名の構造

[FIG(short list)[
- [[根ドメイン]]
- [28] [[TLD]]
- [29] [[SLD]]
- [[public suffix]]
- [[ラベル]]
- [[ラベル分離子]]
- [[ドメイン名前空間]]
- [[末尾の点]]
]FIG]

* ドメイン名の分類

[53] [[ドメイン名]]には色々な分類があります。

[FIG(short list)[
- [[FQDN]]
- [[完全修飾ホスト名]]
- [[正準化ホスト名]]
- [[実効ホスト名]]
- [[naked domain]]
- [[伝統的ドメイン名]]
- [[Unicode名]]
- [[内部名]]
- [[代替ルート]]
- [[Registered Domain Name]]
- [[Unregistered Domain Name]]
- [[独自ドメイン]]
]FIG]

[55] [[RFC 6125]] は、[DFN[DNS [RUBYB[ドメイン名]@en[domain name]]]]を次の2つの総称としています
[SRC[>>54]]。
[FIG(list)[
- [56] [RUBYB[[[伝統的ドメイン名]]]@en[traditional domain name]]、
[[STD 13]] [[完全修飾DNSドメイン名]] ([[FQDN]]) すなわちすべての[[ラベル]]が
[[IDNA2008]] [[LDHラベル]]であるもの。
- [57] [[国際化ドメイン名]]、すなわち[[ドメイン名]]の形を取っていて、
[[ラベル]]がすべて [[IDNA2008]] [[NR-LDHラベル]]、[[Aラベル]]、[[Uラベル]]のいずれかであり、
少なくても1つは [[Uラベル]]か[[Aラベル]]であるもの。
]FIG]

[REFS[
- [54] [CITE@en[RFC 6125 - Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)]] ([TIME[2015-03-13 22:27:53 +09:00]] 版) <https://tools.ietf.org/html/rfc6125#section-2.2>
]REFS]

* 特殊なドメイン名

[FIG(short list)[
- [25] [CODE@en[[[localhost]]]]
- [26] [CODE@en[[[localhost.localdomain]]]]
- [27] [CODE@en[[[location.request]]]]
- [CODE[unix/]]
- [CODE[aterm.me]]
]FIG]

;; [50] [[TLD]] も参照。

;; [84] [[節点識別子]]では [CODE[unknown][節点識別子]] という特別な値があり、
[[IPアドレス]]のかわりに使うことができます。ただし、
そもそも[[ドメイン名]]が認められず、かわりに[[難読化識別子]]が求められます。

* 比較と正規化

[33] [[ドメイン名]]の[[比較]]や[[パターン]]の記述には、いくつかの方法があります。

[FIG(short list)[
- [[ASCII大文字・小文字不区別]]
- [[IDNA2003ラベル等価性]]
- [[IDNA2008ラベル等価性]]
- [[ドメイン一致]]
- [[合同一致]]
- [[超ドメイン一致]]
- [[reach]]
- [[クッキー]] [CODE(HTTP)@en[[[Domain]]]] [[属性]]
- [[既知HSTSホストドメイン一致]]
- [[証明書拡張]] [[name constraints]] の [CODE[[[dNSName]]]]
- [[service identity]] に関する一致検査
-- [[ワイルドカード証明書]]の一致検査
-- [[HTTPS]] の [[identity]] の検査
- [CODE[[[shExpMatch]]]] ([[proxy.pac]])
- [[RDAP]] の[[ドメイン名]]のパターン
- [[登録可能ドメイン接尾辞であるか等しい]]
- [[ホストパターン]]
- [CODE[HostMatch]]
]FIG]

[58] [[URL]] の構文解析 (正準化) では、 [[authority]] の[[ドメイン名]]は[[小文字]]に[[正準化]]されます。

;; [[authority]] 参照。

** [CODE[.][ラベル分離子]] から始まるパターンの記述

[79] かつて[[クッキー]]の [CODE(HTTP)@en[Domain]] [[属性]]では、
[DFN[[CODE[.][Domain]]]] から始まる[[ドメイン名]]によって、
[[サブドメイン]]すべてを表すことがありました。

;; [CODE(HTTP)@en[Domain]] 参照。

** ドメイン名自体によるパターンの記述

[80] [[クッキー]]の [CODE(HTTP)@en[Domain]] [[属性]]のように、通常の[[ドメイン名]]の構文で記述し、
当該[[ドメイン]]およびすべての[[サブドメイン]]を表すものとして (定義された[[一致]]演算と共に)
用いられることもあります。

* 操作

[70] [[ドメイン名]]から [[IPアドレス]]等の[[ネットワークアドレス]]を取得する操作を[[名前解決]]、
[[正引き]]などといいます。

[71] [[IPアドレス]]から[[ドメイン名]]を取得する操作を[[逆引き]]といいます。

* 名前の解決

[36] [[ドメイン名]]から[[ネットワークアドレス]]を得る操作を[[名前解決]]といいます。
[[ドメイン名]]は、 [[DNS]] などによって [[IPアドレス]]に変換するのが一般的です。

;; [[名前解決]]参照。

;; [37] [[串]]への接続時や[[メールアドレス]]の記載、[[名前空間]]名の一部としての利用など、
[[名前解決]]せずに[[ドメイン名]]を利用することもよくあります。

* DNS とドメイン名

[69] [[ドメイン名]]は [[DNS]] によって [[IPアドレス]]に[[解決]]するのが一般的ですが、
それだけに限られるわけではありません。歴史的には[[ドメイン名]]は [[DNS]]
より前に存在していました。現在でも[[名前解決]]には [CODE[[[/etc/hosts]]]]
や [[NetBIOS名前解決]]などの [[DNS]] 以外の方法が併用されます。

;; [[名前解決]]参照。

* 名前空間としてのドメイン名

[2] [[DNS]] によって[[解決]]する[[プロトコル]]としての[[ドメイン名]]でなく、
それを流用した[[名前空間]]の[[識別子]]としての[[ドメイン名]]が使われることもあります。

;; [7] [[URL]] の一部として[[名前空間]]に使われる場合については、
[[URL]] を参照。

[20] [[小エンディアン]]より[[大エンディアン]]の方が使いやすいとして、
[[ラベル]]の順序を入れ替えて使うことがあります。詳しくは[[逆ドメイン名]]を参照。

[34] 逆順にしないで使う場面としては次のものがあります。
[FIG(short list)[
- [[Vendor Domain Name]] ([[ヘッダー名]])
- [CODE(822)@en[[[List-ID:]]]]
- [[メッセージID]]
]FIG]

* 文脈

[38] [[ドメイン名]]や[[ホスト名]]は、次の場面で使われます。

[FIG(short list)[
- [[ドメイン名スロット]]
- [[URL]] [[authority]]
- [[項組起源]]
- [[文書のドメイン]]
- [[HTTP]] [CODE(HTTP)@en[[[Host:]]]]
- [[Cookie]] [CODE(HTTP)@en[[[Domain]]]]
- [[TLS SNI]]
- [CODE[[[CN]]]] ([[CN-ID]])
- [CODE@en[[[dNSName]]]]
- [CODE[[[SRVName]]]]
- [CODE@en[[[domainComponent]]]]
- [[電子メールアドレス]]
- [CODE(URI)@en[[[sip:]]]] [[URL]]
- [[メッセージID]]
- [CODE(822)@en[[[List-ID:]]]]
- [[Vendor Domain Name]]
- [[Java]] [[パッケージ名]]
- [CODE(JS)@en[[[document.domain]]]]
- [[逆ドメイン名]]
- [[SOCKS]] の接続先
- [[NAI]]
- [[domainpart]]
- [CODE(URI)@en[tag:]]
- [CODE[+//IDN]]
]FIG]

* 関係者

[61] [[ドメイン名]]には次の関係者が存在しています。
[FIG(short list)[
- [[登録者]]
- [[レジストリ]]
- [[レジストラ]]
- [[CA]]
- [[ICANN]]
]FIG]

* メモ

[3] [[アメリカ]]のドメイン名は国名を省略可能とか説明しているトンデモ本がいまだに存在しているのを知って唖然としましたが。
しかもそれがなんとか検定の教科書だったりするからなんともやるせない。
- [4] [SAMP[組織名.属性.国名]]という階層化がさも世界共通 (で米国が例外) という感じの説明が跡を絶たないのもなんともはや。[[汎用JPドメイン]]が始まってからもずいぶん経つっていうのに。
- [5] >>3-4 米国はインターネット発祥の地、米国慢性という自虐思想だよね、あるいみ。

[8] [CITE@en[RFC 5321 - Simple Mail Transfer Protocol]]
([TIME[2009-09-09 02:12:56 +09:00]] 版)
<http://tools.ietf.org/html/rfc5321#section-4.5.3.1.2>

[9] [CITE[Squid 2.6.STABLE21 Configuration File: allow_underscore]]
([TIME[2008-07-22 05:54:52 +09:00]] 版)
<http://www.squid-cache.org/Versions/v2/2.6/cfgman/allow_underscore.html>

[10] [CITE@en[RFC 6021 - Common YANG Data Types]]
([TIME[2010-10-07 04:53:03 +09:00]] 版)
<http://tools.ietf.org/html/rfc6021>


[30] [CITE@en[RFC 6761 - Special-Use Domain Names]]
( ([TIME[2013-06-27 22:35:13 +09:00]] 版))
<http://tools.ietf.org/html/rfc6761>

[FIG(quote)[
[FIGCAPTION[
[35] [CITE[DeleGate reference manual version 9.9]]
([TIME[2014-09-29 00:34:55 +09:00]] 版)
<http://www.delegate.org/delegate/Manual.htm>
]FIGCAPTION]

> 
> Special names "-"and "-.-", when it is used in the "host:port" part of URL, means the host and port of the DeleGate itself. And URL "http://-.-/-/" is reserved for a entry point of a control page of DeleGate. 
> Another reserved name is "mypro.xyz". An access to "http://mypro.xyz" is interpreted to your proxy server like "http://-.-". If the proxy is chained, you can access to upstream proxies by prefixing the hop count N from your client, as "http://N.mypro.xyz", as "http://2.mypro.xyz" for example. This feature can be enabled or disabled by the HTTPCONF=mypro.xyz parameter.

]FIG]

[FIG(quote)[
[FIGCAPTION[
[52] [CITE[HTTP authentication - The Chromium Projects]]
([TIME[2015-03-21 10:14:33 +09:00]] 版)
<https://www.chromium.org/developers/design-documents/http-authentication>
]FIGCAPTION]

> This list is passed in to Chrome using a comma-separated list of URLs to Chrome via the "auth-server-whitelist" command-line switch.  For example, you can pass in:
> --auth-server-whitelist="*example.com,*foobar.com,*baz"
> which would tell chrome that any URL ending in either 'example.com', 'foobar.com' or 'baz' is in the permitted list.  Without the '*' prefix, the URL has to match exactly.

]FIG]

[FIG(quote)[
[FIGCAPTION[
[59] [CITE@en[RFC 7483 - JSON Responses for the Registration Data Access Protocol (RDAP)]]
([TIME[2015-03-26 07:38:37 +09:00]] 版)
<https://tools.ietf.org/html/rfc7483>
]FIGCAPTION]

>    LDH names:        Textual representations of DNS names where the
>                      labels of the domain are all "letters, digits,
>                      hyphen" labels as described by '''['''RFC5890''']'''.  Trailing
>                      periods are optional.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[60] ([TIME[2014-11-01 05:54:38 +09:00]] 版)
<https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=10>
]FIGCAPTION]

> Domain Name: The label assigned to a node in the Domain Name System.

]FIG]


[62] [CITE@en[Appended period to hostnames can bypass HPKP and HSTS protections — Mozilla]]
([TIME[2015-03-21 03:30:27 +09:00]] 版)
<https://www.mozilla.org/en-US/security/advisories/mfsa2015-13/>

[FIG(quote)[
[FIGCAPTION[
[63] [CITE@en[RFC 4880 - OpenPGP Message Format]]
([TIME[2015-04-05 14:41:03 +09:00]] 版)
<https://tools.ietf.org/html/rfc4880#section-5.2.3.16>
]FIGCAPTION]

> Names in the user namespace consist of a UTF-8 string tag followed by
>    "@" followed by a DNS domain name.  Note that the tag MUST NOT
>    contain an "@" character.  For example, the "sample" tag used by
>    Example Corporation could be "sample@example.com".

]FIG]


[FIG(quote)[
[FIGCAPTION[
[1] [CITE@en[RFC 6762 - Multicast DNS]]
([TIME[2015-03-24 01:44:49 +09:00]] 版)
<https://tools.ietf.org/html/rfc6762#section-16>
]FIGCAPTION]

> However, many Unicast DNS implementers have read these RFCs
>    differently, and argue that the 255-byte limit does include the
>    terminating zero, and that the "Clarifications to the DNS
>    Specification" '''['''RFC2181''']''' statement that "." is the "zero length full
>    name" was simply a mistake.
>    Hence, implementers should be aware that other Unicast DNS
>    implementations may limit the maximum domain name to 254 bytes plus a
>    terminating zero, depending on how that implementer interpreted the
>    DNS specifications.
>    Compliant Multicast DNS implementations MUST support names up to 255
>    bytes plus a terminating zero, i.e., 256 bytes total.

]FIG]


[67] [CITE[Bug 370445 &#8211; Zalewski cookie setting / same-domain bypass vulnerability]] ([TIME[2007-02-17 12:13:53 +09:00]] 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=370445>
([[名無しさん]] [WEAK[2007-02-17 03:15:14 +00:00]])



[FIG(quote)[
[FIGCAPTION[
[72] [CITE@en[RFC 7686 - The ".onion" Special-Use Domain Name]]
([TIME[2015-10-24 08:17:52 +09:00]] 版)
<https://tools.ietf.org/html/rfc7686>
]FIGCAPTION]

> Note that .onion names are required to conform with DNS name syntax
>    (as defined in Section 3.5 of '''['''RFC1034''']''' and Section 2.1 of
>    '''['''RFC1123''']'''), as they will still be exposed to DNS implementations.
> 

]FIG]


[FIG(quote)[
[FIGCAPTION[
[73] [CITE@en[RFC 4282 - The Network Access Identifier]]
([TIME[2015-10-16 10:47:33 +09:00]] 版)
<https://tools.ietf.org/html/rfc4282#section-2.6>
]FIGCAPTION]

> The BNF of the realm portion allows the realm to begin with a digit,
>    which is not permitted by the BNF described in '''['''RFC1035''']'''.  This
>    change was made to reflect current practice; although not permitted
>    by the BNF described in '''['''RFC1035''']''', Fully Qualified Domain Names
>    (FQDNs) such as 3com.com are commonly used and accepted by current
>    software.

]FIG]


[74] [CITE@en[RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format]]
([TIME[2015-12-08 07:08:54 +09:00]] 版)
<https://tools.ietf.org/html/rfc7622>

[75] [CITE@en[Revamp the way document.domain is defined · whatwg/html@2a03759]]
([TIME[2016-02-14 16:32:28 +09:00]] 版)
<https://github.com/whatwg/html/commit/2a03759f2fbf4199d187c046074d574a9ae0e209>

[76] [CITE@en[RFC 952 - DoD Internet host table specification]]
( ([TIME[2016-03-31 08:11:51 +09:00]]))
<https://tools.ietf.org/html/rfc952>

[FIG(quote)[
[FIGCAPTION[
[77] [CITE@en[RFC 7719 - DNS Terminology]]
( ([TIME[2016-06-05 17:09:11 +09:00]]))
<https://tools.ietf.org/html/rfc7719#section-2>
]FIGCAPTION]

>    Domain name:  Section 3.1 of '''['''RFC1034''']''' talks of "the domain name
>       space" as a tree structure.  "Each node has a label, which is zero
>       to 63 octets in length. ... The domain name of a node is the list
>       of the labels on the path from the node to the root of the tree.
>       ... To simplify implementations, the total number of octets that
>       represent a domain name (i.e., the sum of all label octets and
>       label lengths) is limited to 255."  Any label in a domain name can
>       contain any octet value.
> 

]FIG]


[81] [CITE@en[Attempt to explain valid input better]]
([[annevk]]著, [TIME[2017-02-10 17:10:23 +09:00]])
<https://github.com/whatwg/url/commit/50cb9ab9d8f70cc2bc72e91976bfaea0ad0fd330>

[82] [CITE@ja[日本人に馴染みが深い、とんでもなく長いドメイン名 | スラド IT]]
([TIME[2017-03-22 01:41:16 +09:00]])
<https://it.srad.jp/story/09/05/19/0010236/>

[FIG(quote)[
[FIGCAPTION[
[83] [CITE@en-US[Understanding Web Proxy Configuration – IEInternals]]
([TIME[2017-08-26 12:09:37 +09:00]])
<https://blogs.msdn.microsoft.com/ieinternals/2013/10/11/understanding-web-proxy-configuration/>
]FIGCAPTION]

> The Exceptions box allows you to specify what hostnames are configured to bypass the proxy. Beyond hostnames, it supports two special tokens:
> <local> – Matches “plain” hostnames (with no embedded dots)
> <-loopback> – Unmatches localhost, 127.0.0.1 and other “loopback” addresses.
> WinINET defaults to automatically bypassing the proxy for loopback addresses; this token disables that behavior.
> This token impacts WinINET and current versions of WinHTTP; the .NET Framework simply ignores it.

]FIG]