説明に使用するドメインなどについて、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 は無いようです。