Squid Split DNS: プライベートドメインを適切なリゾルバーへ振り分ける
Squid に曖昧なリゾルバー一覧を渡すのではなく、プライベートとパブリックの DNS 名前空間を意図的に振り分けます。
内部リゾルバーを先に、パブリックリゾルバーを次に置いても、どの名前がどちらの名前空間に属するかは Squid に伝わりません。
Squid 6 と 7 では、dns_nameservers は通常のリゾルバー一覧をサーバーアドレスに置き換えます。この構文にはドメイン単位のマッピングはありません。正当な否定応答は到達不能なリゾルバーとも異なるため、互換性のない名前空間を代替で探す方法は信頼できません。
ドメインごとに問い合わせを振り分ける
ローカルの DNS フォワーダーなら、欠けているポリシーを表現できます。既存の dnsmasq 設定では、プライベートなサフィックスを次のように振り分けられます。
server=/internal.example/192.0.2.53ドメインとアドレスを置き換えます。他の名前には承認済みの既定アップストリームを、適切なリスナーとアクセス制限も設定します。そのうえで、インストール済みバージョンが対応する設定を使って Squid をそのリゾルバーに向けます。
別の方法として、両方の名前空間を正しく解決する組織の DNS サービスを使います。プライベート名を公開しながら応答できないパブリックフォールバックは避けてください。
親プロキシが宛先の解決を行う場合、そのホップにはプライベート名前空間が必要です。ローカルの Squid ホスト上のリゾルバーでは親の解決は直りません。
否定のケースも確認する
有効なプライベート名、有効なパブリック名、存在しないプライベート名を用意します。それぞれについて、想定されるアップストリームと、期待する応答がアドレスか否定応答かを特定します。最後のケースは、内部の否定応答の後に意図せずパブリックへフォールバックしていることを示します。
クライアントが必要とするアドレスファミリーを含めます。A の解決が成功しても、AAAA がポリシーに従うことや到達可能な宛先を返すことは証明できません。キャッシュの状態も記録してください。キャッシュされた応答は、新しい問い合わせがどのアップストリームを選ぶかを隠すことがあります。