DNSSECとは?

インターネットの安全性を次のレベルへ

2023年10月23日
翻訳: 竹洞 陽一郎

この記事は米Catchpoint Systems社のブログ記事「What is DNSSEC? 」の翻訳です。
Spelldataは、Catchpointの日本代理店です。
この記事は、Catchpoint Systemsの許可を得て、翻訳しています。

DNS（ドメインネームシステム）はインターネットの基本的な構成要素であり、その役割はドメイン名を対応するインターネットプロトコルアドレス（IPv4およびIPv6）に位置づけて変換することです。
業界では時間とともに変化と適応が行われ、より多くのトップレベルドメイン、レジストリ、およびレジストラーが存在するようになりました。
人類は「ドットコムバブル」を経験し、インターネットはますます多くの人々によって採用されました。

これらすべての出来事にもかかわらず、ドメインをIPアドレスに変換する基本的な理論は有効であり、大きく変わることはありませんでした。

ドメインネームシステムは、元々セキュリティを主目的として設計されたわけではありません。
それはスケーラブルな公共データベースであり、そのデータへのアクセスを制限していませんでした。
このことがシステムに多くの脆弱性を露呈させ、複数の攻撃手法が生まれる原因となりました。

過去数年で、DNS関連の攻撃手法（スプーフィング、キャッシュポイズニング、DNSハイジャックなど）の数は前例のないほど増加しました。
これが、DNSにセキュリティ拡張を追加するための「ドメインネームシステムセキュリティ拡張（DNSSEC）」の開発を促しました。

DNSの脆弱性と攻撃

ほとんどの脆弱性と攻撃手法は、DNSとしてのプロトコルがどのように実装されているかに起因しています。

DNSキャッシュポイズニング

キャッシュポイズニングは、DNSサーバがドメイン-IPマッピングに関する誤った情報をキャッシュする形態の攻撃です。
ユーザは意図していないWebサイトにリダイレクトされます。
毒されたキャッシュ情報は、一つのサーバから別のサーバに拡散する可能性があり、これがキャッシュポイズニングを非常に危険にしています。

DNSは分散型のサーバシステムであり、単一のサーバだけに依存しているわけではありません。
DNSでのキャッシュは、複数のレベルで行われます。

• ローカルマシン
• ルータ
• ISP（インターネットサービスプロバイダ）
• ドメインのネームサーバ
• gTLDサーバ

攻撃者がDNSシステム内のサーバの一つにアクセスしてそのサーバ上の情報を変更した場合、どうなるでしょうか？
毒されたエントリは、サーバ間で伝播し、エンドユーザのデバイスにキャッシュされる可能性があります。

この問題は仮想のものではありません。
近年では、複数の実例がありました。

2010年には、中国外のISPが、中国に位置するDNSサーバから情報を取得するようにDNSサーバを設定しました。
中国の「Great Firewall」は、キャッシュポイズニング（自分自身のキャッシュを毒する）を使って、一部のWebサイトのユーザを誤ったIPアドレスにリダイレクトすることで知られています。
このケースでは、ISPは中国のサーバから受け取ったレスポンスをキャッシュし、その後他のサーバによってキャッシュされました。

毒されたキャッシュはシステムからシステムへと拡散し、結果として、アメリカとチリの一部のユーザがFacebook、Google、TwitterなどのWebサイトにアクセスできなくなりました。

DNSハイジャック

DNSハイジャックでは、キャッシュポイズニングとは異なり、DNSキャッシュは変更されません。
ハイジャックする人は、ドメイン名のDNS設定を自分自身のIPに指すように更新します。
DNS設定が更新されると、ハイジャックする人はユーザを自分のWebサイトにリダイレクトできます。

これはフィッシング攻撃や、ユーザをハイジャックする人が訪れて欲しいWebサイトにリダイレクトすることでお金を稼ぐためにも使用される可能性があります。
DNSハイジャックとキャッシュポイズニング/スプーフィングは、DNS攻撃の中で最も一般的に使用される形態の2つです。

DDoS（分散型サービス拒否攻撃）や増幅攻撃といった攻撃も存在します。

DNSがセキュリティを念頭に置いて構築されていないこと、また、答えを受け入れる前に何らかの資格情報を確認しないことは皆さんも知っていると思います。
では、これらの脆弱性と攻撃手法が存在する中で、DNSをより安全で堅牢にするにはどうすればよいでしょうか？

DNSを安全にするために講じられた最も重要なステップの一つは、DNSSEC（Domain Name System Security Extensions）の導入でした。
以下のセクションで、それがどのように機能するのか詳しく書きます。

DNSSEC（Domain Name System Security Extensions）

DNSSECは、DNSレスポンスの検証を可能にすることで、ドメイン名システムにセキュリティを追加します。
DNSSECの正確な実装によって、DNSスプーフィングと呼ばれる非常に一般的なタイプの攻撃に対するDNSの脆弱性が減少します。

