[書籍]実践DNS - DNSSEC時代のDNSの設定と運用 -

2011/5/30-1
実践DNS-DNSSEC時代のDNSの設定と運用-

実践DNS - DNSSEC時代のDNSの設定と運用 -」の献本を頂きました。 ありがとうございます。

私はDNSのことが良くわからなくて「勉強したい」と思いつつ色々調べてはいるのですが、DNSの情報がまとまって述べられている書籍が発見できずに困っているところだったので、非常に参考になりました。 これまで、通称「バッタ本」と呼ばれているDNS & BINDが最も詳しいDNS本だったと思うのですが、バッタ本はBINDの本であって、DNSの本ではありませんでした。 そういう意味で、「実践DNS」は、技術としてのDNSに関してキッチリ書いてある良書だと思います。

豪華な執筆陣

「実践DNS」は、DNSやDNSSECに関して日本国内で考え得る最高レベルの執筆陣によって執筆されていると思いました。

著者は3名とも「.jp」のJPドメイン名の登録管理業務とDNSの運用を行っている株式会社日本レジストリサービス(JPRS)の方々です。 民田雅人氏(通称「みんみん」さん)は、Root DNSSECの鍵を管理する「Crypto Officers for the US West Coast Facility」の7人のうちの一人です(余談ですが、去年話題になった「WWWへのアクセス権を持つ7人」は大嘘なので信じてはいけません)。 森下泰宏氏(「森下/Orange」さん)は、DNS以外の話題を含めてインターネットインフラ業界で広く活動をされている方で、「djbdnsで作るネームサーバ徹底攻略」の執筆にも関わられています。 坂口智哉氏も、様々な講演等でDNSに関する発表を行われています。

インターネットの仕組みから解説

1章と2章の第1部は、基礎となるインターネットの仕組みが解説してあります。

3章から5章の2部は、入門編としてDNSの基礎知識が解説されています。

6章から9章の3部は、実践編としてプロトコル解説、digの利用方法、BIND設定例などが書かれています。

本書は、他の本と異なり、プロトコルや動作に関する解説が非常にキッチリしていて非常に勉強になると思いました。

カミンスキー型攻撃手法が付録C

本書のこだわりとして、「DNSキャッシュポイズニングとカミンスキーメソッドの概要」という内容が本文中ではなく付録になっている点が非常に印象的です。 (世の中では「カミンスキーアタック」という表現が使われることが多いのですが、カミンスキー氏は脆弱性発表者であり攻撃者ではないので、「実践DNS」では「カミンスキーメソッド」という表現をしているとのことでした。私もその話を聞いてから「カミンスキーアタック」という表現を極力避けるようにしています。)

「DNSSECはカミンスキーとは直接関係があるわけではない」という点が編成によって強調されていて、イイ感じです。

DNSSECというと、どうしてもカミンスキー型攻撃手法と組み合わせて論じたくなりますが、DNSSECは昔からある話題です。 そもそも、DNSSECの標準化が開始されたのが1994年です(参考:Impress Internet Watch: 1通の論文から始まったDNSSECの歴史、ランチセミナーで紹介)。

平行線が続いていた議論を一気に進める効果があったという要素の一つであったとしても、技術書としては別に本筋ではないという思い切りが良いと思いました。

おまけ、というか、個人的なモヤモヤ

本書は非常に良い本だと思いましたし、この本を良く読んで自分は勉強すべきだと強く思いました。 ただ、個人的には、本書の副題でもあるDNSSECそのものが良いのかどうかに関しては良くわかりません。

レコードの正当性を担保できたとしても、Webだけを考えれば結局はSSLに頼る形は変わらなさそうです。 さらに、現時点ではアプリケーションレベルでDNSSECによる確認が行われたどうかを得る一般的なAPIが無いので、たとえばFirefoxに「DNSSECでFQDNを確認できた」という意味を表す鍵マークみたいなものが登場するかというと微妙です(追記:val_getaddrinfoがあるそうです。知りませんでした。今度調べておきます)。

