DNSの名前解決とその安全性を支える技術

ドメイン名からIPアドレスを引く名前解決は、Webアクセスやメール配送の前段にあり、ほとんどの通信がここを通ります。この入口が偽の応答を受け入れると、利用者は正しいドメイン名を入力したまま攻撃者の用意したサーバへ誘導されます。本記事は、名前解決がどの順序で進むかを整理したうえで、応答の偽造を許す機構と、それを抑える技術を分けて説明します。技術ごとに何を守り何を守らないかが異なるため、その境界を一次情報に沿って明確にします。

名前解決でドメイン名がIPアドレスに変換される流れ#

利用者の端末がドメイン名を入力すると、解決の起点になるのはOSに組み込まれたスタブリゾルバです。スタブリゾルバ自身は完全な探索を行わず、設定された問い合わせ先へ「このドメイン名のアドレスを教えてほしい」という再帰問い合わせを一度だけ投げます。問い合わせ先になるのが、プロバイダや社内に置かれるフルサービスリゾルバ(キャッシュDNSサーバとも呼びます)です。

フルサービスリゾルバは、答えを自分のキャッシュに持っていなければ、ドメイン名を末尾から順にたどって権威サーバへ問い合わせます。最初にルートサーバへ尋ね、example.comであれば.comを管理するTLDサーバの所在を得ます。次にそのTLDサーバへ尋ね、example.comの権威サーバの所在を得ます。最後にその権威サーバへ尋ねて、目的のIPアドレスを含む応答を受け取ります。この一連の探索を反復問い合わせと呼びます。

得られた応答を、フルサービスリゾルバはTTL(Time To Live)で指定された期間だけキャッシュに保持します。同じドメイン名への次回の問い合わせはキャッシュから即座に返るため、ルートやTLDへの負荷が下がり、応答も速くなります。このキャッシュが性能を支える一方で、後述する攻撃の標的にもなります。

ここまでの問い合わせと応答は、初期のDNSでは暗号化されないUDPで運ばれます。応答が正しい相手から来たことを受信側が確かめる手段は、問い合わせに付けた16ビットのトランザクションID(クエリID)と、問い合わせ元のIPアドレスやポートの一致だけです。この確認の弱さが、次に述べる偽造の余地を生みます。

偽の応答を先に注入するキャッシュポイズニング#

DNSキャッシュポイズニングでは、攻撃者がフルサービスリゾルバに対し、正規の権威サーバより先に偽の応答を届けてキャッシュを汚します。攻撃者はまず標的のリゾルバに目的のドメイン名を解決させ、リゾルバが権威サーバへ問い合わせを出した直後に、自分が用意した偽の応答を大量に送り込みます。受信側はトランザクションIDと送信元の情報が合致した応答を正しいものとして受け入れるため、攻撃者がこれらを当てれば偽のIPアドレスがキャッシュに書き込まれます。汚染されたキャッシュは、TTLが切れるまでその後の利用者全員へ偽の答えを返し続けます。

偽の応答が正規より先に届き、かつIDと送信元が合致したときに、この攻撃は成立します。攻撃者は正規の応答が戻る前の短い窓の中で、推測した値を持つ応答を送りつけるしかありません。トランザクションIDは16ビットしかないため、当てるべき値の範囲が狭ければ総当たりが現実的な時間で成功してしまいます。

この弱点を大きく広げたのが、2008年にDan Kaminsky氏が公表した手法です。従来はキャッシュにある記録の有効期限切れを待つ必要がありましたが、Kaminsky氏の手法はaaa.example.com、bbb.example.comのように存在しないサブドメインを次々に問い合わせます。サブドメインごとにキャッシュミスが起き、攻撃者は何度でも新しい攻撃の窓を作り出せます。さらにこの手法の偽応答は、単一の偽IPアドレスを返すだけでなく、対象ドメインの権威サーバを指すNSレコードなど偽の権威情報をあわせて注入できます。これが通れば、攻撃者は対象ドメインの解決全体を自分の管理下へ向けられます。JPCERT/CCは2008年に、多くのDNSサーバ製品が影響を受けるとして注意喚起を出しました。

この問題への当面の緩和として広まったのが、送信元ポートのランダム化です。問い合わせの送信元UDPポートを毎回ランダムに選べば、攻撃者は16ビットのトランザクションIDに加えてポート番号も当てる必要が生じ、推測すべき範囲が大きく広がります。JPCERT/CCの注意喚起も、各製品でのポートランダム化を含む対策の適用を促しました。ただしこれは攻撃の成功確率を下げる緩和であって、応答の真正性を暗号的に検証する仕組みではありません。経路上で問い合わせと応答を観測できる攻撃者や、ポートのランダム性を損なう環境では、緩和の効きが弱まります。