DNSSECは、公開鍵暗号を用いて、権威DNSサーバでDNSレコードにデジタル署名を行います。
デジタル署名により、DNSレスポンスが指定されたソースから来たことが確認でき、DNSレコードの発信元を検証できます。
これにより、システムのユーザがドメイン名に関連する正確なIPアドレスを取得することが保証されます。
権威DNSサーバで既存のDNSリソースレコードに暗号学的な署名が追加されます。

DNSSECはプロトコルとして暗号化されていません。
キーはレコードに署名し、信頼のチェーンを構築するために使用されます。
ただし、パケットは暗号化されていないため、DNSSECは暗号化を提供しません。

DNSSECは信頼のチェーンを確立することで機能します。
このチェーンは、ルートの「.」ネームサーバで始まります。
ルートの公開鍵のコピーは、DNSSECが有効な再帰的ネームサーバに保持されています。
ルートサーバは、TLD（トップレベルドメイン）サーバと、TLDサーバはドメイン名の権威サーバと信頼関係を形成します。

DNSSECの署名検証を支援するために、以下のリソースレコードが導入されました。

RRSIG（Resource Record Signature）

RRSIGレコードには署名されたレコードが含まれています。
署名されたゾーンでドメイン名のAレコードを問い合わせると、AレコードとともにRRSIGレコードが返されます。
RRSIGレコードには、それを検証するために使用される署名のコピーが含まれています。

DNSKEY（DNS Public Key）

DNSKEYは、レコードまたはDNSゾーンに署名するために使用される公開鍵を保持するレコードです。
DNSKEYには2種類あります。

• Zone Signing Key（ZSK）：DNSゾーン内のレコードに署名するために使用されます。
• Key Signing Key（KSK）：ZSKに署名し、その上位レベルと信頼のチェーンを形成するために使用されます。

DS（Delegation Signer）

DSレコードは親ゾーンに存在し、子ゾーンへの問い合わせ結果を検証するために使用されます。
たとえば、ドメイン名example.comについては、DSレコードが.COMゾーンに存在します。

NSEC/NSEC3（Next Secure）

NSECおよびNSEC3は、DNSで存在しないドメイン名（NXDOMAIN）を安全に処理するために使用されます。
これらは、レコードが存在しないことを示すNXDOMAINレスポンスに署名されたレスポンスを提供します。

DNSSECは公開鍵暗号を使用してDNSリソースレコードセット（RRsets）に署名および認証を行います。
公開鍵はDNSKEYリソースレコードに保存され、DNSSECの認証プロセスで使用されます。
ゾーンは、プライベートキーを使用してその権威あるRRsetsに署名し、対応する公開鍵をDNSKEYリソースレコードに保存します。
リゾルバは、その後、公開鍵を使用してゾーン内のRRsetsをカバーする署名を検証し、それらを認証することができます。

DNSSEC実装の要件

• DNSSECを実装するためには、ドメインの親ゾーンとその親の親ゾーン、最終的にはROOTまでがDNSSECをサポートしていなければなりません。
  現在、ROOTゾーンにある1531のTLD（トップレベルドメイン）のうち、1386が署名されています。
  
• ドメイン名のレジストラは、DSレコードを親ゾーンにアップロードできるようにする必要があります。
• ドメインのホスティングプロバイダはDNSSECをサポートしていなければならず、提供される管理インターフェースはDNSKEY、RRSIG、DNSSECおよびその他のDNSSEC関連レコードを追加できるようにする必要があります。

DNSSECの仕組み

DNSゾーンは「ゾーン署名」と呼ばれるプロセスを使用してDNSSECで保護されます。
このためには、権威DNSサーバとほとんどのケースでISPに所属するローカルリゾルバもDNSSECをサポートしている必要があります。

• ゾーンがDNSSECで署名された場合、ゾーンの作成者はキー・バリューのペアを生成します。
  このキー・バリューのペアは、公開鍵暗号または非対称暗号の基礎を形成します。
  DNSレスポンスは、これらのデジタル署名を使用して検証され、DNSレスポンスに含まれます。
  公開鍵暗号では、秘密鍵がメッセージを暗号化し、公開鍵がメッセージを復号化できます。
  ドメイン名前空間では、ゾーンファイル内のDNSKEYレコードに公開鍵が含まれます。
• リソースレコード（A、CNAME、AAAAなど）は、ゾーンが更新されるたびにRRSIGレコードを使用してデジタル署名されます。
  
• 上記の画像は、RRSIGレコードがA、CNAME、SOA、NS、AAAAなどのリソースレコードにデジタル署名する方法を示しています。
  DNSKEYレコードには公開鍵が含まれています。
• DNSSECが有効なゾーンでは、RRSIGレコードがDNS問い合わせへのレスポンスと共に解決サーバに送り返されます。
  このレスポンスとRRSIGが解決サーバに受信されると、解読のための公開鍵（すなわちDNSKEYレコード）を求めます。
• RRSIGレコードはリソースレコードのダイジェスト/ハッシュであり、暗号化されています。
  DNSSECが有効なゾーンに対する任意のDNSレスポンスにRRSIGレコードが添付されます。
