DNS Security Extensions

DNS Security Extensions (DNSSEC)とは

DNS Security Extensions（DNSSEC）は、インターネットの基盤であるDomain Name System（DNS）における応答の正当性を保証するための拡張仕様です。IETFによって策定されました。DNSSECは、サーバーとクライアントの両方が対応している場合に、DNS応答の偽造や改竄を検出し、ユーザーが意図しない接続先へ誘導されるのを防ぎます。

背景

インターネットでは、通信相手を特定するためにIPアドレスが使用されます。しかし、一般のユーザーはホスト名（例：www.example.com）を利用し、アプリケーションがDNSに問い合わせてホスト名に対応するIPアドレスを取得します。DNS応答が偽造または改竄されると、ユーザーは意図しない接続先へ誘導される可能性があります。これはDNS偽装と呼ばれる攻撃手法です。DNSは1983年に設計されたものであり、現代のネットワーク環境では攻撃に対して脆弱であることが問題視されています。

DNSSECの概要

DNSSECは、ドメイン登録情報にデジタル署名を付与することで、応答が正当な管理者によって生成されたものであること、そして改竄されていないことを保証します。DNSにおけるドメイン登録情報は、リソースレコード（RR）の集合で構成されています。リソースレコードには、A（IPv4アドレス）、AAAA（IPv6アドレス）、MX（メールサーバー）など様々な種類があります。DNSSECでは、認証に必要な情報を追加のリソースレコードとして扱い、対応していないクライアントはこれらの追加情報を無視することで従来の照会が可能です。

デジタル署名の例

RFC 4034では、`host.example.com`のAレコードに対するデジタル署名の例として、以下のようなRRSIGレコードが示されています。

host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
20030220173103 2642 example.com.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

デジタル署名は、データのハッシュ値に対して公開鍵暗号に基づく署名処理を適用したものです。この例では、SHA-1とRSAが使用されています（1行目の「5」が使用アルゴリズムを示しています）。認証に必要な公開鍵は、DNSKEYレコードとして取得できます。DNSSECは、DNSの階層構造を利用して認証チェーンを構成します。

認証チェーン

ドメイン名は巨大な木構造を形成しており、DNSの照会はこの木構造を根から順にたどります。DNSでは、この木構造を「ゾーン」に分割して分散管理しています。子ドメインが別のゾーンで管理されている場合、その委譲先のDNSサーバーのホスト名を記述します。DNSSECは、委譲先のホスト名に加えて、そのゾーンで使用される公開鍵のダイジェスト値をDSレコードとして提供します。クライアントは委譲先のDNSKEYレコードから公開鍵を取得し、DSレコードとダイジェスト値を比較することで、鍵の正当性を確認できます。

DNS over HTTPS (DoH) / DNS over TLS (DoT) との関係

DNS over HTTPS (DoH)は、DNSクエリをHTTPS上でやり取りすることでセキュリティを向上させるRFC 8484で定義されるプロトコルです。DNS over TLS (DoT)は、TLSプロトコルでDNSクエリをやり取りします。DoH/DoTとDNSSECは競合しません。DNSSECはドメイン登録情報の完全性を保証し、DoH/DoTはクエリのプライバシーを保護します。EDNS Client Subnetを利用する場合、フルリゾルバは端末のIPアドレスのサブネットを権威サーバーに渡すことがあります。この情報は、フルリゾルバと権威サーバーの間で平文で通信されます。DNSCurveは、これらの間の通信も暗号化するプロトコルです。

対応状況

DNS実装ソフトウェアとして、BIND9などDNSSECに対応したものが登場しています。しかし、2009年時点ではDNSSECの利用は一部に限られていました。上位ゾーンの対応の遅れが原因の一つでした。DNSSECの認証チェーンはルートゾーンからの委譲関係を辿るため、トップレベルドメインでの対応が不可欠でした。DNSSEC Lookaside Validation (DLV)という暫定手段も提案されましたが普及しませんでした。2008年のDNSキャッシュポイズニング問題以降、状況は改善され、.orgドメインがgTLDとして最初にDNSSECに対応しました。.comや.netを管理するVeriSignは、2011年までに全てのgTLDで対応を完了すると宣言しました。ルートゾーンも2010年7月までに段階的にDNSSECを導入する計画が立てられました。日本のccTLDである.jpドメインは、2011年1月16日に対応しました。

パブリックDNSサービス

Google Public DNS、Verisign Public DNS、Norton ConnectSafeなどのパブリックDNSサービスがDNSSECに対応しています。また、国内ではIIJ、InfoSphere、SANNETなどがDNSSEC対応サービスを提供しています。

KSKロールオーバー問題

KSKロールオーバー問題は、DNSSECでルートゾーンの暗号鍵（KSK）を更新する際に、応答データサイズが大きくなり、通信設定によってはDNSSECの検証が失敗する可能性があるという問題です。ルートゾーンKSKは2016年まで更新されていませんでしたが、2016年10月から2018年3月にかけて順次変更されることになり、問題が顕在化しました。特に2017年9月19日、12月20日、2018年1月11日からの更新では、IPフラグメンテーションが発生しない最大値を超える応答データが発生すると予想されました。この問題は、DNSの運用責任者がソフトウェアのアップデートや設定変更で対応する必要がありましたが、一般消費者向けルーターの内蔵DNS Proxyでも問題が発生する可能性がありました。しかし、2019年12月の報告によると、KSKロールオーバーによる大きな問題は報告されませんでした。

脚注

RFC

DNSSECに関するRFCは以下の通りです。

- RFC 2535 - Domain Name System Security Extensions
- RFC 3110 - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
- RFC 4033 - DNS Security Introduction and Requirements
- RFC 4034 - Resource Records for the DNS Security Extensions
- RFC 4035 - Protocol Modifications for the DNS Security Extensions
- RFC 4431 - The DNSSEC Lookaside Validation (DLV) DNS Resource Record
- RFC 4470 - Minimally Covering NSEC Records and DNSSEC On-line Signing
- RFC 4509 - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
- RFC 5074 - DNSSEC Lookaside Validation (DLV)
- RFC 5702 - Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC

外部リンク

- .org/'>OpenDNSSEC （英語）
- .jp/'>DNSSECジャパン