Azure DNSでDNSSECがGAしたので試してみた

【Amazon.co.jp限定】バッファロー WiFi ルーター無線 LAN Wi-Fi5 11ac ac1200 866+300Mbps IPv6 WPA3 デュアルバンド日本メーカー【 iPhone 16e / 16 / 15 / 14 / Nintendo Switch / PS5 動作確認済み】エコパッケージ WCR-1166DHPL/N

(462)

￥3,380 (2025年4月25日 13:08 GMT +09:00 時点 - )

モバイルモニタースタンド VESAホルダー - マグネット VESA 75 モニタスタンド 10" 10.1 10.5 11 11.6 12 12.5 13.3 13.4 14 15.6 17 17.3 18 18.5 インチ磁石 360度回転置き台 Feising FS07A

(29)

￥3,909 (2025年4月25日 13:08 GMT +09:00 時点 - )

【2025正規MFi認証品】i-Phone 充電ケーブルライトニングケーブル純正品質【1M/2M 各２本】充電器ケーブル 2.4A急速充電 USB 充電コード高速データ転送断線防止高耐久 i-Phone 14/14 Pro/13/13 Pro/12/11/X/8/8plus/7/6/iPad 各種対応

(2103)

￥898 (2025年4月25日 13:07 GMT +09:00 時点 - )

AzureでDNSSECサポートがGAされたので、DNSSECの仕組みを理解しながら試してみました！
DNSサーバーへの問い合わせ結果をデジタル署名を使って検証する技術で、真正性（正規のDNSサーバーが応答した値であること、値が改竄されていないこと）を確保することができます。
DNSキャッシュポイズニングなどの攻撃に対する対策となりうるものですが、サーバーとクライアントの両方がDNSSECに対応している必要があります。
まずはDNSSECの設定は行わず、Azure DNSでAレコードを登録して問い合わせ結果を確認します。
Azure DNSでDNSSECの設定を有効化して動作を確認します。
最後にDNSSECによる署名の発行と検証の仕組みについて解説します。

 PoC構成Azure DNS Public Zoneでcontoso.comゾーンを作成します。
まずはDNSSECは設定せず、Aレコードだけ登録しておきます。

!
記事に掲載しているドメイン名は一律contoso.comに置換しています。
実際の検証はcontoso.comではなく、別のドメインを使用しています。
なお、ドメインはAWSのRoute53で購入しており、ネームサーバーとしてAzure DNSを使っています。
AzureでもApp Service Domainを使うとドメインの購入ができるのですが、DNSSECの設定で必須となるレジストラを通した上位ゾーン（例えば.com）へのDSレコード登録に対応していません。
AWSのRoute53は上位ゾーンへのDSレコード登録に対応しているので、ドメインだけ購入してAzure DNSのPublic ZoneでDNSレコードをホストするという形をとっています。
https://zenn.dev/mrt/articles/a2e3573c392b62

 動作確認（DNSSEC設定なし）digコマンドでAレコードの問い合わせを行うと、Azure DNSに設定している値（10.0.0.1）が取得されます。

$ dig contoso.com. @8.8.8.8

; > DiG 9.16.50 > contoso.com. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER
!
digコマンドで@8.8.8.8を指定し、DNSSECに対応しているgoogleのフルサービスリゾルバ（キャッシュDNSサーバー）を使って動作確認をしています。
まだDNSSECの設定は行なっていないので、digコマンドにDNSSECデータを要求する+dnssecオプションをつけても、取得される内容に変化はありません。

$ dig +dnssec contoso.com. @8.8.8.8

; > DiG 9.16.50 > +dnssec contoso.com. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER

 DNSSECの有効化
 Azure DNSでDNSSECを有効化Azure PortalでDNSゾーンを開き、DNSSEC を有効にするをオンにします。Azure DNSの設定としてはこれだけでOKです。

有効化すると、署名の発行と検証に使用するキーペア（秘密鍵と公開鍵）が２組（ZSKとKSK）作成されます。（ZSKとKSKについては後で解説します）
親ゾーン（.com）にDSレコードとしてKSK公開鍵のハッシュを登録するまでは、状態表示が署名済みですが委任されていませんとなります。（DSレコードについても最後に解説します）

親ゾーンのDSレコード登録に使用するKSK公開鍵も表示されているので、控えておきます。（Azure PortalのPublic key欄）

!
公開鍵やRRSIGレコード、DNSKEYレコードは性質上公開される値なので特にマスクはしていません。

 ドメインのレジストラで上位ゾーンにDSレコードを登録親ゾーン（.com）にDSレコードとしてKSK公開鍵のハッシュを登録します。
今回はDSレコードの登録に対応しているレジストラのAmazon Route 53でドメインを購入しているので、AWS Management ConsoleでDSレコードの登録を行います。
!
親ゾーンへのDSレコードの登録方法はレジストラによって異なります。
ドメインはAWSのRoute53で購入しているので、AWSマネジメントコンソールのRoute53で取得したドメインを開き、DNSSECキーの追加を押下します。

Azure DNSでDNSSECを有効化した際に表示されていたKSK公開鍵の値をコピペして追加すると、そのハッシュ値が生成されDSレコードとして親ゾーン(.com)に登録されます。

digコマンドで親ゾーン（.com）のDSレコードを参照すると、KSK公開鍵のハッシュ値が登録されたことが確認できます。

$ dig @"$(dig +short com. NS | head -n 1)" +noall +answer +norecurse +nosplit contoso.com. DS
contoso.com.             86400   IN      DS      55790 13 2 ED4E3A5BB244F5807CA5D2149EB69B29C3F71C386395C342E4461F483A1DD69B

