事の始まり
VirtualBoxのホストオンリーアダプターでクローズド環境なテスト環境を構築した。
その際、DNSの名前解決ができない壁にぶち当たる。
やったこと
Contents DNSにはexample.testドメインの権威サーバーとしてbindを設定。
Cache DNSはContents DNSをフォワーダーとして、丸投げキャッシュDNSとして作成。
Clientから
dig @ContentsDNS example.test any
直接権威サーバーに問い合わせれば解決できるが
dig @CacheDNS example.test any
これがエラーになる。キャッシュサーバーは解決してくれない。
解決策(そして新たな謎)
Cache DNSの/etc/named.confにある”dnssec-validation”のパラメータを"no"にしてあげることで、”名前解決”はできるようになる。
DNSSECというDNSの回答が本当に正しい権威サーバーから返しているのか検証する機能だ。多分。
キャッシュ側でその検証を無効化したおかげで、権威サーバーからの回答を受け入れてくれた。
確かに今回の権威サーバーではそんなややこしい設定はしていない。zoneファイル作っただけだ。
そうか世のDNS権威サーバーはこんなややこしい設定されてるんだなぁすげぇや。と思いきや調べてみると
dnsviz.net
google.comってば署名されてないじゃん！ (2022/2現在)
先の"dnssec-validation”は使ったCentOS8のbindでは初期設定で有効だ。消してもデフォルト有効になる。
これでクローズドではない社内キャッシュDNSとして設置したらググれないではないか！
そして迷宮入り
そんなことは無い。安心してほしい。
Cache DNSをNAT接続にし、フォワーダーをISPのDNS書き換えたが、"dnssec-validation”が有効でも、何も問題なく名前解決してくれる。
ん？署名してないよ？ドメインの署名確認してくれるんじゃないの？んん？
いやじゃあクローズドで解決してくれなかったのはなぜ？
色々調べてみたが、解決していない。誰か答えを教えてほしい。
小学生並みの仮説
当然ながら、.(ルート)はDNSSEC署名がされている。トラストアンカーというものらしい。
トラストアンカーに対する公開鍵はbindに同梱されている。2017年にこれが変わるせいで大騒ぎになった、らしい。
comもTLDのせいか、署名されている。
このあたりの上位ドメインで解決がなされれば一応OK、という判断をしているのではないか。
それであればクローズドの(やっつけドメインの)環境ではルート、及び上位ドメインを管理するDNSまでは作成していないので
辻褄は合う。そうしないとDNS使えなくなっちゃうものね。大混乱だし、そんな危険な機能有効にできないわ。
しかしそれであれば、現実外部ネットワークでDNSSEC検証が機能すること、「このgoogle.comの回答は嘘だね！」ということは無い、ということか。
ちなみにクローズドの環境でContents DNSにgoogle.comのゾーンも作ってみたが、結果は同じだった。
.testだとかそういうのが問題なわけでもなさそうだ。
ほんと、なんなん？
