dig app.example.test Aは正しいaddressを返すが、getent hosts app.example.testは何も返さない。
DNS server自体ではなくNSSのhost検索経路を最初に確認する。
確認すべきfileはどれか。
digはDNSへ直接queryする一方、getentはNSSを使うため、差が出る場合はnsswitch.confのhosts行とNSS moduleを確認する。
詳細解説
/etc/hostnamelocal host自身のstatic hostnameを保持する。
誤り。static hostnameが異なっても、getentのhosts databaseでdnsを使うかの設定にはならない。
/etc/nsswitch.confhosts databaseでdns serviceを利用するかと検索順を定める。
正しい。hosts行にdns等がなければdigは成功してもgetentがDNSを参照しないため、最初の確認対象になる。
/etc/servicesservice名とport/protocolの対応を保持する。
誤り。services databaseはhttps 443/tcp等の名前とport対応用で、host名解決sourceを制御しない。
/etc/protocolsIP protocol名とnumberの対応を保持する。
誤り。protocols databaseはtcp 6等の対応用で、NSS hostsのDNS利用可否とは別である。
実際に確かめる
一時的な検証環境で実行できる例です。
printf '%s
' 'dig=DNS query' 'getent hosts=NSS lookup' 'difference -> inspect nsswitch hosts line'期待される結果
dig=DNS query
getent hosts=NSS lookup
difference -> inspect nsswitch hosts line理解のポイント
- digとgetentの経路差
- hosts行を確認
- dns serviceの有無
確認時の注意
- 確認環境: 診断対応表の表示のみ
基礎のおさらい
差分診断
同じnameでもdigとgetentの結果差を比較すると、DNS server側かclient NSS側かを分離できる。
NSS module
設定名だけでなく対応moduleの導入やservice状態も、getentだけが失敗する原因になり得る。