DNSのセキュリティ2：DNSSEC、DoT、DoHなど

情報処理安全確保支援士試験の対策として、DNSセキュリティについて解説します。2回目はDNSSEC、DoT（DNS over TLS）、DoH（DNS over HTTPS）、サブドメインテイクオーバーです。

１．DNSSEC

（１）DNSSECとは

DNSSEC（DNS Security Extensions）は、DNS応答にディジタル署名を付与する仕組みです。これにより、DNSキャッシュサーバは権威DNSサーバから受け取った応答が改ざんされていないかを検証できます。結果として、利用者は正しい応答を受け取ることが保証されます。なお、DNSSECの目的は通信内容の暗号化ではなく、「応答の真正性と完全性」を確認することにあります。
参考ですが、以下の資料が、とても詳しいです。
https://www.nic.ad.jp/ja/materials/iw/2012/proceedings/t9/t9-Funato.pdf

（２）DNSSECの目的

以下の丸の2つが目的です。
⭕ DNS応答の真正性
・ 「この応答は確かに、seeeko.com の権威DNSサーバが発行したものである」
　→ DSレコードとKSKの仕組みで、上位ゾーンからの信頼の連鎖により確認します。

⭕ 完全性の保証（＝改ざん検出）
・ 「応答データ（Aレコードなど）が途中で書き換えられていない」
　→ RRSIG署名をZSK公開鍵で検証し、署名が一致すれば改ざんなし。

❌通信の暗号化（内容が見られないこと）は保証しません。
・ DNSSECは署名による検証だけで、暗号化はしません。
・ 通信経路の暗号化は DoT（DNS over TLS）や DoH（DNS over HTTPS）が担当します。

（３）DNSSECを実装する方法

DNSSECを実装するには、キャッシュDNSサーバ、コンテンツDNSサーバの両方に、DNSSECの設定を有効にする必要があります。
（試験で問われませんが参考までに）、キャッシュサーバ側では、named.confのoptionsにて以下を記載します。　　　　　　　　　　　　　　　　　　　　　　　　　　　

（４）登場人物

以下にあるように、❶キャッシュDNSサーバ、❷権威DNSサーバ（seeeko.com)、❸上位の権威DNSサーバ(.com)、があります。

それぞれ、どんな情報（主にDNSレコード）を持つかを整理します。

❶キャッシュDNSサーバ
キャッシュを持つ

❷seeeko.comの権威DNSサーバ
保持するDNSレコードとしては、以下があります。これがわかりづらいです。いっぱいあるんです。
a)DNSKEYレコード
・DNSSECで使用する公開鍵を格納する。
・ZSK（Zone Signing Key、ゾーン内のA、MXレコードなどを署名する公開鍵）、KSK（Key Signing Key、DNSKEYに署名する公開鍵）の2種類がある。

b)RRSIG
・AやMXなどの各レコードに対して付与されるディジタル署名。
・署名対象のレコードごとに1つずつ存在する。

c)各種リソースレコード：A / MX / CNAME など

❸上位（.com）の権威DNSサーバ
a)DSレコード
下位ゾーン（例：seeeko.com）のKSKのハッシュ値をDSとして登録し、下位ゾーンの鍵（KSK）の正当性を保証する。

（５）DNSKEYリソースレコード

すでに記載しましたが、ここでは、DNSSECの中核をなすDNSKEYについて、改めて説明します。
DNSSECでは、「公開鍵暗号」を使って、DNSの情報が正しい（改ざんされていない）ことを確認できるようにします。このとき使う鍵は以下の2つです。
・🔒 秘密鍵 … 権威DNSサーバが持ち（もちろん非公開）、DNSのレコードに署名を付与する
・🔑 公開鍵 … DNSKEYリソースレコードに登録して公開される。キャッシュDNSサーバは、受け取ったDNSのレコードとその署名が正しいかを検証する際、この公開鍵を取得する。

