説明に使用するドメインなどについて、RFCなどを参照したもののまとめ。
例示ドメイン
RFC 2606「Reserved Top Level DNS Names」
https://www.rfc-editor.org/rfc/rfc2606.html
で規定されています。
トップレベルドメイン(TLD)
まず、予約済みドメインとして以下のように規定されています。
.test
.example
.invalid
.localhost
".test" is recommended for use in testing of current or new DNS
related code.
".example" is recommended for use in documentation or as examples.
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
The ".localhost" TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.
- test
- DNS テスト用
- example
- 文書や例示
- invalid
- オンラインで構築するドメイン
- localhost
- ループバック用に静的に実装
が予約済みとされており、このうち、 example が例示用のTLDとなります。
例示用以外にも、設定テストで使うものとして test や invalid があるので使い分けることになります。
RFC6761 による説明
予約済みTLDについての詳細はRFC6761で説明されています。
「 Special-Use Domain Names」
https://www.rfc-editor.org/rfc/rfc6761
test
6.2. Domain Name Reservation Considerations for "test."
The domain "test.", and any names falling within ".test.", are
special in the following ways:
1. Users are free to use these test names as they would any other
domain names. However, since there is no central authority
responsible for use of test names, users SHOULD be aware that
these names are likely to yield different results on different
networks.
2. Application software SHOULD NOT recognize test names as special,
and SHOULD use test names as they would other domain names.
3. Name resolution APIs and libraries SHOULD NOT recognize test
names as special and SHOULD NOT treat them differently. Name
resolution APIs SHOULD send queries for test names to their
configured caching DNS server(s).
4. Caching DNS servers SHOULD recognize test names as special and
SHOULD NOT, by default, attempt to look up NS records for them,
or otherwise query authoritative DNS servers in an attempt to
resolve test names. Instead, caching DNS servers SHOULD, by
default, generate immediate negative responses for all such
queries. This is to avoid unnecessary load on the root name
servers and other name servers. Caching DNS servers SHOULD offer
a configuration option (disabled by default) to enable upstream
resolving of test names, for use in networks where test names are
known to be handled by an authoritative DNS server in said
private network.
Cheshire & Krochmal Standards Track [Page 7]
RFC 6761 Special-Use Domain Names February 2013
5. Authoritative DNS servers SHOULD recognize test names as special
and SHOULD, by default, generate immediate negative responses for
all such queries, unless explicitly configured by the
administrator to give positive answers for test names.
6. DNS server operators SHOULD, if they are using test names,
configure their authoritative DNS servers to act as authoritative
for test names.
7. DNS Registries/Registrars MUST NOT grant requests to register
test names in the normal way to any person or entity. Test names
are reserved for use in private networks and fall outside the set
of names available for allocation by registries/registrars.
Attempting to allocate a test name as if it were a normal DNS
domain name will probably not work as desired, for reasons 4, 5,
and 6 above.
example
6.5. Domain Name Reservation Considerations for Example Domains
The domains "example.", "example.com.", "example.net.",
"example.org.", and any names falling within those domains, are
special in the following ways:
1. Users SHOULD understand that example names are reserved for use
in documentation.
2. Application software SHOULD NOT recognize example names as
special and SHOULD use example names as they would other domain
names.
3. Name resolution APIs and libraries SHOULD NOT recognize example
names as special and SHOULD NOT treat them differently. Name
resolution APIs SHOULD send queries for example names to their
configured caching DNS server(s).
4. Caching DNS servers SHOULD NOT recognize example names as special
and SHOULD resolve them normally.
5. Authoritative DNS servers SHOULD NOT recognize example names as
special.
6. DNS server operators SHOULD be aware that example names are
reserved for use in documentation.
7. DNS Registries/Registrars MUST NOT grant requests to register
example names in the normal way to any person or entity. All
example names are registered in perpetuity to IANA:
Cheshire & Krochmal Standards Track [Page 10]
RFC 6761 Special-Use Domain Names February 2013
Domain Name: EXAMPLE.COM
Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
Whois Server: whois.iana.org
Referral URL: http://res-dom.iana.org
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 26-mar-2004
Creation Date: 14-aug-1995
Expiration Date: 13-aug-2011
IANA currently maintains a web server providing a web page explaining
the purpose of example domains.
invalid
6.4. Domain Name Reservation Considerations for "invalid."
The domain "invalid." and any names falling within ".invalid." are
special in the ways listed below. In the text below, the term
"invalid" is used in quotes to signify such names, as opposed to
names that may be invalid for other reasons (e.g., being too long).
1. Users are free to use "invalid" names as they would any other
domain names. Users MAY assume that queries for "invalid" names
will always return NXDOMAIN responses.
2. Application software MAY recognize "invalid" names as special or
MAY pass them to name resolution APIs as they would for other
domain names.
3. Name resolution APIs and libraries SHOULD recognize "invalid"
names as special and SHOULD always return immediate negative
responses. Name resolution APIs SHOULD NOT send queries for
"invalid" names to their configured caching DNS server(s).
4. Caching DNS servers SHOULD recognize "invalid" names as special
and SHOULD NOT attempt to look up NS records for them, or
otherwise query authoritative DNS servers in an attempt to
resolve "invalid" names. Instead, caching DNS servers SHOULD
generate immediate NXDOMAIN responses for all such queries. This
is to avoid unnecessary load on the root name servers and other
name servers.
5. Authoritative DNS servers SHOULD recognize "invalid" names as
special and handle them as described above for caching DNS
servers.
Cheshire & Krochmal Standards Track [Page 9]
RFC 6761 Special-Use Domain Names February 2013
6. DNS server operators SHOULD be aware that the effective RDATA for
"invalid" names is defined by protocol specification to be
nonexistent and cannot be modified by local configuration.
7. DNS Registries/Registrars MUST NOT grant requests to register
"invalid" names in the normal way to any person or entity. These
"invalid" names are defined by protocol specification to be
nonexistent, and they fall outside the set of names available for
allocation by registries/registrars. Attempting to allocate a
"invalid" name as if it were a normal DNS domain name will
probably not work as desired, for reasons 2, 3, 4, and 5 above.
localhost
6.3. Domain Name Reservation Considerations for "localhost."
The domain "localhost." and any names falling within ".localhost."
are special in the following ways:
1. Users are free to use localhost names as they would any other
domain names. Users may assume that IPv4 and IPv6 address
queries for localhost names will always resolve to the respective
IP loopback address.
2. Application software MAY recognize localhost names as special, or
MAY pass them to name resolution APIs as they would for other
domain names.
3. Name resolution APIs and libraries SHOULD recognize localhost
names as special and SHOULD always return the IP loopback address
for address queries and negative responses for all other query
types. Name resolution APIs SHOULD NOT send queries for
localhost names to their configured caching DNS server(s).
4. Caching DNS servers SHOULD recognize localhost names as special
and SHOULD NOT attempt to look up NS records for them, or
otherwise query authoritative DNS servers in an attempt to
resolve localhost names. Instead, caching DNS servers SHOULD,
for all such address queries, generate an immediate positive
response giving the IP loopback address, and for all other query
types, generate an immediate negative response. This is to avoid
unnecessary load on the root name servers and other name servers.
Cheshire & Krochmal Standards Track [Page 8]
RFC 6761 Special-Use Domain Names February 2013
5. Authoritative DNS servers SHOULD recognize localhost names as
special and handle them as described above for caching DNS
servers.
6. DNS server operators SHOULD be aware that the effective RDATA for
localhost names is defined by protocol specification and cannot
be modified by local configuration.
7. DNS Registries/Registrars MUST NOT grant requests to register
localhost names in the normal way to any person or entity.
Localhost names are defined by protocol specification and fall
outside the set of names available for allocation by registries/
registrars. Attempting to allocate a localhost name as if it
were a normal DNS domain name will probably not work as desired,
for reasons 2, 3, 4, and 5 above.
セカンドレベルドメイン(SLD)
RFC2606 で指定されていないTLDのうち、以下のセカンドレベルドメインとの組み合わせが例示ドメインとして規定されています。
3. Reserved Example Second Level Domain Names
The Internet Assigned Numbers Authority (IANA) also currently has the
following second level domain names reserved which can be used as
examples.
example.com
example.net
example.org
組み合わせは限定されているので、example.gov などは NGです。
また、 トップレベルドメインが国ドメインになっている場合のセカンドレベルドメインについてはそれぞれの国で管理されていて、RFC2656 で定められているもの以外のものが規定されています。
例えば .jp の場合の例示用セカンドレベルドメインは以下に述べるようなものが存在します。
.jpで使える例示用ドメイン
JPRSで規定されています。
https://jprs.jp/faq/use/
Q
例示に使用可能なドメイン名はありませんか？
A
次の文字列のJPドメイン名は、例示としてご利用いただけます。"EXAMPLE"を用いたもの
例： EXAMPLE.JP
EXAMPLE.CO.JP
EXAMPLE.NE.JP"EXAMPLE"の後に1桁の数字（""0""から""9""）がつく文字列を用いたもの
例： EXAMPLE1.JP
EXAMPLE2.CO.JP
EXAMPLE3.NE.JP次の日本語ドメイン名
ドメイン名例.JP （日本語JPドメイン名）
XN--ECKWD4C7CU47R2WF.JP （「ドメイン名例.JP」のpunycode表記）
例示IPv4アドレス
RFC 5737「IPv4 Address Blocks Reserved for Documentation」
https://www.rfc-editor.org/rfc/rfc5737.html
で規定されています。
3. Documentation Address Blocks
The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),
and 203.0.113.0/24 (TEST-NET-3) are provided for use in
documentation.
- 192.0.2.0/24 (TEST-NET-1)
- 198.51.100.0/24 (TEST-NET-2)
- 203.0.113.0/24 (TEST-NET-3)
これらの扱いについて、インターネット上ではルーティングを行わずパケットフィルターに追加するべきであると記されています。
Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks
SHOULD NOT appear on the public Internet and are used without any
coordination with IANA or an Internet registry [RFC2050]. Network
operators SHOULD add these address blocks to the list of non-
routeable address spaces, and if packet filters are deployed, then
this address block SHOULD be added to packet filters.
These blocks are not for local use, and the filters may be used in
both local and public contexts.
例示ユーザ
ユーザは上記例示ドメインなどと組み合わせてつかうとすればいずれの名前もOKということになります。
それ以外の場合は、具体的なサービスを指して行うのはよくないことになります。
しかしながら gmail での設定の例などではどうしても gmail.com を使ったユーザ名を使った説明をしたいところです。
保証はできませんが、2023/7/12現在において anybody@gmail.com、example@gmail.com は無いようです。