キャッシュポイズニングの脆弱性と、送信元ポートのランダム化を含む対策については、JPCERT/CCの2008年の注意喚起(JPCERT/CC)を参照しました。

DNSSECが保証する真正性と完全性、保証しない機密性#

DNSSEC(DNS Security Extensions)は、推測の難しさに頼る緩和とは異なり、権威データへ電子署名を付けることで応答の正しさを暗号的に検証できるようにします。RFC 4033は、DNSSECが提供するのはデータ出自の認証(応答が正しいゾーンから来たこと)とデータの完全性(伝送途中で改ざんされていないこと)であると定めています。検証する側のリゾルバは、応答に付いた署名を、信頼の連鎖をたどって得た鍵で確かめ、署名が合致しなければその応答を拒否できます。

信頼の連鎖は、上位ゾーンが下位ゾーンの鍵を裏書きする形で組み立てられます。各ゾーンは自分の記録に署名し、その検証鍵を公開します。親ゾーンは子ゾーンの鍵の指紋を保持して署名するため、ルートを起点に.com、example.comへと署名の連鎖をたどれます。連鎖のどこか一つでも署名の検証に失敗すれば、リゾルバはその応答を正しいものとして扱いません。これにより、キャッシュポイズニングで注入された偽の応答は、正規の署名を持たないため検証段階で弾かれます。

一方で、DNSSECが守らないものをRFC 4033は明示しています。DNSSECは機密性を提供する設計ではなく、問い合わせと応答の内容は依然として誰でも観測できます。また、サービス妨害に対する保護も提供せず、署名検証という新たな計算処理がかえって妨害の余地を増やす面もあるとされます。したがってDNSSECは「応答が本物か」を確かめる技術であり、「誰がどのドメイン名を引いたかを隠す」技術ではありません。

DoHとDoTが守る経路上の盗聴と改ざん#

DNSSECが応答の真正性を扱うのに対し、DNS over HTTPS(DoH)とDNS over TLS(DoT)が扱うのは問い合わせと応答が通る経路の保護です。初期のDNSは平文のUDPで運ばれるため、同じ経路上にいる第三者は、利用者がどのドメイン名を引いたかを観測でき、応答を書き換えることもできます。DoTを定めるRFC 7858と、DoHを定めるRFC 8484は、クライアントとリゾルバの間の通信をTLSで暗号化し、リゾルバを適切に認証したうえで、この経路上の盗聴と改ざんを防ぎます。なおRFC 7858はDoTにサーバ認証の強度が異なる運用プロファイルを認めており、保護の水準は認証のかけ方に依存します。DoTは専用のポート上でTLSを張り、DoHはHTTPS上にDNSの問い合わせを載せて一般のWebトラフィックに紛れさせます。

ここで守られる範囲は、クライアントとリゾルバの区間に限られます。リゾルバから先の権威サーバへの問い合わせは、この暗号化の対象ではありません。さらに、問い合わせを受け取るリゾルバ自身は問い合わせ内容を平文で扱うため、利用者がどのドメイン名を引いたかはリゾルバの運営者には見えます。暗号化された通信であっても、パケットの大きさやタイミング、接続先から推測される情報が残る点にも留意します。

DoHとDoTは、リゾルバから返ってきた応答が改ざんされていないことを経路の暗号化として保証しますが、その応答の内容が正しいゾーンに由来する本物かどうかまでは検証しません。応答の出自と完全性を暗号的に確かめる役割は、前節のDNSSECが担います。両者は守る対象が異なるため、片方をもう片方の代わりにはできません。経路の秘匿が要るならDoHやDoTを、応答の真正性が要るならDNSSECを用い、必要に応じて併用します。

運用での選び方#

開発者と運用担当が判断するのは、自組織が権威側か、解決側か、その両方かです。権威DNSを運用する側は、自ドメインのゾーンにDNSSEC署名を施すことで、外部のリゾルバが自ドメインの応答の真正性を検証できるようにします。解決側、つまりフルサービスリゾルバを運用する側は、DNSSEC検証を有効にして偽造応答を拒否し、あわせて送信元ポートのランダム化が効いていることを確認します。クライアントの通信経路を秘匿したい場合は、DoHやDoTに対応したリゾルバを選びます。

導入の順序は、守りたい対象から逆算します。応答の偽造が主な懸念であれば、解決側のDNSSEC検証の有効化が起点になります。自ドメインを他者から正しく検証してもらいたい場合は、権威側の署名とDS登録を進めます。経路上の盗聴が懸念であれば、DoHやDoTに対応したリゾルバへ切り替えます。これらは排他ではないため、要件が重なる場合は段階的に併用していきます。