875.txt

[32] [DFN[[RUBYB[[[名前解決]]]@en[name resolution]]]]は、[[ドメイン名]]等の名前から[[ネットワーク]]上の[[アドレス]]を得る操作です。
多くの [[OS]] や[[プログラミング言語]]の標準ライブラリー等は、
[[DNSドメイン名]]等から[[IPアドレス]]等を取得できる[[名前解決]]の仕組みを提供しています。

* プロトコル

[11] [[名前解決]]は、 [[OS]]、[[ライブラリー]]、あるいは個別の[[アプリケーション]]のいずれか、あるいはその組み合わせにより実装されており、
その実装方法は様々です。従って同じ環境でも[[アプリケーション]]によって動作が異なることがあります。
[[名前解決]]における [[DNSキャッシュ]] (や [[DNS]] 以外の方法で得られた[[名前解決]]結果の[[キャッシュ]])
の動作も違いがあります。

;; [[DNSキャッシュ]]も参照。なお[[再読み込み]]時には[[DNSキャッシュ]]を回避するような実装もあるようです。

[12] [[名前解決]]には、次のような手段が使われます。どれを使うか、どのような優先順位とするか、
失敗した場合他の方法を試すか、[[キャッシュ]]を適用するかなどは実装により異なります。

[FIG(short list)[
- [[DNS]] ([[DNS解決器]])
- [[mDNS]]
- [CODE(file)[[[/etc/hosts]]]]
- [[NetBIOS名前解決]]
- [[LLMNR]]
- [[NIS]]
]FIG]

;; [51] [[ドメイン名]]のパターンなどにより複数の [[DNS]] サーバーを使い分ける実装もあります。

;; [13] 実装によっては通常と異なる [CODE(file)[[[/etc/hosts]]]] を使えるものもあります。

;; [14] 設定により動作を変更できる実装もあります。

[EG[
[39] 多くの [[Linux]] システムでは既定の状態で [[DNS]] より
[CODE[[[/etc/hosts]]]] が優先されるようになっています。 [[Web開発者]]はしばしば
[CODE[[[/etc/hosts]]]] を書き換えて、実際とは異なるサーバーに接続させ、
開発中のアプリケーションの動作を確認することがあります。
中にはこの標準的な動作とは異なる実装もありますが [SRC[>>7]]、
そうした使い方ができないため、不評です [SRC[>>8]]。
]EG]

[15] 入力として [[IPアドレス]] (のようなもの) を与えた場合、 [[IPアドレス]]として解釈した結果を返す実装もあります。
[[十六進数]]表記の [[IPv4アドレス]]など、標準的でない [[IPアドレス]]の指定方法を認めている実装もあります。
[[URL]]の[[ホスト]]など、[[ドメイン名]]と[[IPアドレス]]のいずれかを指定できる文脈もよくあるので、
どちらが入力でも適当な結果が返される方が便利そうです。

[16] [[IDN]] に対応する実装もあります。

;; [17] [[IDN]] の [[RFC]] の趣旨に従うなら[[アプリケーション]]側で[[Aラベル]]に変換してから[[名前解決]]するべきなのでしょうが、
[[DNS]] 以外の方法で[[名前解決]]する可能性を考慮すると、[[名前解決]]側で処理するのが適切にも思われます。
[[RFC 6055]] も[[アプリケーション]]ではなく[[名前解決]]ライブラリー側で変換するのが好ましいとしています。

[20] 解決する名前のパターンその他で解決方法を切り替えたり、 [[Aラベル]]への変換を行うかどうか決定したり、
[[DNSサーバー]]を切り替えたりする実装や設定もあります。

[21] [[名前解決]]や [[DNS]] の実装によっては、指定された通りの名前を解決するだけでなく、
指定された名前の後に予め設定された文字列
(所属するネットワークに割り振られた[[ドメイン名]]など) を結合した名前を解決しようとすることがあります。
所属ネットワークの[[ドメイン名]]を省略した[[ホスト名]] ([[計算機名]])
のみで名前解決できるようにするために用意されている機能です。
解決したい名前の末尾に[[根ドメイン]]を表す [CODE[.][末尾の点]]
([[末尾の点]]) を明記することでこの挙動を防ぐことができるとされています
(が、実際の挙動は、実装によって異なっています)。