試しに、digコマンドでDNSKEYを調べてみよう。
※nslookup ではできない。また、ipaやGoogleではDNSKEYリソースレコードが出てこないので、jprs.jpで実験した。覚える必要は全くないが、256と書いてある方がZSK (Zone Signing Key)で、署名に使われる公開鍵。257は、KSK (Key Signing Key)で、「ゾーンの署名鍵（ZSK）が本物であること」を保証するために使われる公開鍵です。忘れてください。

（６）DNSSECによる検証の流れ

繰り返しですが、DNSSECでは、DNSキャッシュサーバが、権威DNSサーバから受け取った応答が改ざんされていないかを検証します。以下の図を見てください。

①PCがキャッシュDNSサーバにDNSの問い合わせをします。例）「www.seeeko.comのIPアドレスを教えてください」
②キャッシュDNSサーバは、DNSSEC検証を有効（DOビットをセット）にした上で、権威DNSサーバにDNSの問い合わせをします。
③権威DNSサーバは、ゾーン情報（例：www.seeeko.comのAレコード）に秘密鍵（ZSKの秘密鍵）でディジタル署名を行い、その署名結果（＝RRSIG レコード）を生成します。そして、権威DNSサーバは、A レコードと署名（対応する RRSIG レコード）を応答として返します。
※RRSIG レコードは毎回動的に署名を生成するわけではなく、有効期限が切れるまで保持され、定期的に再署名されます。

④キャッシュDNSサーバは、署名の検証に必要な公開鍵（DNSKEY レコード、ZSK の公開鍵）を、権威DNSサーバに問合せて受け取ります。

⑤キャッシュDNSサーバは、受け取った公開鍵（DNSKEYレコード、ZSKの公開鍵）を使って、手順③で受け取った署名（RRSIG）が、正しい署名であるかを検証します。

（７）DNSKEYの正当性の確認

😯受け取ったDNSKEY（ZSKの公開鍵）が本物かどうかは、どうやって確認するのですか。

🙍‍♂️たしかに、偽のサーバから「偽の公開鍵」をもらってしまえば、いくら検証しても意味がありません。

DNSSECでは、公開鍵（DNSKEY）の正当性を上位のDNSサーバ（親ゾーン）が保証します。具体的には、上位ゾーンにDSレコード（Delegation Signer Record）という署名情報があり、下位ゾーンであるseeeko.comのDNSKEYのハッシュ値が登録されています。

キャッシュDNSサーバは、取得した seeeko.com の DNSKEY のうち、
「フラグが257（＝KSKであって、ZSKではない））」の公開鍵を選び、そのハッシュ値を計算します。計算結果が、親ゾーンの DS レコードに書かれた値と一致すれば、このKSK公開鍵は、親ゾーン（.com）が認めた本物だと判断できます。
なのでお気づきかと思いますが、この説明は、ZSKの公開鍵の正当性ではなく、KSKの公開鍵の正当性を確認する方法です。

（８）KSKの必要性

🙁先の（６）の話、何でこんな面倒なことをするの？ KSKがなくても、ZSKとDSがあればいいのでは？

🙍‍♂️確かに。そして、DSがZSKのハッシュ値を持てばいいと思います。

なぜこうしないのかというと…、DSはKSKのハッシュ値でした。これをZSKのハッシュ値にすると、運用がかなり大変になるのです。
なぜなら、Aレコードなどは大量にあり、頻繁に変わることもあります。そうすると、上位の権威DNSサーバで、その都度DSレコードを書き換える必要があります。大変ですよね。
そこで、ZSK（頻繁に変わる）と KSK（あまり変えない）を分離し、親の権威DNSサーバが追うのは KSKだけ にしたのです。

（９）KSKの必要性と、ZSKの正当性の確認

