名前解決

名前解決 (ドメイン名)

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

プロトコル

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

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

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

[51] ドメイン名のパターンなどにより複数の DNS サーバーを使い分ける実装もあります。
[13] 実装によっては通常と異なる /etc/hosts を使えるものもあります。
[14] 設定により動作を変更できる実装もあります。

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

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

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

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

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

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

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

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

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

出力

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

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

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

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

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

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

特別な IP アドレスの扱い

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


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

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

[95] NEC のネットワーク機器の中には、 aterm.me を機器設定画面の WebサーバーIPアドレス解決するものがあります。 aterm.meNEC が所有するドメイン名で、 通常の DNS では NEC の公開 Webサーバー解決されます。


[93] Chrome0.0.0.0/8名前解決エラーとするようです。

名前解決を経由しないIPアドレスへのアクセスは挙動が異なります。

[94] Chrome224.0.0.1 (マルチキャスト 224.0.0.0/3) や 255.255.255.255 (ブロードキャスト) を失敗としますが、 非妥当アドレスエラーなので、名前解決レベルではなく TCP 側のエラーかもしれません。

[50] Chrome127.0.53.53 (ICANN_NAME_COLLISION) を失敗としますが、名前解決より後のエラーかもしれません。

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

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

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

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

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

[24] そのようなドメイン名であっても URLauthority に使われるなど、 名前解決以外の使われ方では通常のドメイン名と区別がつきません。
[92] 通常の DNS への情報漏洩を避けるため、そうした TLDドメイン名前解決が必ず失敗し、外部に解決を委ねない実装もあります。

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

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

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

解決にかかる時間

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

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

Web における名前解決

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

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

文脈

[43] 次の場面で名前解決が行われます。

セキュリティー

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

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

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

実効要求URLも参照。

実装

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

[1] Windows 名前解決の順序 - Ask the Network & AD Support Team - Site Home - TechNet Blogs ( 版) <http://blogs.technet.com/b/jpntsblog/archive/2009/07/13/windows.aspx>

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>

[4] Postfix Configuration Parameters ( 版) <http://www.postfix.org/postconf.5.html#smtp_host_lookup>

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.

[5] Man page of NSSWITCH.CONF ( 版) <http://linuxjm.sourceforge.jp/html/LDP_man-pages/man5/nsswitch.conf.5.html>

ネームサービススイッチ (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>

[7] AnyEvent::Socket - search.cpan.org ( 版) <http://search.cpan.org/dist/AnyEvent/lib/AnyEvent/Socket.pm>

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/

[8] dex4er/perl-AnyEvent-DNS-EtcHosts ( 版) <https://github.com/dex4er/perl-AnyEvent-DNS-EtcHosts>

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

[18] idn wrapper - JPNIC (Japan Network Information Center 著, 版) <https://www.nic.ad.jp/ja/idn/mdnkit/download/documents/idnkit-1.0pr1-doc/ja/guide/wrapper.html>

Windows では、DNS だけではなく、WINSやLMHOSTS によってもドメイン名、 ホスト名の解決が行われます。 idn wrapper を使った場合には、これらのすべての方式について、 国際化ドメイン名への対応のためのエンコーディング変換が行われることになります。

このため、Windows が、WINSやLMHOSTS を使っている場合には、予期しない 問題が発生する可能性があります。 idn wrapper を使う場合には、名前解決にDNS だけを使用することをお勧めします。

[19] <idn> 要素 (Uri 設定) ( 版) <https://msdn.microsoft.com/ja-jp/library/bb882553(v=vs.110).aspx>

idn enabled = AllExceptIntranet

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

[26] Network Stack - The Chromium Projects ( 版) <https://www.chromium.org/developers/design-documents/network-stack>

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

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

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

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

関連

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

歴史

IDNA2003

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

[86]

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文字に対応し、 ToASCIIToUnicodeライブラリーの内部で行うことが想定されています >>84

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

IDNA2008

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

[36] RFC 6055 - IAB Thoughts on Encodings for Internationalized Domain Names ( 版) <https://tools.ietf.org/html/rfc6055#page-6>

[37] RFC 6055 - IAB Thoughts on Encodings for Internationalized Domain Names ( 版) <https://tools.ietf.org/html/rfc6055#section-4>

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>

[58] RFC 7686 - The ".onion" Special-Use Domain Name ( 版) <https://tools.ietf.org/html/rfc7686>

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].

[59] RFC 7542 - The Network Access Identifier ( 版) <https://tools.ietf.org/html/rfc7542#section-3.2>

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>

[89] 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.

[96] WCF and Internationalized Domain Names () <https://msdn.microsoft.com/en-us/library/hh556231(v=vs.110).aspx>

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.