[22] いわゆる [[alternative root]] の他、組織内ネットワーク等の 
[[DNSサーバー]]を用いて一部または全部の名前を解決するように設定されていることがあり、
その場合[[インターネット]]の [[DNS]] 
で用いられている[[ドメイン名]]の体系に属さない[[ドメイン名]]で[[名前解決]]されることがあります。

[EG[
[38] たとえば Example 社の社内ネットワークの [[DNSサーバー]]には、 [CODE[main.x]] や
[CODE[printer.x]] の [CODE[x]] のような独自の [[TLD]] が存在するかもしれません。
]EG]

[25] [[DNSラウンドロビン]]の実装方法や [[IPv4]] と [[IPv6]] の選択など、
[[DNS解決器]]の実装の詳細や動作モードにも様々なバリエーションがあります。

* 出力

[28] 名前解決が成功した場合は、アドレスが返されます。一般的には、 [[IPv4アドレス]]または
[[IPv6アドレス]]が返されます。

[29] [[DNSラウンドロビン]]などで複数のアドレスが得られた場合、
アドレスのリストが返される実装もあります。

[47] 通常は[[ユニキャストアドレス]]が返されることが期待されていますが、
[[DNS]] 等が[[ブロードキャストアドレス]]や[[マルチキャストアドレス]]、
あるいは特殊なアドレスを返す可能性もあります。

[48] 広く[[インターネット]]からアクセス可能な[[アドレス]]が返されることもあれば、
私的なネットワーク内のみで通用するアドレスのこともあります。

;; [49] 公的な[[ドメイン名]]から私的な[[アドレス]]が返されることを防ぎたい場合もあるかもしれませんが、
一般的な [[OS]] 等の名前解決器はそのような機能を提供していないので、
[[アプリケーション]]側で個別に実装する必要があります。

[50] [CODE[[[127.0.53.53]]]] は、失敗とみなされることがあります。

;; [CODE[[[ICANN_NAME_COLLISION]]]] 参照。

[60] [[DNS]] では、 [CODE[CNAME]] によって[[名前]]に対応する[[アドレス]]を他の[[名前]]によって間接的に記述することができますが、
普通、[[名前解決]]は、それを更に[[解決]]して最終的に得られた[[アドレス]]を返します。
[[アプリケーション]]側は中間の[[名前]]にはアクセスできず、
諸操作に中間の[[名前]]を使うこともありません。

[EG[
[61] [[HTTPリダイレクト]]があると、最終的な[[応答]]の [[URL]]
は、[[リダイレクト]]の指示に従って書き換わった結果の [[URL]] となります。
それとは違って、 [CODE[CNAME]] が使われていても、大元の[[ドメイン名]]がそのまま[[応答]]の
[[URL]] に使われ、書き換わることはありません。
]EG]

[30] [[OS]] 等が提供する名前解決では、 [[DNS]] における [[TTL]] など名前に付随するその他の情報にはアクセスできないのが一般的です。
これを理由にアプリケーション側で独自に名前解決を実装することもあります。

[31] 名前解決は失敗することがあります。アプリケーションは失敗時の処理も実装しておく必要があります。

* プロキシによる間接的名前解決

[9] [[SOCKS]] では接続先として[[IPアドレス]]ではなく[[ドメイン名]]を指定することもできますので、
これは[[名前解決]]を [[SOCKS]] [[サーバー]]に委ねていることになります。

[10] [[絶対URL]]による [[HTTP要求]]や [[HTTP]] [CODE(HTTP)@en[[[CONNECT]]]] 
では接続先の[[ホスト]]を[[要求対象]]として指定することになるので、
[[名前解決]]を [[HTTPサーバー]] ([[串]]) に委ねていることになります。

[52] 組織内ネットワークの[[ドメイン名]]を [[SOCKS]]5 プロキシ経由でアクセスするべき場合のように、
当該システムにおいて通常の [[DNS]] などでは[[名前解決]]できないものが使われることもあります。

[23] [[Tor]] の [CODE[[[.onion]]]] のように、 [[DNS]] 等通常の方法で[[名前解決]]することは想定せず、
[[SOCKS]] など[[串]]を通した[[名前解決]]に限って用いられる[[ドメイン名]]も存在します。

;; [24] そのような[[ドメイン名]]であっても [[URL]] の [[authority]] に使われるなど、
[[名前解決]]以外の使われ方では通常の[[ドメイン名]]と区別がつきません。