!
DSレコードに登録されるのは公開鍵ではなく、公開鍵のハッシュ値です。

 Azure DNSでDNSSECの状態を確認Route53でDSレコード登録後にAzure DNSのDNSSECパネルを開くと、状態が署名済みで、委任が確立されましたに変わったことが確認できます。

 動作確認（DNSSEC設定あり）digコマンドにDNSSECデータを要求する+dnssecオプションをつけて実行してみると、flagsがflags: qr rd ra;からflags: qr rd ra ad;に変わっており、adが出力されるようになりました。
また、ANSWER SECTIONでRRSIGレコードも取得されています。
flagsのadはAuthentic Dataの略で署名の検証に成功したことを示します。
RRSIGレコードはリソースレコード（Aレコード）に対する署名で、これを用いて問い合わせ結果の真正性を検証しています。

$ dig +dnssec contoso.com. @8.8.8.8

; > DiG 9.16.50 > +dnssec contoso.com. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER
権威DNSサーバーの応答がなりすまされている状態を再現するため、親ゾーン（.com）のDSレコードに不適切なハッシュを登録してみます。
その状態でdigコマンドを実行すると署名の検証に失敗するので、flagsにadが出力されず、statusもSERVFAILとなります。

$ dig +dnssec contoso.com. @8.8.8.8

; > DiG 9.16.50 > +dnssec contoso.com. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER
どのような仕組みで、署名の発行と検証が行われたのかを解説します。

 DNSSECで使用されるDNSレコードまず、DNSSECでは通常のリソースレコード以外に、RRSIGレコードとDNSKEYレコードが使用されます。
リソースレコード
通常のDNS問い合わせで応答しているAレコードなどのDNSサーバーで管理しているレコード。

RRSIGレコード（DNSSEC専用）
リソースレコードの署名。
署名対象のレコードによって使用する秘密鍵が異なる。
リソースレコードの署名にはZSK秘密鍵を使用する。
DNSKEYレコードセットの署名にはKSK秘密鍵を使用する。

DNSKEYレコード（DNSSEC専用）
RRSIGレコードの検証に使用する公開鍵。
DNSKEYレコードは、ZSK公開鍵とKSK公開鍵の２レコードある。

 ２種類（ZSK、KSK）のキーペア（秘密鍵と公開鍵）ややこしいのですが、DNSSECでは２種類（ZSK、KSK）のキーペアが使用されます。
署名対象のレコードによって、使用するキーペアが異なります。

digコマンドでDNSKEYレコードの問い合わせを行うと、ZSKとKSKの公開鍵を確認することができます。
RRSIGレコードはDNSKEYレコードセットの署名です。KSKのDNSKEYレコードと、RRSIGレコードのkey id 55790が一致しており、KSKで署名されていることが分かります。

$ dig +dnssec +multi contoso.com. dnskey @8.8.8.8

; > DiG 9.16.50 > +dnssec +multi contoso.com. dnskey @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER

 DNSSECの流れDNSSECを有効化すると、権威DNSサーバー（Azure DNS contoso.comゾーン）上に２種類（ZSK、KSK）のキーペア（秘密鍵と公開鍵）が作成されます。
フルサービスリゾルバ（キャッシュDNSサーバー）は、権威DNSサーバー（Azure DNS contoso.comゾーン）にリソースレコード（Aレコードなど）の問い合わせを行います。
権威DNSサーバーは、ZSK秘密鍵を用いて問い合わせレコードの署名を作成し、署名をRRSIGレコードとして問い合わせ結果と併せて応答します。
フルサービスリゾルバ（キャッシュDNSサーバー）は、権威DNSサーバー（Azure DNS contoso.comゾーン）にDNSKEYレコードの問い合わせを行い、DNSSECのZSK公開鍵を取得します。
フルサービスリゾルバ（キャッシュDNSサーバー）は、公開鍵を用いてRRSIGレコードの署名を検証します。
このような流れで、RRSIGレコードとDNSKEYレコードを組み合わせて、正規のDNSサーバーが応答した値であること、値が改竄されていないことを検証しています。

 DNSKEYレコードの公開鍵の真正性DNSKEYレコードで署名の検証に使用する公開鍵を受け取るのですが、RRSIGレコードもDNSKEYレコードもどちらも同じDNSサーバーから取得しています。
もし、偽装されたDNS応答であったとしても、DNSKEYレコードを用いたRRSIGレコードの検証は成功してしまうことになります。
そのため、公開鍵そのものも正規のものであるかを検証する必要があります。
ZSK公開鍵を含むDNSKEYレコードセットは、KSK秘密鍵で署名され、KSK公開鍵で検証されます。
KSK公開鍵の検証には、上位ゾーン（例えば.com）に登録しておいたDSレコードを使用します。
KSK公開鍵のハッシュを上位ゾーンにDSレコードとして登録しておき、DNSKEYレコードのKSK公開鍵がDSレコードのハッシュと一致していることを検証することによって、公開鍵の真正性を担保します。

親ゾーンのDSレコードもRRSIGレコードでまた検証して…と、これをルートゾーンまで遡って検証していく仕組みになっています。これを信頼の連鎖と言うそうです。

 DNSSECのテストhttps://dnsviz.net を使うと、対象ドメインからルートゾーンまでのDNSSEC信頼チェーンが正しく構成できているかをテストすることができます。

 最後にDNSSECの仕組みを理解しながら、Azure DNSで実際に試してみました！
Azure PortalでDNSSECの有効化は簡単に行えますが、キーペアのロールオーバー、特にKSKを置き換える場合は親ゾーンのDSレコードの更新など、実際の運用で使うのは結構大変そうな印象を受けました。
Azure DNSにはまだ他にもいろいろな機能があるので、今後も試しながら更に理解を深めていきたいと思います！