[32] 名前解決は、ドメイン名等の名前からネットワーク上のアドレスを得る操作です。 多くの OS やプログラミング言語の標準ライブラリー等は、 DNSドメイン名等からIPアドレス等を取得できる名前解決の仕組みを提供しています。
[11] 名前解決は、 OS、ライブラリー、あるいは個別のアプリケーションのいずれか、あるいはその組み合わせにより実装されており、 その実装方法は様々です。従って同じ環境でもアプリケーションによって動作が異なることがあります。 名前解決における DNSキャッシュ (や DNS 以外の方法で得られた名前解決結果のキャッシュ) の動作も違いがあります。
[12] 名前解決には、次のような手段が使われます。どれを使うか、どのような優先順位とするか、 失敗した場合他の方法を試すか、キャッシュを適用するかなどは実装により異なります。
/etc/hosts
を使えるものもあります。[39] 多くの Linux システムでは既定の状態で DNS より
/etc/hosts
が優先されるようになっています。 Web開発者はしばしば
/etc/hosts
を書き換えて、実際とは異なるサーバーに接続させ、
開発中のアプリケーションの動作を確認することがあります。
中にはこの標準的な動作とは異なる実装もありますが >>7、
そうした使い方ができないため、不評です >>8。
[15] 入力として IPアドレス (のようなもの) を与えた場合、 IPアドレスとして解釈した結果を返す実装もあります。 十六進数表記の IPv4アドレスなど、標準的でない IPアドレスの指定方法を認めている実装もあります。 URLのホストなど、ドメイン名とIPアドレスのいずれかを指定できる文脈もよくあるので、 どちらが入力でも適当な結果が返される方が便利そうです。
[20] 解決する名前のパターンその他で解決方法を切り替えたり、 Aラベルへの変換を行うかどうか決定したり、 DNSサーバーを切り替えたりする実装や設定もあります。
[21] 名前解決や DNS の実装によっては、指定された通りの名前を解決するだけでなく、
指定された名前の後に予め設定された文字列
(所属するネットワークに割り振られたドメイン名など) を結合した名前を解決しようとすることがあります。
所属ネットワークのドメイン名を省略したホスト名 (計算機名)
のみで名前解決できるようにするために用意されている機能です。
解決したい名前の末尾に根ドメインを表す .
(末尾の点) を明記することでこの挙動を防ぐことができるとされています
(が、実際の挙動は、実装によって異なっています)。
[22] いわゆる alternative root の他、組織内ネットワーク等の DNSサーバーを用いて一部または全部の名前を解決するように設定されていることがあり、 その場合インターネットの DNS で用いられているドメイン名の体系に属さないドメイン名で名前解決されることがあります。
[25] DNSラウンドロビンの実装方法や IPv4 と IPv6 の選択など、 DNS解決器の実装の詳細や動作モードにも様々なバリエーションがあります。
[98]
localhost
と .localhost
について、
let-localhost-be-localhost
名前解決規則があります。
[99] この規則を採用するか否かは、潜在的に信頼できる起源の判定に影響します。
[28] 名前解決が成功した場合は、アドレスが返されます。一般的には、 IPv4アドレスまたは IPv6アドレスが返されます。
[29] DNSラウンドロビンなどで複数のアドレスが得られた場合、 アドレスのリストが返される実装もあります。
[60] DNS では、 CNAME
によって名前に対応するアドレスを他の名前によって間接的に記述することができますが、
普通、名前解決は、それを更に解決して最終的に得られたアドレスを返します。
アプリケーション側は中間の名前にはアクセスできず、
諸操作に中間の名前を使うこともありません。
[61] HTTPリダイレクトがあると、最終的な応答の URL
は、リダイレクトの指示に従って書き換わった結果の URL となります。
それとは違って、 CNAME
が使われていても、大元のドメイン名がそのまま応答の
URL に使われ、書き換わることはありません。
[30] OS 等が提供する名前解決では、 DNS における TTL など名前に付随するその他の情報にはアクセスできないのが一般的です。 これを理由にアプリケーション側で独自に名前解決を実装することもあります。
[31] 名前解決は失敗することがあります。アプリケーションは失敗時の処理も実装しておく必要があります。
[47] 通常はユニキャストアドレスが返されることが期待されていますが、 DNS 等がブロードキャストアドレスやマルチキャストアドレス、 あるいは特殊なアドレスを返す可能性もあります。
[48] 広くインターネットからアクセス可能なアドレスが返されることもあれば、 私的なネットワーク内のみで通用するアドレスのこともあります。
[95] NEC のネットワーク機器の中には、 aterm.me
を機器設定画面の
Webサーバーの IPアドレスに解決するものがあります。
aterm.me
は NEC が所有するドメイン名で、
通常の DNS では NEC の公開 Webサーバーに解決されます。
[93] Chrome は 0.0.0.0/8
を名前解決エラーとするようです。
[94] Chrome は 224.0.0.1
(マルチキャスト 224.0.0.0/3
)
や 255.255.255.255
(ブロードキャスト) を失敗としますが、
非妥当アドレスエラーなので、名前解決レベルではなく TCP
側のエラーかもしれません。
[50] Chrome は 127.0.53.53
(ICANN_NAME_COLLISION
)
を失敗としますが、名前解決より後のエラーかもしれません。
[9] SOCKS では接続先としてIPアドレスではなくドメイン名を指定することもできますので、 これは名前解決を SOCKS サーバーに委ねていることになります。
[10] 絶対URLによる HTTP要求や HTTP CONNECT
では接続先のホストを要求対象として指定することになるので、
名前解決を HTTPサーバー (串) に委ねていることになります。
[52] 組織内ネットワークのドメイン名を SOCKS5 プロキシ経由でアクセスするべき場合のように、 当該システムにおいて通常の DNS などでは名前解決できないものが使われることもあります。
[23] Tor の .onion
のように、 DNS 等通常の方法で名前解決することは想定せず、
SOCKS など串を通した名前解決に限って用いられるドメイン名も存在します。
[27] こうした形の間接的な名前解決では、クライアントは解決結果のアドレスを知ることはできませんし、その必要もありません。 (クライアントが直接アクセスできないアドレスに解決されている可能性も強いです。)
[53] プロキシによる接続と通常の名前解決が混在すると、 意図しない動作を引き起こすかもしれません。
[54] 例えば、プロキシによる名前解決と DNS prefetch を併用すると、おかしなことが起こるかもしれません。
[33] 名前解決は、 DNS 等ネットワークにより問い合わせる場合には相応の時間を必要とします。 そのためアプリケーションの処理内容や解決する名前の量によっては、 できるだけ名前解決が発生するのを避けるべきとされていることもあります。
[35] DNS Prefetching のような、必要になりそうな名前解決を予め行い結果をキャッシュする仕組みが利用されることもあります。
[56] Web では名前解決は透過的に行われ、著者に順引きや逆引きなどの API は提供されていません。
[57] WebSocket接続の確立では同時接続数の制限に名前解決結果が使われています。
[44] DNSSEC を使う場合や組織内の DNSサーバーに組織内ドメインの名前解決を委ねた場合、
/etc/hosts
を使う場合など名前解決の結果が「正しい」
ことを保証できる場合もあれば、一般のインターネットの DNS
ドメイン名の解決の場合のように、(通信路上または DNS 等のサーバーにおいて)
攻撃者に結果を改竄される可能性を排除できない場合もあります。
[45] TLS + サーバー証明書の service identity 検証のように、 用途に応じた適切な手段で解決結果と通信相手が「正しい」 ことを別途確認する必要があるかもしれません。
[55] DNS rebinding のように名前解決を操作することによる攻撃も存在します。
サーバーは、自身の意図する名前でのみクライアントがアクセスして来ることが保証されていませんから、
SNI や Host:
の検証などを通してこれを検査する必要があります。
[80] Chrome は OS の名前解決を使うのをやめて独自実装に切り替えましたが、 その過程で相当数の不具合報告を受け取っており、いくつかは未だ解消していないようです。 OS の名前解決処理は明文化されていない部分が相当に複雑で再実装困難なようです。
1) DNS リゾルバーキャッシュ (*1) を確認して、指定された名前に対応するレコードがキャッシュされている場合は、そのアドレスを返します。
2) HOSTSファイル (*2) を参照し、指定された名前に対応するレコードが登録されている場合はそのアドレスを返します。
3) 登録されている DNS サーバーに問い合わせを行い、受領したアドレスを返します。
4) 上記 1 ~ 3 で名前解決に成功しない場合は、NetBIOS 名前解決を行います。
[2] Microsoft TCP/IP のホスト名解決の順序 ( 版) https://support.microsoft.com/en-us/kb/172218/ja
[3] Microsoft ネットワークを解剖する 第1回「NetBIOSでの通信と名前解決の仕組み」 -- Microsoftネットワークの混迷 -- ( 版) http://www.monyo.com/technical/windows/msnet/msnet1.html
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.
ネームサービススイッチ (Name Service Switch; NSS) の設定ファイル /etc/nsswitch.conf は、 GNU C ライブラリが いろいろなカテゴリーの名前サービス情報を、どの情報源から どの順序で取得するかを判断するのに使用される (情報の各カテゴリーはデータベース名で識別される)。
[6] Check /etc/hosts first · Issue #2 · potyl/perl-AnyEvent-CacheDNS ( 版) https://github.com/potyl/perl-AnyEvent-CacheDNS/issues/2
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/
AnyEvent::DNS::EtcHosts changes AnyEvent::DNS behavior. The /etc/hosts file is searched before DNS, so it is possible to override DNS entries.
Windows では、DNS だけではなく、WINSやLMHOSTS によってもドメイン名、 ホスト名の解決が行われます。 idn wrapper を使った場合には、これらのすべての方式について、 国際化ドメイン名への対応のためのエンコーディング変換が行われることになります。
このため、Windows が、WINSやLMHOSTS を使っている場合には、予期しない 問題が発生する可能性があります。 idn wrapper を使う場合には、名前解決にDNS だけを使用することをお勧めします。
idn enabled = AllExceptIntranet
この値は、ローカルなイントラネット以外のすべての Unicode ドメイン名を、等価の Punycode (IDN 名) を使用するように変換します。 このように、ローカルなイントラネットで国際名を処理する場合、このイントラネットで使用する DNS サーバーは Unicode の名前解決をサポートしている必要があります。
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.
[40] 名前解決は各システムやその所属するネットワークの様々な事情の影響を受けるため、 明確な標準が存在せず、様々な実装や設定が存在しています。 インターネットの DNS の LDHラベルのみで構成される一般的なドメイン名のみを使う限りは問題はほとんど起こりませんが、 それ以外の、少しでも特殊な事情のある名前の解決は、しばしば問題を引き起こします。
[41] 名前解決の問題は個別システムの事情で標準化に馴染まないとの考え方もありますが、 実際にはネットワークアプリケーションの相互運用性に関わる重要な要素の1つです。 例えば URL は authority でドメイン名を使っていますから、 それがどう解決されるかは Web の根幹に関わります。
[83] DNS の解決を行うソフトウェア・コンポーネントを解決器といいます。
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).
[85] 旧来のリゾルバー・ライブラリーは ASCIIドメイン名を想定しているので、IDNA 対応アプリケーションは ToASCII 演算により ASCII に変換する準備をしなければなりません。 >>84
[87] 新しいリゾルバー・ライブラリーは非ASCII文字に対応し、 ToASCII や ToUnicode をライブラリーの内部で行うことが想定されています >>84。
[88] リゾルバー・ライブラリーに渡したり、 DNS 要求で question section に入れたりするドメイン名は、 Stringprep における照会文字列の規則に従います >>84。
[91] 「lookup」は、IDNA2008 によって行われる演算と DNS解決器によって行われるものの全体を指します >>90。
[36] RFC 6055 - IAB Thoughts on Encodings for Internationalized Domain Names ( 版) https://tools.ietf.org/html/rfc6055#page-6
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.
[46] Manpage of GETHOSTBYNAME ( ( 版)) http://archive.linux.or.jp/JM/html/LDP_man-pages/man3/gethostbyname.3.html
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].
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.
[63] #5741 (TBB proxy bypass: Some DNS requests not going through Tor) – Tor Bug Tracker & Wiki ( ()) https://trac.torproject.org/projects/tor/ticket/5741
[64] Firefox security bug (proxy-bypass) in current TBBs | The Tor Blog ( ()) https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs
[65] Issue 432236 - chromium - Remove AsyncDNS option in about:flags - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=432236
[66] Issue 265970 - chromium - Built-in DNS resolver does not handle /etc/resolver configuration - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=265970
[67] Issue 545123 - chromium - Experiment with use Async DNS in Cronet - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=545123
[68] Issue 239657 - chromium - Crash with async DNS when nameserver rotation enabled and socket pools are exhausted - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=239657
[69] Issue 171346 - chromium - Built-in DNS uses the wrong DNS server - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=171346
[70] Issue 5139 - webrtc - WebRTC should use async DNS resolution function - Monorail ( ()) https://bugs.chromium.org/p/webrtc/issues/detail?id=5139
[71] Issue 143454 - chromium - Add field trial for asynchronous DNS - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=143454
[72] Issue 223876 - chromium - Built-in async DNS resolver needs a reliable equivalent to AI_ADDRCONFIG - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=223876
[73] Issue 516305 - chromium - Chrome not respecting ipv6 prefix precedence on linux. - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=516305
[74] Issue 117655 - chromium - Respect nsswitch.conf when using HOSTS file with --enable-async-dns - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=117655
[75] Issue 224215 - chromium - Can't access a local webserver anymore - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=224215
[76] Issue 124437 - chromium - Very large default timeout in DnsConfigService - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=124437
[77] Issue 518673 - chromium - Slow DNS resolution only within Chrome(?) - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=518673
[78] Issue 132128 - chromium - ChromeOS: IPv4-only DNS on IPv6 network - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=132128
[79] Issue 402339 - chromium - DNS timeout should be something less than 5 seconds - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=402339
[81] 94079 – PAC: too many DNS lookups ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=94079
[82] Necko/DNS/ResolverIntegration - MozillaWiki ( 版) https://wiki.mozilla.org/Necko/DNS/ResolverIntegration
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.
When the IDN setting is set to “None”, no conversions are performed by Uri.Host or Uri.DnsSafeHost. When the IDN setting is set to “All”, uri.Host remains Unicode and uri.DnsSafeHost is converted to Punycode. When the IDN setting is set to “AllExceptIntranet”, uri.DnsSafeHost is converted to Punycode for internet addresses, and remains Unicode for intranet addresses. This setting is important for correct DNS name resolution.
[97] 696569 - Cronet needs to support disabling ipv6 - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=696569
[100] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#--resolve
[101] 265970 - Built-in DNS resolver does not handle /etc/resolver configuration - chromium, https://bugs.chromium.org/p/chromium/issues/detail?id=265970