「DNSメッセージがTCPでやり取りされるようになったときには?」という視点も個人的にはあります。 長年議論され続けたDNSSECが一気に推進へと傾いたのは、2008年にBlackHatで発表されたカミンスキー型攻撃手法があまりに衝撃的だったからという側面がありますが、DNSSEC情報の追加によってメッセージ全体が大きくなりUDPパケット一つに収まりきらずにUDP 53ではなく、TCP 53で通信する場合が増えることを考えると、TCPで通信すればカミンスキー型攻撃手法は使えないという点に視点が向きます。 「IPv6とDNSSECによって53番TCPが使われるようになるけど、カミンスキー型攻撃手法を無効化したいだけであるならば、そもそもDNSSECを使わずにUDPからTCPに変えるだけでよかったのでは?」という視点です。

しかし、DNSSECそのものは、セッションハイジャック的なことが簡単なUDPでの通信をセキュアにすることが本筋ではなく、暗号技術を使って各レコードの正当性を保証するものなので、UDP vs TCPな議論とは実際は無関係です。 とはいえ、「UDPであること」が根本的な原因の一つとなってカミンスキー型攻撃手法が登場し、それが大きな原動力となってDNSSECは一気に推進されました。

さらに、IPv6やDNSSECによるDNSデータ増大によって、エニーキャストTCPでのDNS情報やり取りを真面目に考えなければならない時期に来ている可能性を考えると、「え!?これからの時代のDNSはTCPがナウい?」みたいな別の角度な考えも湧きます。 エニーキャスト+TCPを気持ち悪いと言う人も多いのですが、「TCPとエニーキャストは相性が悪いというのはFUDだ!」という2006年のNANOG37発表(Operational experience with TCP and Anycast)での意見もあり、「本当のところはどうなんだろう?」という興味もあります。 あとは、「TCPだと負荷が」という話がありそうですが、どちらにせよWebサーバのように膨大なTCPセッション数を管理できるDNSサーバが必要な環境が今後は増えて行きそうな気がしています。

DNSSECは運用が非常に難しそうなイメージがあり、今後ノウハウが溜まって行くまで二の足を踏む事業者も多そうだという感想も持っています。 様々な方々の話を聞くと、IPv6対応同様に「様子見」と答える運用者が非常に多い印象があります。 そういった背景もあって、DNSSECを正確に紹介するために「実践DNS」が執筆されたのではないかとも思います。

実際、DNSSECの世界的な運用開始後にTLDごと落ちてしまった事件がいくつか発生していますし、DNSSECが関連するソフトウェア脆弱性報告も増えています。 しかし、そういう意味では、IPv6も同様に運用開始時期には事故も色々発生しますし、使われていないソフトウェアに含まれる脆弱性は一般的な問題でありDNSSECそのものの問題とまでは言えません。

「様子見」と答える人が多い理由として、DDoSの問題もあります。 DNSSECのデータが大きい事と、計算処理が重くなることから、通常のDNSよりもDDoSに弱くなる可能性や、DNSアンプリファイアーアタックに利用されてしまう問題を指摘する人もいます。

とはいえ、DNSSEC技術は、それなりのニーズがあって生まれてますし、今までがあまりに信頼性が無さ過ぎたという側面も否定できません。 DNSSECそのものが全く駄目な物だとは思ってませんし、運用ノウハウが積み重なったりすることで「心配のし過ぎだった」という結論に達するかも知れないとも思います。

ということで、DNSSECは良くわかりなくて、まだまだ色々と勉強しないと何とも感想が定まらないので、「実践DNS」を良く読んで勉強したうえで、色々な情報をさらに集めて勉強したいと思う今日この頃です。

最近のエントリ

過去記事

過去記事一覧

IPv6基礎検定

YouTubeチャンネルやってます!