/etc/hosts /etc/hosts
.
(
main.x や
printer.x の x のような独自の
localhost と .localhost について、
CNAME によって
CNAME が使われていても、大元の
aterm.me を機器設定画面の
aterm.me は
0.0.0.0/8 を
224.0.0.1 (224.0.0.0/3)
や 255.255.255.255 (
127.0.53.53 (ICANN_NAME_COLLISION)
を失敗としますが、
dns-prefetch
Host: の検証などを通してこれを検査する必要があります。
1) DNS リゾルバーキャッシュ (*1) を確認して、指定された名前に対応するレコードがキャッシュされている場合は、そのアドレスを返します。
2) HOSTSファイル (*2) を参照し、指定された名前に対応するレコードが登録されている場合はそのアドレスを返します。
3) 登録されている DNS サーバーに問い合わせを行い、受領したアドレスを返します。
4) 上記 1 ~ 3 で名前解決に成功しない場合は、NetBIOS 名前解決を行います。
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 ライブラリが いろいろなカテゴリーの名前サービス情報を、どの情報源から どの順序で取得するかを判断するのに使用される (情報の各カテゴリーはデータベース名で識別される)。
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.
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).
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.
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.
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.