ローカル開発環境用に独自のドメインを用意するなら .local を末尾にしちゃだめ

みゅーとんです. どうも

原因がわからず長期間ハマっていたミスの原因がわかったので, 備忘録として残しておきます。

事象

私のローカル環境では, フロントエンドの Nuxt サーバは port 8001, API は 3000 で立ち上がっています.
ただ, ホスト名に依存した処理が一部存在しているため, reserve-hacomono.local という独自のホストを /etc/hosts に設定し, nginx を使ってNuxt, API それぞれにリクエストを振り分けるような設定をしていました.

これが, どうにもレスポンスが遅すぎて, ストレスになっていました.

原因は初歩的なミス

すごく基礎的なミスなので恥ずかしい限りではあるのですが, 検証用に設定したドメインの末尾が .local であることが原因でした.
なんでこの設定にしたか ? というと, 本当になんとなく, ローカル (手元のPCの意味で) で使うから .local でいっかなーーーくらいの気持ちで設定していました. これ, 予約語だったんですね.

.local について

3 行でまとめると ..

.localは Zeroconf（Zero Configuration Networking）に属する特殊なドメイン名.
mDNS（マルチキャストDNS）を用いて, LAN内の機器を自動で名前解決する仕組みに使われる.
多くの OS では通常の DNS や hosts よりも優先して mDNS に問い合わせが行われる.

開発に使用しているPC は MacBook なので, ZeroConf の実装として Bonjour が標準で組み込まれています.
Bonjour に含まれる mDNSResponder は .local ドメインに対してマルチキャストDNS（mDNS）を使って名前解決を行うよう、OS に登録されています.
そのため .local ドメインを使うと, LAN 内に対する名前探索が優先され, ローカル環境でのレスポンス遅延につながっていたようです。

また, この挙動は RFC6762 MulticastDNS にて定義されていました.

This document specifies that the DNS top-level domain ".local." is a
   special domain with special semantics, namely that any fully
   qualified name ending in ".local." is link-local, and names within
   this domain are meaningful only on the link where they originate.
   This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
   addresses in the FE80::/10 prefix, which are link-local and
   meaningful only on the link where they originate.
   Any DNS query for a name ending with ".local." MUST be sent to the
   mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
   equivalent FF02::FB).  The design rationale for using a fixed
   multicast address instead of selecting from a range of multicast
   addresses using a hash function is discussed inAppendix B.
   Implementers MAY choose to look up such names concurrently via other
   mechanisms (e.g., Unicast DNS) and coalesce the results in some
   fashion.  Implementers choosing to do this should be aware of the
   potential for user confusion when a given name can produce different
   results depending on external network conditions (such as, but not
   limited to, which name lookup mechanism responds faster).

対処

トップレベルドメインの予約語の定義として, RFC 2606 Reserved Top Level DNS Names を見てみると, 以下の記載がありました.

To safely satisfy these needs, four domain names are reserved as
   listed and described below.
                   .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.

つまるところ, この4 種から適切なものを選んでおけば良いみたいですね.
今回のケースだと reserve-hacomono.test としておけばよかったようです.