• 解決サーバがDNSレスポンスとそのレスポンスに対応するRRSIGレコードを受信したら、RRSIGを復号化するための公開鍵が必要です。
  解決サーバは要求されたリソースレコードのハッシュを作成し、公開鍵を受け取ると、そのキーを使用してRRSIGまたは署名を復号化し、2つのハッシュまたはダイジェストを比較します。
  一致すると、署名は有効です。
• 悪意のあるエンティティがDNSレスポンスとRRSIGレコード、そして使用されている公開鍵を独自のキーペアに偽装する可能性があります。
  これは、DSレコードまたはDelegation Signer Recordsを使用してDNSSECで回避できます。
  次のセクションでは、DNSSECが理論外でどのように動作するのかを理解するために、実際のDIGコマンドを見ていきます。

DNSSECとDIGコマンドの使用

DNSSECがどのように動作するかを理解するために、いくつかのDIG問い合わせを見てみましょう。

• まず、DNSSECをサポートしていないDNSリゾルバを使用して、example.comのNSレコードを問い合わせします。
  得られるレスポンスは以下の通りです。
  

  
  $ dig + short NS example.com
  b.iana-servers.net.
  a.iana-servers.net.	
  

• 次に、DNSSECを有効にして同じ問い合わせを実行します。
  

  
  $ dig + short +dnssec NS example.com
  b.iana-servers.net.
  a.iana-servers.net.	
  NS 13 2 86400 20231109002917 20231019095303 2182 example.com. LhezD+LGEtT667lJ7RfRsi0sRB7Z0Ph4zHP7vGozUSHC/5o0melNv++W NAfI5A2nlPmX7VnMNPWNK4VhF70y2g==
  

  このケースでは、ドメインexample.comのNSレコードだけでなく、RRSIG（リソースレコード署名）も受け取りました。
  任意のDNSSEC署名ゾーンでは、各レコードセット（RRset）に1つまたは複数のRRSIGレコードがあります。
  RRSIGレコードは基本的に、秘密鍵で結果に署名した後に生成される署名を含んでいます。
• 次のステップは、返された署名が有効かどうかを確認することです。
  署名の有効性を確認するために、DNSリゾルバは「DNSKEY」レコードを取得する必要があります。
  

  
  $ dig + short DNSKEY example.com
  256 3 13 /nRLBtx2AgW9shSZR4QVW6N3r0+tHCjiHc4gnlmY1VXggS0fiSfjsrkF OCZFGHrQWFlG839iIV7ToSFk0wRvOw==
  257 3 13 kXKkvWU3vGYfTJGl3qBd4qhiWp5aRs7YtkCJxD2d+t7KXqwahww5IgJt xJT2yFItlggazyfXqJEVOmMJ3qT0tQ==
  256 3 13 PAwmimrmweQdmio2mmVkbWI8HWyLv9ddPbUPuulE2Jf+Pc3DNTP0xwKm eSCgAeinSLZb8MKIMhcxL6Qt20L4Dg==
  

  上記のスクリーンショットでは、example.comのDNSKEYをdigしています。
• リゾルバがこの段階で持っているすべてのレコードを見ると、ドメインexample.comのNSレコード、その署名（RRSIGレコードの形）、および公開鍵（DNSKEYレコード）があります。
  問題は、ドメインのゾーン内（このシナリオではexample.com）で信頼を確立するだけで十分かどうかです。
  この問題に対する答えはNOです。
• DNSは複数の階層が関与する階層型のシステムであり、ルートから始まり、ドメインの権威サーバまで続いています。
  DNSSECでは、これら複数の階層間で「信頼の連鎖」を作成することが非常に重要です。
• DNSSECでは、信頼の連鎖は「Delegation Signer Record」、つまりDSレコードを使用して作成されます。
  これにより、親ゾーンと子ゾーンの間に信頼の連鎖を構築できます。DSレコードは2つの非常に重要な機能を果たします。
  • 子ゾーンがDNSSEC対応であることをDNSリゾルバに通知する
  • 子ゾーンの公開KSK（Key Signing Key）の検証を支援する。
    リゾルバはこれをハッシュ化し、親からのDSレコードと比較します。
    一致する場合、KSKが改ざんされていないとリゾルバは判断でき、子ゾーン内のすべてのレコードが信頼できます。
• KSK（Key Signing Key）に変更がある場合、親ゾーンのDSレコードを更新する必要があります。
• この信頼と検証の階層が「Chain of Trust」と呼ばれるものです。

DNSSECは新しい概念ではなく、1994年に開発されましたが、その実装にかかるコストとリソースが正当化されるかどうかは依然として熱く議論されています。
2008年のKaminskyバグはDNSに関するセキュリティの重要性を浮き彫りにし、「DNSSEC」が注目を集めました。
開発から数十年経った今でも、その長所と短所について議論が続いています。

次のブログの部分では、DNSSECの可能な応用について見ていきます。
DANE、TLSAレコード、そしてCatchpointを使用してDNSSECを効率的に監視する方法に焦点を当てます。