動的IPアドレスを使用する場合は、/ etc / hostsを使用してDNSサーバールックアップをバイパスします
それらの一般的にアクセスされる名前が/ etc/hostsに存在する場合、一般的にアクセスされる名前について外部DNSサーバーに照会する必要性を減らすことができると私は理解しています。
今、私は動的IPアドレスを持つ組み込みLinuxボックスを持っている状況があります。この動的IPアドレスが現在206.190.36.105であると仮定しましょう。
/ etc/hostsファイルの内容は次のとおりです。
[root@zop]# cat /etc/hosts
127.0.0.1 localhost
192.168.0.1 mydevice
173.194.33.18 somesite.com
ただし、tcpdumpを実行してsomesite.comにpingを実行すると、DNSルックアップを介してsomesite.comが解決されていることがわかります。
17:28:48.330535 IP 206.190.36.105 > somesite.com: ICMP echo request, id 14880, seq 0, length 64
17:28:48.333465 IP 206.190.36.105.57201 > resolver1.opendns.com.domain: 2+ PTR? 204.220.167.10.in-addr.arpa. (45)
17:28:49.312286 IP somesite.com > 206.190.36.105: ICMP echo reply, id 14880, seq 0, length 64
17:28:49.335601 IP 206.190.36.105 > somesite.com: ICMP echo request, id 14880, seq 1, length 64
17:28:49.366973 IP resolver1.opendns.com.domain > 206.190.36.105.57201: 2* 0/1/0 (104)
17:28:49.368286 IP 206.190.36.105.59381 > resolver1.opendns.com.domain: 3+ PTR? 204.220.167.10.in-addr.arpa. (45)
17:28:49.664215 IP somesite.com > 206.190.36.105: ICMP echo reply, id 14880, seq 1, length 64
17:28:49.742004 IP resolver1.opendns.com.domain > 206.190.36.105.59381: 3* 0/1/0 (104)
17:28:49.743194 IP 206.190.36.105.57388 > resolver1.opendns.com.domain: 4+ PTR? 204.220.167.10.in-addr.arpa. (45)
17:28:50.038848 IP resolver1.opendns.com.domain > 206.190.36.105.57388: 4* 0/1/0 (104)
17:28:50.040069 IP 206.190.36.105.53513 > resolver1.opendns.com.domain: 5+ PTR? 204.220.167.10.in-addr.arpa. (45)
17:28:50.335815 IP resolver1.opendns.com.domain > 206.190.36.105.53513: 5* 0/1/0 (104)
17:28:50.337036 IP 206.190.36.105.54248 > resolver1.opendns.com.domain: 6+ PTR? 204.220.167.10.in-addr.arpa. (45)
次のように、/ etc/hostsにLinuxボックスの現在のIPアドレスのエントリを作成するとします。
[root@zop]# cat /etc/hosts
127.0.0.1 localhost
192.168.0.101 mydevice
173.194.33.18 somesite.com
206.190.36.105 whatismyip
次に、somesite.comへのpingと並行してtcpdumpを実行すると、DNSルックアップがバイパスされていることが示されます。
17:15:35.795013 IP whatismyip > somesite.com: ICMP echo request, id 61212, seq 0, length 64
17:15:36.648193 IP somesite.com > whatismyip: ICMP echo reply, id 61212, seq 0, length 64
17:15:36.809234 IP whatismyip > somesite.com: ICMP echo request, id 61212, seq 1, length 64
17:15:37.164276 IP somesite.com > whatismyip: ICMP echo reply, id 61212, seq 1, length 64
17:15:37.819915 IP whatismyip > somesite.com: ICMP echo request, id 61212, seq 2, length 64
17:15:38.148193 IP somesite.com > whatismyip: ICMP echo reply, id 61212, seq 2, length 64
17:15:38.827728 IP whatismyip > somesite.com: ICMP echo request, id 61212, seq 3, length 64
この観察された行動の背後にある理論的根拠を理解することに興味があります。組み込みLinuxベンダーは、この動作は正常で予想される動作であると主張していますが、合理的には、宛先IPアドレスのみが/ etc/hostsファイルにない場合、DNSルックアップをバイパスするべきではありませんか？
順方向DNSルックアップと逆方向DNSルックアップを混同していると思います。
フォワードDNSルックアップは名前からIPアドレスになります。最初のtcpdumpでDNSパケットを見ると、IPを名前に変換する要求であるPTR?（ポインター要求）が表示されます。
z.y.x.w.in-addr.arpaは、逆引き参照表記で要求されているIPです。この順序を逆にすると、検索しようとしているIPアドレスであるw.x.y.zが取得されます。
tcpdumpは、IPで逆ルックアップを実行する必要がないため、pingではなく、逆ルックアップ要求のソースであると思われます。 IPを/etc/hostsに追加すると、リゾルバーライブラリがDNSクエリを実行せずにIPを見つけることができるため、tcpdumpはIPに対して逆ルックアップを実行する必要がなくなります。
これらのルックアップを回避するために、通常は-nオプションを指定してtcpdumpを実行することをお勧めします。通常は必要ありません。
ルックアップの順序は通常、/etc/nsswitchによって制御されます。 /etc/hostsにエントリがあり、それが最初のルックアップである場合、DNSルックアップは発生しないことに注意してください。エントリが静的で正しいことを確認してください。
dnsが最初の場合、/etc/hostsはDNSルックアップが失敗した場合にのみ使用されます。 filesが最初の場合、dnsは/etc/hostsが失敗した場合にのみ使用されます。
/etc/resolv.confのsearchおよびdomain行により、名前が見つからない場合、追加のルックアップが試行される場合があります。 ndotsオプションを使用して、検索でのsearchおよびdomainの使用を無効にするために必要なドットの数を示すことができます。
searchの最初のエントリに関連付けられた/etc/hostsのエイリアスを使用して、追加の検索ドメインでのルックアップを防ぐことができます。
表示されるDNSリクエストは、IPをドメイン名にマッピングするリバースリクエストです。
PTR 204.220.167.10.in-addr.arpa.
Pingは、10.167.220.204の名前（おそらくクライアントのIP？）を要求します。 tcpdump出力に転送リクエスト（somesite.comをIPアドレスに解決する）が表示されませんでした。
ここで、元の意図に戻ります。これは、ネットワークトラフィックを削減することだと思います。 nscd（Name Services Caching Daemon）を実行すると、通常、ホスト名ごとに1つのDNS要求のみが表示され、nscdデーモンがそれをキャッシュします。これは、ネットワークの変更や番号の付け直しで/etc/hostsを最新の状態に保つよりもはるかに優れたオプションです。