検証ドメインに自鯖DNSでDNSSECを導入した
6月末に検証用ドメインを購入していたが、今まで他の検証をしていて忘れていた (´・ω・｀)
折角購入した物を放置するのも勿体無いので、DSレコード申請が出来るレジストラの調査を再開したら、
バリュードメインも一部のgTLD/ccTLDにはDSレコード申請に対応している事が判明した。
そうなればシメた物。今回の検証ドメインはバリュードメインで購入していたので、
レジストラトランスファーを行わずにDSレコード申請が出来る事となる。
という事で、自力で解決不可能な問題は無くなったので、実際に自鯖権威DNSにDNSSECを導入してみた。
元ネタは、IIJエンジニアブログで公開していた次の記事。
バリュードメイン利用時のDSレコード申請方法は、筆者の技術wikiに纏めてみた。
- IIJ Engineers Blog > やってみようDNSSEC
- nowsky system-lab memo > Knot
今回はお試しでDNSSECを触ってみたかったのと、粗探しの検証も兼ねているので、
構成はIIJのサンプルを流用して変に躓かないようにした。
ゾーン管理にはBIND、ゾーン署名にKnot、DNSクエリ処理にNSDを使う多段構成になっている。
最初はKnotを使わずに、スクリプトとansibleを組み合わせてゾーン署名の自作を考えていたのだが、
レコードを書き換えた時のロック処理や、署名の自動更新が複雑で実装が凄く面倒臭かったので諦めた。
………
今回一番躓いたのはDNSSECの仕組み把握する事。関連技術が多い上、文献も多く中々大変だった。
とは言っても、正しく把握しないと運用出来ないのでJPRS資料を片っ端から読んでなんとかした。
資料にも書かれていない細かい仕様があったりするが、
運用する上で必要な情報はゲット出来たので結果オーライだと思う。
ソフトウェア面ではKnotを使うのが初めてだったが、
1週間程度弄っていたらチューニングのコツは大体わかった。
DNSSECの実装範囲はソフトウェア毎に違うので、結果として弄るのが最善・最短となった。
という事で、DNSSECオプションを有効にしてDNS名前解決したのがこちら。
実際はもっと長いレコードが返ってくるのだが、画像が横にデカくなってしまうので割愛。
サンプルでは個別にAAAAレコードも指定しているが、ちゃんとRRSIGレコードが付与されている。
………
本来はメイン利用の権威DNSにもDNSSECを導入したいのだが、、
サーバをマルチマスターかつansibleでゾーン管理をしているのでサーバの改修が必要となった。
また、DNSSEC運用を間違えたら名前解決が全滅するので、いきなり適用するのは見送った。
検証ドメインを購入して何でも出来る様に、メイン利用のドメインと別に用意した訳なので、
暫くはこのまま検証ドメインで運用を続け、軌道に乗ったらメイン利用のドメインに反映しようと思う。
形は置いといてDNSSECの導入は出来たので、当初の目的は達成出来たとしてヨシとしよう。