;; [92] 通常の [[DNS]] への[[情報漏洩]]を避けるため、そうした [[TLD]]
の[[ドメイン]]の[[名前解決]]が必ず失敗し、外部に[[解決]]を委ねない実装もあります。

[27] こうした形の間接的な[[名前解決]]では、[[クライアント]]は解決結果のアドレスを知ることはできませんし、その必要もありません。
([[クライアント]]が直接アクセスできないアドレスに解決されている可能性も強いです。)

[53] [[プロキシ]]による接続と通常の[[名前解決]]が混在すると、
意図しない動作を引き起こすかもしれません。

[EG[
[54] 例えば、[[プロキシ]]による[[名前解決]]と [[DNS prefetch]]
を併用すると、おかしなことが起こるかもしれません。
]EG]

* 解決時間

[33] [[名前解決]]は、 [[DNS]] 等ネットワークにより問い合わせる場合には相応の時間を必要とします。
そのためアプリケーションの処理内容や解決する名前の量によっては、
できるだけ名前解決が発生するのを避けるべきとされていることもあります。

[35] [[DNS Prefetching]] のような、必要になりそうな[[名前解決]]を予め行い結果を[[キャッシュ]]する仕組みが利用されることもあります。

* Web における名前解決

[56] [[Web]] では[[名前解決]]は透過的に行われ、[[著者]]に[[順引き]]や[[逆引き]]などの
[[API]] は提供されていません。

[57] [[WebSocket接続の確立]]では同時接続数の制限に[[名前解決]]結果が使われています。

* 文脈

[43] 次の場面で[[名前解決]]が行われます。
[FIG(short list)[
- [[HTTP接続]]
- [[WebSocket接続の確立]]
- [CODE(HTML)@en[dns-prefetch]]
]FIG]

* セキュリティー

[44] [[DNSSEC]] を使う場合や組織内の [[DNSサーバー]]に組織内ドメインの[[名前解決]]を委ねた場合、
[CODE[[[/etc/hosts]]]] を使う場合など[[名前解決]]の結果が「正しい」
ことを保証できる場合もあれば、一般の[[インターネット]]の [[DNS]]
[[ドメイン名]]の解決の場合のように、(通信路上または [[DNS]] 等のサーバーにおいて)
攻撃者に結果を改竄される可能性を排除できない場合もあります。

[45] [[TLS]] + [[サーバー証明書]]の [[service identity]] 検証のように、
用途に応じた適切な手段で解決結果と通信相手が「正しい」
ことを別途確認する必要があるかもしれません。

[55] [[DNS rebinding]] のように[[名前解決]]を操作することによる攻撃も存在します。
[[サーバー]]は、自身の意図する[[名前]]でのみ[[クライアント]]がアクセスして来ることが保証されていませんから、
[[SNI]] や [CODE(HTTP)@en[Host:]] の検証などを通してこれを検査する必要があります。

;; [[実効要求URL]]も参照。

* 実装

[80] [[Chrome]] は [[OS]] の[[名前解決]]を使うのをやめて独自実装に切り替えましたが、
その過程で相当数の不具合報告を受け取っており、いくつかは未だ解消していないようです。
[[OS]] の[[名前解決]]処理は明文化されていない部分が相当に複雑で再実装困難なようです。

[FIG(quote)[
[FIGCAPTION[
[1] [CITE@en[Windows 名前解決の順序 - Ask the Network & AD Support Team - Site Home - TechNet Blogs]]
([TIME[2015-03-21 19:13:48 +09:00]] 版)
<http://blogs.technet.com/b/jpntsblog/archive/2009/07/13/windows.aspx>
]FIGCAPTION]

> 
> 1) DNS リゾルバーキャッシュ (*1) を確認して、指定された名前に対応するレコードがキャッシュされている場合は、そのアドレスを返します。 
> 2) HOSTSファイル (*2) を参照し、指定された名前に対応するレコードが登録されている場合はそのアドレスを返します。 
> 3) 登録されている DNS サーバーに問い合わせを行い、受領したアドレスを返します。 
> 4) 上記 1 ~ 3 で名前解決に成功しない場合は、NetBIOS 名前解決を行います。 

]FIG]


[2] [CITE@en-us[Microsoft TCP/IP のホスト名解決の順序]]
([TIME[2015-03-21 19:15:29 +09:00]] 版)
<https://support.microsoft.com/en-us/kb/172218/ja>

