こんにちは!イーゴリです。
インターネットの初期の設計時には、セキュリティが最優先されていませんでした。1970年代から1980年代にかけて、インターネットの前身であるARPANETやTCP/IPプロトコルが開発された当初、研究者たちは主に接続性とデータ交換の効率を重視していました。その結果、セキュリティの観点が後回しにされることになりました。
そのため、多くの基本的なインターネットプロトコルは、今日の基準から見るとセキュリティに脆弱な部分を抱えています。DNSもそのプロトコルの一つです。
DNSの脆弱性
DNSの通信は非暗号である
設計時に暗号化について考慮されていなかったため、DNS自体は暗号化されておらず、DNSリクエストとレスポンスは平文で送信されるため、第三者による盗聴や改ざんができてしまいます。レゾルバは受信した情報の正当性を問い合わせIDだけで判断していましたが、その長さはたったの2バイト(16ビット)でした。つまり、キャッシュを汚染するには、65536の値を総当たりでパケットを生成するなどして偽装すればよいという脆弱性が存在します。本来であればDNSを設計し直す必要がありますが、それは現実的ではないため、DNSSECがDNSプロトコルの補強として登場されました。
DNSSECは1997年に初めて公開され、2年後に次のバージョンが登場しました。現在使われているDNSSECのバージョンは2005年に発表されたものです。
DNSSECが守ってくれる攻撃パターン (キャッシュポイズニング攻撃)
キャッシュポイズニング攻撃とは攻撃者はDNSサーバーのキャッシュに偽のDNSレコードを挿入し、ユーザーを悪意のあるサイトに誘導します。この攻撃は、特定のDNSクエリに対して偽のレスポンスを送ることで実行されます。
DNSSECとは
DNSSEC(Domain Name System Security Extensions)は、DNS(ドメインネームシステム)に対するセキュリティ拡張機能で、DNSのデータの完全性と認証性を保証するための技術です。具体的には、DNSのレスポンスにデジタル署名を付与し、その署名を検証することで、DNSの応答が正当なものであり、改ざんされていないことを確認できます。
DNSSECの有効化前:
DNSSECの有効化後:
DNSSECを有効化することで、緑の矢印の改ざんから守られますが、クライアント端末 <-> フルサービスリゾルバの通信はDNSSEC外の話(DNS over HTTPS/DNS over TLSの話になります)となりますので、その点はご承知おきください。厳密に言えば、.comゾーンではすでにDNSSECが有効になっているため、今回はexample.comでDNSSECを有効化することで赤い枠の改ざんから守れます。
DNSSEC導入のメリット
- DNSSECを導入することで、キャッシュポイズニング攻撃から保護されます。
DNSSEC導入のデメリット
- KSKの鍵によってDNSのトラブルシューティングが難しくなります。KSKの問題が発生した場合、DNSSECのチェーン全体に影響を与える可能性があるため、問題の特定と解決が難しくなります。また、誤った設定やKSKの更新に失敗すると、ユーザーはDNSサービスにアクセスできなくなる可能性があります。
- Amazon Route 53には直接関係しませんが、過去にCVE-2023-50387 (KeyTrap)があったため、DNSSECソフト自体(PowerDNS, NLnet Labs Unbound, Internet Systems Consortium, BIND9など)の運用/管理が重要です。しかし、Amazon Route 53の場合、マネージドサービスのため、お客様のほうで何かしらのソフトの管理が不要ですので、Amazon Route 53のDNSSECはとても便利だと思います。
Amazon Route 53でDNSSECの有効化
DNSSECの有効化前の状態の確認
DNSVizで確認すると、DNSSECが有効化されていないと対象ドメインまで「DNSKEY」が下がらず、.com(対象)ゾーンで止まっている状態です。
対象ドメインのStatusに「INSECURE」と書いてあります。
whoisコマンドで確認すると下記の結果になります。
$ whois example.com | grep -i dnssec DNSSEC: unsigned DNSSEC: unsigned DNSSEC: unsigned
DNSSECを有効にする
KSKのキーの作成
今回は新規鍵の作成をします。自分のCMKを使う場合、下記の要件をご確認ください。
完了したら、DNSSEC 署名ステータスが「署名」になり、「キー署名キー (KSK) 」にKSKキーが表示されます。
KSKのCMKキーに下記のキーポリシーが作成されます。
{ "Version": "2012-10-17", "Id": "dnssec-policy", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<アカウントID>:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow Route 53 DNSSEC Service", "Effect": "Allow", "Principal": { "Service": "dnssec-route53.amazonaws.com" }, "Action": [ "kms:DescribeKey", "kms:GetPublicKey", "kms:Sign" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "<アカウントID>" }, "ArnLike": { "aws:SourceArn": "arn:aws:route53:::hostedzone/*" } } }, { "Sid": "Allow Route 53 DNSSEC to CreateGrant", "Effect": "Allow", "Principal": { "Service": "dnssec-route53.amazonaws.com" }, "Action": "kms:CreateGrant", "Resource": "*", "Condition": { "Bool": { "kms:GrantIsForAWSResource": "true" } } } ] }
DSレコードの作成
[DS レコードを作成するための情報を表示]をクリックすると、DS レコードの情報が表示されます。[信頼チェーンを確立]をクリックします。
ホストゾーンの親ゾーンでDSレコードを作成しないといけません。私のドメインが「example.com」のため、.comゾーンが登録されているドメインレジストラでDSレコードを登録します。
親ゾーンの管理レジストラによって[Route 53 レジストラ]と[別のドメインレジストラ]のどちらかをご参照ください。
Route 53 レジストラ
[登録済みドメイン] > 対象ドメイン > [DNSSECキー] > [追加]をクリックし、DSレコードを登録します。
- キータイプ:257 KSK
- アルゴリズム:13 – ECDSAP256SHA256
- パブリックキー:パブリックキーを入力する
[登録済みドメイン] > 対象ドメイン > DNSのステータスが「設定済み」になっていることを確認します。
別のドメインレジストラ
[信頼チェーンを確立] > [別のドメインレジストラ]をクリックします。
私のドメインレジストラはonaame.comですが、ドメインレジストラによって多少GUIが変わりますので、「対象レジストラ名 DSレコード設定 新規追加」で検索してください。
ZSKとKSKの鍵の責任分担
Amazon Route 53ではZSKの管理はRoute 53 (AWSの責任) によって実行されますので、ZSKの何かしらの設定は不要です。KSKの管理はお客様の責任となりますので、その点はご注意ください。
AWS KMS 必要に応じてローテーションするなど、KSK管理はお客様の責任となります。ZSK 管理は Route 53 によって実行されます。 docs.aws.amazon.com
DNSSECの有効化後の状態の確認
DNSVizで確認すると、DNSSECが有効化されると対象ドメインまで「DNSKEY」が下がっている状態です。
対象ドメインのStatusに「SECURE」と書いてあります。
whoisコマンドで確認すると下記の結果になります。
whois example.com | grep -i dnssec DNSSEC: signedDelegation DNSSEC DS Data: 28623 13 2 2E7587DDA6D7CE825536D3FAB8FC4E240 DNSSEC: signedDelegation
考慮事項
- DNSSECを2つのDNSプロバイダで同時に有効にすることはできません。現在のDNSサービスプロバイダからAmazon Route 53にドメイン名を移行する前に、現在のDNSサービスプロバイダからDNSSECを無効にする必要があります。これは、親ゾーンから委任署名者(DS)レコードを削除することで行うことができます。 DNSSECはドメインのセキュリティを確保するために、親ゾーン(通常はTLD)にDS(Delegation Signer)レコードを登録する必要がありますが、このレコードは一つのDNSプロバイダにしか設定できません。そのため、DNSゾーンを切り替える際は、現在のプロバイダでDNSSECを無効化し、DSレコードを親ゾーンから削除してから、新しいプロバイダでDNSSECを再度有効化する必要があります。
- 普通のDNSと同じく、DNSゾーンを移行する際、切り替え前に古いゾーンデータのレコードのTTL値を短く設定することで、DNSキャッシュが速やかに更新され、新しいDNS設定が早く適用されるようになります。これにより、ダウンタイムや切り替えに伴う混乱を最小限に抑えることができます。
- DNSSECを有効にすると、各DNSクエリに対して追加のデジタル署名データが送信されるため、従来のDNSクエリに比べて応答サイズが大きくなります。このため、以下の点に注意が必要です。
①TCP 53ポートを開く必要がある
UDPパケットのサイズが512バイトを超える可能性があるため、DNSクエリの一部がTCPにフォールバックすることがあります。そのため、TCP 53ポートが空いていることも確認してください。許可されていない場合、許可をする必要があります。
②料金が増える可能性がある
応答データが大きくなるため、データ転送量が増加し、その結果としてデータ転送にかかるコストが増える可能性があります。
課金
DNSSEC自体は無料ですが、KMSの利用料は発生します。
以上、御一読ありがとうございました。
本田 イーゴリ (記事一覧)
カスタマーサクセス部
・2024 Japan AWS Top Engineers (Security)
・AWS SAP, DOP, SCS, DBS, SAA, DVA, CLF
・Azure AZ-900
・EC-Council CCSE
趣味:日本国内旅行(47都道府県制覇)・ドライブ・音楽