ホスト名

ドメイン (インターネット)

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

ドメイン名とホスト名

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

[42] RFC 6943 は「ホスト名」の意味は文脈により様々で、次のような用法があると述べています >>40

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

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

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

[49] TLS SNIDNSFQDN で末尾の . を含まないものを DNSホスト名 (DNS hostname) と呼んでいます。

IDNA2003 の定義

[6]

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

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.

構文

  1. ラベル
  2. *
    1. .
    2. ラベル
  3. ?
    1. .

ASCII ドメイン名の定義

[11] >>12

<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>

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

[15] この定義では、 www.example.com. のように . で終わるものは <domain> ではありません。

仕様書

Web での定義

[65] ドメイン (domain) は、ネットワーク中の (realm) を識別するものです >>64

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

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

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

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.

IDN での定義

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

構文解析

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

レンダリング

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

[22] ラベルrtl 文字が含まれる場合、ドメイン名の一部分が rtlレンダリングされる可能性が生じます。ネットワーク順ABC.DEF のとき、

CBA.FED
FED.CBA
... の2種類のレンダリングが考えられ、どちらも行われているとされています。 このどちらが正しいとも規定はされておらず、利用者エージェントに委ねられています。 >>24

仕様書

ドメイン名の構造

ドメイン名の分類

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

[55] RFC 6125 は、DNS ドメイン名 (domain name) を次の2つの総称としています >>54

特殊なドメイン名

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

比較と正規化

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

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

authority 参照。

. から始まるパターンの記述

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

Domain 参照。

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

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

操作

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

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

名前の解決

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

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

DNS とドメイン名

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

名前解決参照。

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

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

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

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

[34] 逆順にしないで使う場面としては次のものがあります。

文脈

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

[85] 逆ドメイン名の用法は逆ドメイン名の項を参照。

関係者

[61] ドメイン名には次の関係者が存在しています。

メモ

[3] アメリカのドメイン名は国名を省略可能とか説明しているトンデモ本がいまだに存在しているのを知って唖然としましたが。 しかもそれがなんとか検定の教科書だったりするからなんともやるせない。

[8] RFC 5321 - Simple Mail Transfer Protocol ( 版) <http://tools.ietf.org/html/rfc5321#section-4.5.3.1.2>

[9] Squid 2.6.STABLE21 Configuration File: allow_underscore ( 版) <http://www.squid-cache.org/Versions/v2/2.6/cfgman/allow_underscore.html>

[10] RFC 6021 - Common YANG Data Types ( 版) <http://tools.ietf.org/html/rfc6021>

[30] RFC 6761 - Special-Use Domain Names ( ( 版)) <http://tools.ietf.org/html/rfc6761>

[35] DeleGate reference manual version 9.9 ( 版) <http://www.delegate.org/delegate/Manual.htm>

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.

[52] HTTP authentication - The Chromium Projects ( 版) <https://www.chromium.org/developers/design-documents/http-authentication>

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.

[59] RFC 7483 - JSON Responses for the Registration Data Access Protocol (RDAP) ( 版) <https://tools.ietf.org/html/rfc7483>

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.

[60] ( 版) <https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=10>

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

[62] Appended period to hostnames can bypass HPKP and HSTS protections — Mozilla ( 版) <https://www.mozilla.org/en-US/security/advisories/mfsa2015-13/>

[63] RFC 4880 - OpenPGP Message Format ( 版) <https://tools.ietf.org/html/rfc4880#section-5.2.3.16>

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".

[1] RFC 6762 - Multicast DNS ( 版) <https://tools.ietf.org/html/rfc6762#section-16>

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.

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

[72] RFC 7686 - The ".onion" Special-Use Domain Name ( 版) <https://tools.ietf.org/html/rfc7686>

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.

[73] RFC 4282 - The Network Access Identifier ( 版) <https://tools.ietf.org/html/rfc4282#section-2.6>

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.

[74] RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format ( 版) <https://tools.ietf.org/html/rfc7622>

[75] Revamp the way document.domain is defined · whatwg/html@2a03759 ( 版) <https://github.com/whatwg/html/commit/2a03759f2fbf4199d187c046074d574a9ae0e209>

[76] RFC 952 - DoD Internet host table specification ( ()) <https://tools.ietf.org/html/rfc952>

[77] RFC 7719 - DNS Terminology ( ()) <https://tools.ietf.org/html/rfc7719#section-2>

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.

[81] Attempt to explain valid input better (annevk著, ) <https://github.com/whatwg/url/commit/50cb9ab9d8f70cc2bc72e91976bfaea0ad0fd330>

[82] 日本人に馴染みが深い、とんでもなく長いドメイン名 | スラド IT () <https://it.srad.jp/story/09/05/19/0010236/>

[83] Understanding Web Proxy Configuration – IEInternals () <https://blogs.msdn.microsoft.com/ieinternals/2013/10/11/understanding-web-proxy-configuration/>

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.