[3] [CITE@ja[Microsoft ネットワークを解剖する 第1回「NetBIOSでの通信と名前解決の仕組み」 -- Microsoftネットワークの混迷 --]]
([TIME[2006-07-12 00:00:19 +09:00]] 版)
<http://www.monyo.com/technical/windows/msnet/msnet1.html>

[FIG(quote)[
[FIGCAPTION[
[4] [CITE[Postfix Configuration Parameters]]
([TIME[2015-02-08 21:38:00 +09:00]] 版)
<http://www.postfix.org/postconf.5.html#smtp_host_lookup>
]FIGCAPTION]

> smtp_host_lookup (default: dns)
> :dns:Hosts can be found in the DNS (preferred).
> :native:Use the native naming service only (nsswitch.conf, or equivalent mechanism).
> :dns, native:Use the native service for hosts not found in the DNS.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[5] [CITE[Man page of NSSWITCH.CONF]]
([TIME[2015-02-06 06:34:01 +09:00]] 版)
<http://linuxjm.sourceforge.jp/html/LDP_man-pages/man5/nsswitch.conf.5.html>
]FIGCAPTION]

> ネームサービススイッチ (Name Service Switch; NSS) の設定ファイル /etc/nsswitch.conf は、 GNU C ライブラリが いろいろなカテゴリーの名前サービス情報を、どの情報源から どの順序で取得するかを判断するのに使用される (情報の各カテゴリーはデータベース名で識別される)。

]FIG]


[6] [CITE@en[Check /etc/hosts first · Issue #2 · potyl/perl-AnyEvent-CacheDNS]]
([TIME[2015-03-21 19:25:21 +09:00]] 版)
<https://github.com/potyl/perl-AnyEvent-CacheDNS/issues/2>

[FIG(quote)[
[FIGCAPTION[
[7] [CITE[AnyEvent::Socket - search.cpan.org]]
([TIME[2015-03-21 19:26:56 +09:00]] 版)
<http://search.cpan.org/dist/AnyEvent/lib/AnyEvent/Socket.pm>
]FIGCAPTION]

> For internet addresses, $node is either an IPv4 or IPv6 address, an internet hostname (DNS domain name or IDN)
> If a host cannot be found via DNS, then it will be looked up in /etc/hosts (or the file specified via $ENV{PERL_ANYEVENT_HOSTS}). If they are found, the addresses there will be used. The effect is as if entries from /etc/hosts would yield A and AAAA records for the host name unless DNS already had records for them.
> For UNIX domain sockets, $node must be the string unix/

]FIG]


[FIG(quote)[
[FIGCAPTION[
[8] [CITE@en[dex4er/perl-AnyEvent-DNS-EtcHosts]]
([TIME[2015-03-21 19:31:10 +09:00]] 版)
<https://github.com/dex4er/perl-AnyEvent-DNS-EtcHosts>
]FIGCAPTION]

> AnyEvent::DNS::EtcHosts changes AnyEvent::DNS behavior. The /etc/hosts file is searched before DNS, so it is possible to override DNS entries.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[18] [CITE@ja[idn wrapper - JPNIC]]
([[Japan Network Information Center]] 著, [TIME[2015-03-21 20:33:19 +09:00]] 版)
<https://www.nic.ad.jp/ja/idn/mdnkit/download/documents/idnkit-1.0pr1-doc/ja/guide/wrapper.html>
]FIGCAPTION]

> Windows では、DNS だけではなく、WINSやLMHOSTS によってもドメイン名、 ホスト名の解決が行われます。 idn wrapper を使った場合には、これらのすべての方式について、 国際化ドメイン名への対応のためのエンコーディング変換が行われることになります。
> このため、Windows が、WINSやLMHOSTS を使っている場合には、予期しない 問題が発生する可能性があります。 idn wrapper を使う場合には、名前解決にDNS だけを使用することをお勧めします。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[19] [CITE@ja[<idn> 要素 (Uri 設定)]]
([TIME[2015-03-21 20:34:42 +09:00]] 版)
<https://msdn.microsoft.com/ja-jp/library/bb882553(v=vs.110).aspx>
]FIGCAPTION]