キャッシュDNSサーバは、Aレコード＋その署名（ZSKで署名）を検証する前に、その検証に使うDNSKEY（ZSKとKSKの公開鍵のセット）を取得した瞬間に、受け取ったZSKが正しいかを検証します。
この検証に使うのが、KSKです。
流れとしては、以下です。
① キャッシュDNSサーバが「www.seeeko.comのIPアドレス」を問い合わせると、Aレコード＋RRSIG(ZSKで署名されたデータ）を受け取る。

② キャッシュDNSサーバ「この署名を検証」するのですが、署名検証にはZSKの公開鍵（DNSKEYレコード）が必要なので、seeeko.com の DNSKEYレコード を問い合わせる。

③ 権威DNSサーバから返ってくるものは、以下の2つ（レコードとしては3つ）
・DNSKEYレコード（ZSKとKSKの公開鍵）
・RRSIG（DNSKEYレコードをKSKで署名したデータ）

④ キャッシュDNSサーバはまず、受け取ったDNSKEY署名（RRSIG）を検証します。
具体的には、③で受け取った公開鍵（ZSK＋KSK）をハッシュし、上位ゾーン（.com）のDSレコード（KSKのハッシュ）と比較する。これで、ZSK＋KSKの正当性が確認できました。

（１０）DNSSECの有効範囲

😯PCとキャッシュDNSサーバ間はどうやってDNSSECをするのですか？

🙅‍♂️先の（５）図でも記載しましたが、PCとキャッシュDNSサーバ間のDNS問合せは、DNSSECを使いません。

PC側がDNSSECには対応していないので、使えないと思ってください。

Q.なぜPCとキャッシュDNSサーバの間はDNSSECの必要性が高くないのか？
↓
↓
↓
↓
↓
A.DNSキャッシュポイズニングなどの攻撃は、キャッシュDNSサーバに対して行われます。よって、キャッシュDNSサーバにて対策が行われれば一定の効果が期待できるのです。また、キャッシュDNSサーバとDNSSECを実施したとしても、すでに汚染されたレコードを受け取っていれば、その汚染されたレコードに対して署名をしてしまい、意味がありません。

　DNSSECの詳細な動作に関しては、過去の試験ではあまり問われませんでした。なので、言葉と概要だけ覚えておけばいいでしょう。

２．DNS over TLS とDNS over HTTPS

（１）DNS通信の課題

従来のDNSは、①暗号化が無いので盗聴される、②真正性と完全性の確保が
できない、という問題を抱えていました。
これを解決するために登場したのが以下の技術です。

①暗号化が無いので盗聴される
→DNS over TLS (DoT)やDNS over HTTPS (DoH)による通信経路の「暗号化」
②真正性と完全性の確保ができない
→DNSSECで、応答データの「真正性の確保」と「改ざん防止」

🙁DNS通信が盗聴されて困ることはあるのですか？

🙍‍♂️すごく困るというわけではないかもしれないけど、リスクはあるよね。

たとえば、DNSの通信内容から「どのサイトにアクセスしたか」が第三者に知られてしまう可能性があります。これにより、利用者の行動履歴や興味関心といったプライバシー情報が漏洩するおそれがあります。特に、公衆無線LANのような不特定多数が利用する環境では、通信内容を盗み見られるリスクが高まります。

（２）DoT / DoH の概要

DNSは通常53番ポートを使って非暗号の通信を行います。DNS通信経路を「暗号化」する技術がDoTとDoHです。それぞれ説明します。

❶ DNS over TLS（DoT）
・DNSメッセージを TLS（Transport Layer Security） で暗号化して送信。
・ポート番号：853　
・通常、ファイアウォールのポートで853番は空いていないでしょうから、不便だという声もあります。ですが、AndroidスマホでDoTの方が進んでいます。

❷ DNS over HTTPS（DoH）
・DNSメッセージを HTTPS通信（TLS＋HTTP） にカプセル化して送信。
・ポート番号：443（通常のWeb通信と同じ）
・DoTと違って、企業のファイアウォールをわざわざ開けなくてもいいという便利さもあります。一方で、情報システム部からすると、「Webサイトを見ているのか、DNSを引いているのか」区別がつきません。そのため、管理がしずらいという声もあります。

暗号技術と言いましたが、TLS を使うので サーバ証明書にて、DNSサーバの認証は行うことはできます。

😯じゃあ、「問合せ内容（検索したいドメイン）」と「証明書」の突き合わせができるのですね？

🙅‍♂️いえ、その確認はしません。 確認するのは、あくまで「接続しようとしているDNSサーバ」と「証明書」の一致です。

（３）DoT / DoHの有効化

・この技術を利用するには、クライアント（スタブリゾルバ）と DNS サーバ（リゾルバ／キャッシュ DNS サーバ）双方が DoT または DoH に対応している必要があります。
・Windows クライアント（Windows 10 以降）は、DNS over HTTPS（DoH）がサポートしていますが、 DoTはの「テスト機能」が導入されているレベルのようです。
・また、スマートフォンも、DoTやDoHの対応は進んでいるのですが、まだまだ普及したとまでは至っていないように思います。
・DoT（DNS over TLS）や DoH（DNS over HTTPS）を使うと、クライアント（スタブリゾルバ）はポート53ではなく、TLSやHTTPSのポート（主に443など）でキャッシュDNSサーバに対してDNS問合せを行います。

（４）DNSSECとの違い

 😯DNSSECもありましたよね？

🙍‍♂️DNSSECとは目的が違んだ

違い❶：DNSSECはディジタル署名による「認証」を目的としている。通信の暗号化はされない。→DoTやDoHは暗号
違い❷：DNSSECは、キャッシュDNSサーバ（フルサービスリゾルバ）と、コンテンツDNSサーバの間での認証強化。→DoTやDoHはクライアントPC（スタブリゾルバ）とキャッシュDNSサーバ（フルサービスリゾルバ）の間 

（５）権威DNSサーバとの間でのDoTやDoH

🙁フルリゾルバサーバと権威DNSサーバの間はDoTやDoHは有効にできないのですか？

🙋‍♂️いえ、できますよ。

でも、DNSの問合せというのは、誰でも問合せできるものですから、暗号化する必要性はあまり高くありません。キャッシュDNSサーバからの問合せであれば、個人が特定できないので、プライバシーの問題も関係ないことでしょう。DoTやDoHを有効にすると、UDPではなく、TCPの通信になるため、権威DNSサーバの負荷が高くなります。レスポンスが遅くなるだけです。また、DNSSECがあるので、改ざん検知は可能なので、それで充分と考えていると思います。

３．その他

（１）ドメインのドロップキャッチ

・企業で使用したドメインを手放すと、第三者に再取得（ドロップキャッチ）され、そのドメインがフィッシングサイトやアダルトサイト等に転用される事例がある。
・デジタル庁「Webサイト等の整備及び廃止に係るドメイン管理ガイドライン」には、「旧ドメイン運用停止後も一定期間、旧ドメインを保持し（中略）対策を講じた上で、廃止手続を行う」とある。

４．穴埋め問題（オリジナル問題）

↓
↓
↓
↓
↓
↓
↓
↓

ア ディジタル署名
イ 権威DNSサーバ（コンテンツDNSサーバ）
ウ 完全性（＝改ざんされていない）
エ 真正性（＝正規のサーバからの応答）
オ DoT（DNS over TLS）
カ DoH（DNS over HTTPS）
キ DNSKEY
ク TLS（Transport Layer Security）
ケ HTTPS（TLS＋HTTP）
コ 443
サ キャッシュDNSサーバ（フルリゾルバサーバ）
シ CDN
ス CNAME
セ ホスト名
ソ サブドメインテイクオーバー

５．過去問：午前

（１）過去問❶（H27SC春午前Ⅱ）

↓
↓
↓
↓
↓
正解はア

６．過去問：午後

（１）過去問❶　H22SC春午後Ⅱ問1

↓
↓
↓
↓
↓
a　DNSSEC
b　ディジタル署名

（２）過去問❶　R3春SC午後1問2

↓
↓
↓
↓
↓
↓
↓
↓
↓
解答例　f：オ（スタブリゾルバ）
　　　　g：カ（フルサービスリゾルバ）

（３）過去問❸　R7春SC午後問4

設問1で言うと、解答は以下
★問題は別途掲載★

設定を変更したサーバ名：権威DNSサーバ
変更内容：終了したサブドメインのCNAMEレコードを削除する。