祝ルートからJPへのチェイン。弊社が利用しているドメイン(co.jp jp ch me es be dk com net org…)もすべてDNSSECおよびDANE/TLSA対応完了。DNSSECが有効でTLSA RR,CAA RRにも対応したセカンダリDNSサーバ,DANE,TLSA,DMARC,DKIM,SPFに関するご相談は弊社へどうぞ。と宣伝をしたところで以下は設定を確認するためのリンク集と自分で確認する手順。
- JPRS DNSの設定チェック
- (サービス終了)
DNS-OARC ODVR - (開発終了)
cz.nic DNSSEC/TLSA Validator(web browser extention) - iis.se DNSCheck(by .SE)
- VeriSign DNSSEC Debugger
- DNSViz DNSViz
- DANE Validator by SIDN Labs
- DANE SMTP Validator
- DNSSEC関連RFC
- DNSSECジャパン
DNS-OARCや公開サーバでDNSSECが有効なものをODVRとして使用する方法は、DNS-OARCに書かれているように
|
1 |
dig @8.8.4.4 +dnssec kana.me |
のようなコマンドにて、ADビットがついている、かつ正しい応答であることを確認をします。
|
1 2 3 |
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33906 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 11 |
これだと他人任せなので、もう少し自力で確認するにはroot(.)のKSK(257)を取得してトラストアンカーとしてから検証します。
delv版
|
1 2 3 4 |
cd ~/tmp dig +nosplit . DNSKEY | egrep -E -e '[[:space:]]257[[:space:]]' > hoge.rr.txt # 適当取得 sed -n -E -e 's/^\.[[:space:]]+.*[[:space:]]+(257[[:space:]]+[[:digit:]]+[[:space:]]+[[:digit:]]+)[[:space:]]+(.*)[[:space:]]*$/managed-keys { . initial-key \1 "\2"; };/p' hoge.rr.txt | head -n 1 > hoge.key delv +rtrace -a hoge.key abacustech.co.jp |
にて
|
1 |
; fully validated |
古いdig +sigchase版
|
1 2 3 |
cd ~/tmp dig +nosplit . DNSKEY | egrep -E -e '[[:space:]]257[[:space:]]' > hoge.rr.txt # 適当取得 dig +trusted-key=hoge.rr.txt +sigchase abacustech.co.jp |
WE NOW DO VALIDATION が何回か表示され、最終的に指定したトラストアンカーまでたどり着くのを確認します。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
Launch a query to find a RRset of type DS for zone: . ;; NO ANSWERS: no more ;; WARNING There is no DS for the zone: . ;; WE HAVE MATERIAL, WE NOW DO VALIDATION ;; VERIFYING DS RRset for jp. with DNSKEY:61045: success ;; OK We found DNSKEY (or more) to validate the RRset ;; Ok, find a Trusted Key in the DNSKEY RRset: 19036 ;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS |
お気づきの通りこのやり方では、キャッシュサーバでDNSSECのvalidationが正常に動作していた場合(その場合はすでにトラストアンカーがあったわけですが)を除きトラストアンカーの真正性が確認されていないため、改ざんの可能性が大きく残ります。DNSSEC Trust Anchor Fetcherやunbound-anchorを利用したり、bindであればmanaged-keysを含む/etc/namedb/bind.keys(無いときはlocate bind.keysとかで探す)ファイルが付属しているはずなのでそのファイルのハッシュを検証して利用するなどでより確からしくなります。ここではroot(.)のzoneファイルをhttpsで取得して使ってみます。
|
1 2 |
cd ~/tmp fetch 'https://www.internic.net/domain/root.zone' |
~/tmp/hoge.rr.txtが~/tmp/root.zoneのDNSKEYと同じであることを確認しつつ、念のためこれで再度確認します。
|
1 2 3 |
cd ~/tmp sed -n -E -e 's/^\.[[:space:]]+.*[[:space:]]+(257[[:space:]]+[[:digit:]]+[[:space:]]+[[:digit:]]+)[[:space:]]+(.*)[[:space:]]*$/managed-keys { . initial-key \1 "\2"; };/p' root.zone | head -n 1 > root.key delv +rtrace -a root.key abacustech.co.jp |
今時のキャッシュサーバはデフォルトでtrust anchorが自動更新されるようにパッケージングされていることと思いますが、運用している場合は念のためroot(.)のロールオーバーに対応できるようになっていることも確認します。
今は亡きdigの+sigchaseは;; We are in a Grand Father Problem: See 2.2.1 in RFC 3658 とか言ってみたり core はいてくれたりするので、delvを使うかさっさとUnboundをDNSSEC有効なキャッシュサーバとしてインストールする方が早いです。validationは自分のUnboundでやるのでADビットはついてなくても良いとしても、いまだにISPのキャッシュサーバがDOビット付きqueryでもRRSIG付けて返してくれないといった悲しい状況では公開サーバなどをforwarderとして利用することとなるのでしょう。幸い弊社環境ではすべてRRSIGを付けて返してくれる上流ばかりでした。
以下はDNSVizの確認用リンク