> idn enabled = AllExceptIntranet
> この値は、ローカルなイントラネット以外のすべての Unicode ドメイン名を、等価の Punycode (IDN 名) を使用するように変換します。 このように、ローカルなイントラネットで国際名を処理する場合、このイントラネットで使用する DNS サーバーは Unicode の名前解決をサポートしている必要があります。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[26] [CITE[Network Stack - The Chromium Projects]]
([TIME[2015-03-21 10:14:33 +09:00]] 版)
<https://www.chromium.org/developers/design-documents/network-stack>
]FIGCAPTION]

> Note that, as of time of writing, we cap the number of concurrent host resolutions to 8, but are looking to optimize this value.  HostResolverImpl also contains a HostCache which caches up to 1000 hostnames.

]FIG]

* 相互運用性

[40] [[名前解決]]は各システムやその所属する[[ネットワーク]]の様々な事情の影響を受けるため、
明確な標準が存在せず、様々な実装や設定が存在しています。
[[インターネット]]の [[DNS]] の [[LDHラベル]]のみで構成される一般的な[[ドメイン名]]のみを使う限りは問題はほとんど起こりませんが、
それ以外の、少しでも特殊な事情のある名前の解決は、しばしば問題を引き起こします。

[41] [[名前解決]]の問題は個別システムの事情で標準化に馴染まないとの考え方もありますが、
実際にはネットワークアプリケーションの[[相互運用性]]に関わる重要な要素の1つです。
例えば [[URL]] は [[authority]] で[[ドメイン名]]を使っていますから、
それがどう[[解決]]されるかは [[Web]] の根幹に関わります。

[EG[
[42] [[Web]] のセキュリティーモデルである[[同一起源ポリシー]]は、 [[URL]]
の[[ホスト]]などをセキュリティー上のグループ単位に使っています。
[[ドメイン名]]がどう解決されるかが特定システム上で一貫している必要があるのはもちろん、
[[サーバー]]と[[クライアント]]の間でも共通に理解される必要があります。
]EG]

[EG[
[62] [[PKIX]] に従い[[発行]]された[[証明書]]を使った [[service identity]]
の検証は、現在[[インターネット]]全体で標準的に用いられている [[DNS]]
による[[名前解決]]で運用されている[[ドメイン名]]体系を前提としています。
]EG]

* 関連

[34] [[名前]]から[[アドレス]]への変換を[[正引き]]、[[アドレス]]から[[名前]]への変換を[[逆引き]]と呼ぶことがあります。

* 歴史

** IDNA2003

[83] [[DNS]] の[[解決]]を行う[[ソフトウェア・コンポーネント]]を[DFN[[RUBY[解決器][リゾルバー]@en[resolver]]]]といいます。

[REFS[
- [84] [[IDNA2003]] [CITE@en[RFC 3490 - Internationalizing Domain Names in Applications (IDNA)]] 
<https://tools.ietf.org/html/rfc3490#section-6.2>
]REFS]

[FIG(quote)[
[FIGCAPTION[
[86] 
]FIGCAPTION]
>
Applications normally use functions in the operating system when they
resolve DNS queries.  Those functions in the operating system are
often called "the resolver library", and the applications communicate
with the resolver libraries through a programming interface (API).
]FIG]

[85] 旧来の[[リゾルバー・ライブラリー]]は [[ASCIIドメイン名]]を想定しているので、[[IDNA]]
対応[[アプリケーション]]は [[ToASCII]] [[演算]]により [[ASCII]]
に変換する準備をし[['''なければなりません''']]。 [SRC[>>84]]

[87] 新しい[[リゾルバー・ライブラリー]]は[[非ASCII文字]]に対応し、
[[ToASCII]] や [[ToUnicode]] を[[ライブラリー]]の内部で行うことが想定されています [SRC[>>84]]。

[88] [[リゾルバー・ライブラリー]]に渡したり、 [[DNS]] [[要求]]で [[question section]]
に入れたりする[[ドメイン名]]は、 [[Stringprep]] における[[照会文字列]]の規則に従います
[SRC[>>84]]。

** IDNA2008

[REFS[
- [90] [[IDNA2008]] [CITE@en[RFC 5890 - Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework]] 
<https://tools.ietf.org/html/rfc5890#section-2.2>
]REFS]

[91] 「[DFN[lookup]]」は、[[IDNA2008]] によって行われる[[演算]]と [[DNS解決器]]によって行われるものの全体を指します
[SRC[>>90]]。

**

[36] [CITE@en[RFC 6055 - IAB Thoughts on Encodings for Internationalized Domain Names]]
([TIME[2015-04-26 07:31:45 +09:00]] 版)
<https://tools.ietf.org/html/rfc6055#page-6>

[FIG(quote)[
[FIGCAPTION[
[37] [CITE@en[RFC 6055 - IAB Thoughts on Encodings for Internationalized Domain Names]]
([TIME[2015-04-26 07:31:45 +09:00]] 版)
<https://tools.ietf.org/html/rfc6055#section-4>
]FIGCAPTION]

> It is inappropriate for an application that calls a general-purpose
>    name resolution library to convert a name to an A-label unless the
>    application is absolutely certain that, in all environments where the
>    application might be used, only the global DNS that uses IDNA
>    A-labels actually will be used to resolve the name.
>    Instead, conversion to A-label form, or any other special encoding
>    required by a particular name-lookup protocol, should be done only by
>    an entity that knows which protocol will be used (e.g., the DNS
>    resolver, or getaddrinfo() upon deciding to pass the name to DNS),
>    rather than by general applications that call protocol-independent
>    name resolution APIs.  (Of course, applications that store strings
>    internally in a different format than that required by those APIs,
>    need to convert strings from their own internal format to the format
>    required by the API.)  Similarly, even if an application can know
>    that DNS is to be used, the conversion to A-labels should be done
>    only by an entity that knows which part of the DNS namespace will be
>    used.
>    That is, a more intelligent DNS resolver would be more liberal in
>    what it would accept from an application and be able to query for
>    both a name in A-label form (e.g., over the Internet) and a UTF-8
>    name (e.g., over a corporate network with a private namespace) in
>    case the server only recognizes one.  However, we might also take
>    into account that the various resolution behaviors discussed earlier
>    could also occur with record updates (e.g., with Dynamic Update
>    '''['''RFC2136''']'''), resulting in some names being registered in a local
>    network's private namespace by applications doing conversion to
>    A-labels, and other names being registered using UTF-8.  Hence, a
>    name might have to be queried with both encodings to be sure to
>    succeed without changes to DNS servers.
>    Similarly, a more intelligent stub resolver would also be more
>    liberal in what it would accept from a response as the value of a
>    record (e.g., PTR) in that it would accept either UTF-8 (U-labels in
>    the case of IDNA) or A-labels and convert them to whatever encoding
>    is used by the application APIs to return strings to applications.

]FIG]

[46] [CITE[Manpage of GETHOSTBYNAME]]
( ([TIME[2010-04-25 12:26:43 +09:00]] 版))
<http://archive.linux.or.jp/JM/html/LDP_man-pages/man3/gethostbyname.3.html>

[FIG(quote)[
[FIGCAPTION[
[58] [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]

> 
>    3.  Name Resolution APIs and Libraries: Resolvers MUST either respond
>        to requests for .onion names by resolving them according to
>        '''['''tor-rendezvous''']''' or by responding with NXDOMAIN '''['''RFC1035''']'''.

]FIG]


[FIG(quote)[
[FIGCAPTION[
[59] [CITE@en[RFC 7542 - The Network Access Identifier]]
([TIME[2015-10-18 15:17:56 +09:00]] 版)
<https://tools.ietf.org/html/rfc7542#section-3.2>
]FIGCAPTION]

> When the realm portion of the NAI is used as the basis for name
>    resolution, it may be necessary to convert internationalized realm
>    names to Punycode '''['''RFC3492''']''' encoding form as described in '''['''RFC5891''']'''.
>    As noted in Section 2 of '''['''RFC6055''']''', resolver Application Programming
>    Interfaces (APIs) are not necessarily DNS specific, so conversion to
>    Punycode needs to be done carefully:
>    Applications that convert an IDN to A-label form before calling (for
>    example) getaddrinfo() will result in name resolution failures if the
>    Punycode name is directly used in such protocols.  Having libraries
>    or protocols to convert from A-labels to the encoding scheme defined
>    by the protocol (e.g., UTF-8) would require changes to APIs and/or
>    servers, which Internationalized Domain Names for Applications (IDNA)
>    was intended to avoid.
>    As a result, applications SHOULD NOT assume that non-ASCII names are
>    resolvable using the public DNS and blindly convert them to A-labels
>    without knowledge of what protocol will be selected by the name
>    resolution library.

]FIG]


[63] [CITE[#5741 (TBB proxy bypass: Some DNS requests not going through Tor) – Tor Bug Tracker & Wiki]]
( ([TIME[2016-06-16 11:33:05 +09:00]]))
<https://trac.torproject.org/projects/tor/ticket/5741>

[64] [CITE@en[Firefox security bug (proxy-bypass) in current TBBs | The Tor Blog]]
( ([TIME[2016-06-16 11:32:28 +09:00]]))
<https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs>

[65] [CITE@en[Issue 432236 - chromium - Remove AsyncDNS option in about:flags - Monorail]]
( ([TIME[2016-06-16 19:17:34 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=432236>

[66] [CITE@en[Issue 265970 - chromium - Built-in DNS resolver does not handle /etc/resolver configuration - Monorail]]
( ([TIME[2016-06-16 19:20:38 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=265970>

[67] [CITE@en[Issue 545123 - chromium - Experiment with use Async DNS in Cronet - Monorail]]
( ([TIME[2016-06-16 19:22:36 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=545123>

[68] [CITE@en[Issue 239657 - chromium - Crash with async DNS when nameserver rotation enabled and socket pools are exhausted - Monorail]]
( ([TIME[2016-06-16 19:23:06 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=239657>

[69] [CITE@en[Issue 171346 - chromium - Built-in DNS uses the wrong DNS server - Monorail]]
( ([TIME[2016-06-16 19:23:44 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=171346>

[70] [CITE@en[Issue 5139 - webrtc - WebRTC should use async DNS resolution function - Monorail]]
( ([TIME[2016-06-16 19:24:19 +09:00]]))
<https://bugs.chromium.org/p/webrtc/issues/detail?id=5139>

[71] [CITE@en[Issue 143454 - chromium - Add field trial for asynchronous DNS - Monorail]]
( ([TIME[2016-06-16 19:24:42 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=143454>

[72] [CITE@en[Issue 223876 - chromium - Built-in async DNS resolver needs a reliable equivalent to AI_ADDRCONFIG - Monorail]]
( ([TIME[2016-06-16 19:27:50 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=223876>

[73] [CITE@en[Issue 516305 - chromium - Chrome not respecting ipv6 prefix precedence on linux. - Monorail]]
( ([TIME[2016-06-16 19:28:56 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=516305>

[74] [CITE@en[Issue 117655 - chromium - Respect nsswitch.conf when using HOSTS file with --enable-async-dns - Monorail]]
( ([TIME[2016-06-16 19:29:17 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=117655>

[75] [CITE@en[Issue 224215 - chromium - Can't access a local webserver anymore - Monorail]]
( ([TIME[2016-06-16 19:30:05 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=224215>

[76] [CITE@en[Issue 124437 - chromium - Very large default timeout in DnsConfigService - Monorail]]
( ([TIME[2016-06-16 19:38:25 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=124437>

[77] [CITE@en[Issue 518673 - chromium - Slow DNS resolution only within Chrome(?) - Monorail]]
( ([TIME[2016-06-16 19:54:49 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=518673>

[78] [CITE@en[Issue 132128 - chromium - ChromeOS: IPv4-only DNS on IPv6 network - Monorail]]
( ([TIME[2016-06-16 19:55:39 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=132128>

[79] [CITE@en[Issue 402339 - chromium - DNS timeout should be something less than 5 seconds - Monorail]]
( ([TIME[2016-06-16 19:56:16 +09:00]]))
<https://bugs.chromium.org/p/chromium/issues/detail?id=402339>

[81] [CITE@en[94079 – PAC: too many DNS lookups]]
( ([TIME[2016-06-16 21:15:15 +09:00]]))
<https://bugzilla.mozilla.org/show_bug.cgi?id=94079>

[82] [CITE@en[Necko/DNS/ResolverIntegration - MozillaWiki]]
([TIME[2015-03-21 17:32:04 +09:00]] 版)
<https://wiki.mozilla.org/Necko/DNS/ResolverIntegration>


[FIG(quote)[
[FIGCAPTION[
[89] [CITE@en[Necko/DNS/ResolverIntegration - MozillaWiki]]
([TIME[2016-09-01 10:31:08 +09:00]])
<https://wiki.mozilla.org/Necko/DNS/ResolverIntegration>
]FIGCAPTION]

> We're planning to integrate a DNS resolver into Gecko. Our primary motivation is performance, but we're also interested in a number of new security features such as DNSSEC.

]FIG]