ラック
Home > ブログ > 記事 > 2017年9月 > 備忘録:DNSサーバのルートゾーンKSKロールオーバーに伴う影響について

備忘録:DNSサーバのルートゾーンKSKロールオーバーに伴う影響について

カテゴリ: サーバ,ネットワーク

概要

総務省などから、DNSサーバのルートゾーンKSKロールオーバーに伴う影響についての注意喚起があった。これに対して、どのような対処が必要か調査を行った。

目次

  1. 用語解説
  2. 問題点
  3. 問題への対処
    1. 一般的な対処
      1. トラストアンカーの更新
      2. DNS応答サイズ増大への対応
    2. メーカ・アプリ別の対処内容
      1. BIND
      2. Windowsサーバ
  4. 参考サイト
  5. 追記

用語解説

次に、本書における用語の解説を行う。

  • DNS(Domain Name System)
    • インターネット上のドメイン名からIPを検索(解決)するデータベースシステム。ホスト名からIPを検索することを「正引き」、逆にIPからホスト名を検索することを「逆引き」という。クライアント(PC・タブレット)の接続要求に応じて正引き・逆引きといった「名前解決」の機能を提供するサーバがDNSサーバである。
  • DNSキャッシュサーバ(フルリゾルバ)
    • DNSクライアント(Webブラウザなど、ドメイン名を利用するアプリケーション)から再帰的な問い合わせの依頼を受けて、実際に問い合わせを行って名前解決を行うサーバ。LAN上のゲートウェイの機能やプロバイダが提供する場合が多い。
  • DNSコンテンツサーバ(権威DNSサーバ)
    • ドメインの管理情報、つまり自ゾーン(.uk, .jpといった国のゾーンや、.org, .coといった組織のゾーン、またexample.com, example.co.jpといった各ドメインのゾーンなど)のリソースレコード(Aレコード、MXレコードなど)の情報を管理・保持し、問い合わせ要求があった際に提供するサーバ。
  • ルートゾーン
    • DNSの仕組みにおいて最上位に位置するゾーン。名前解決の起点となる。
  • DNSSEC
    • DNSキャッシュサーバへ送信されたリソースレコードの情報が正しいかを保証するために導入された検証の仕組み。
      基本的な仕組みとしては、
      • a. リソースレコードの情報を
      • b. DNSコンテンツサーバが自身の秘密鍵で1.を署名したハッシュ値
      • c. b.の秘密鍵と対になる公開鍵でb.のデータを複合化
    • a.のレコードから生成したハッシュ値とc.の値が一致すれば、a.のレコードの情報が正しい、と判定する。ただし、a.のレコードと同時にb.で送られるデータも第三者が操作(DNSキャッシュポイズニング)してしまった場合、それも正しいと判定してしまうので、上記3つのプロセスだけでは不十分となる。
      そこで、上記のDNSコンテンツサーバ("サーバA"とする)の親ゾーンを管理するDNSコンテンツサーバ("サーバB"とする)に、上記のc.のデータと等価な情報を登録してもらい、
      • d. c.と等価な情報をサーバBの秘密鍵で署名したハッシュ値
      • e. d.の秘密鍵と対になる公開鍵
    • の2つを提供してもらうことで、サーバAのレコードが正しい情報であることを、サーバA自身の署名と、その親ゾーンを管理するサーバBの署名で検証する、という仕組みとなっている。
      • 実際の運用では、2種類の鍵が使われる。
        • ZSK(Zone Signing Key): ゾーンレコードを署名するために用いる
        • KSK(Key Sigining Key): ZSKを署名するために用いる
      • ZSKは実際のゾーンレコードを署名する際に用いられるため、セキュリティ向上のため頻繁に更新することが望ましい。しかし、その度に親ゾーンを管理するサーバBにも更新を促すと負荷が大きくなる。そこで、サーバBにはKSKのみを登録してもらい、ZSKを更新しても影響が出ないようにして、運用コストを抑えている。
  • トラストアンカー
    • 上記のDNSSECの「親ゾーンを管理するDNSサーバに、自DNSサーバの信頼性を担保してもらう」仕組みにおいて、信頼の起点となるKSK。ルートゾーンKSKがこれに当たる。
  • ルートゾーンKSKロールオーバー
    • 上記のトラストアンカーであるルートゾーンKSKの更新作業。

問題点

今回、ルートゾーンKSKロールオーバーによって次の2点が懸念される。

  1. ルートゾーンに含まれる鍵(KSK)が新しくなる(トラストアンカーの更新)
  2. 一部のDNS応答のサイズが一時的に大きくなる(DNS応答サイズ増大への対応)

これにより、下記に該当する者に対応が求められる。

  • DNSキャッシュサーバの運用者、ネットワーク運用者
  • DNSコンテンツサーバの運用者
  • 顧客のネットワークを運用しているシステムインテグレーター(SIer)

また、特に注意が必要となるのは次の2日である。

  • 2017/9/19: KSK更新作業期間中ではじめて公開鍵(DNSKEY)とその署名(RRSIGレコード)の応答サイズが1,400オクテットを超える日(DNS応答サイズ増大)
  • 2017/10/11: 新しいKSKによる署名へ切り替え(トラストアンカーの変更)

問題への対処

一般的な対処

DNSキャッシュサーバについての対処を以下に記す。

対処としては、

  1. トラストアンカーの更新
    • 対処: DNSキャッシュサーバに、新しいトラストアンカーを信頼済みの状態で追加する
  2. DNS応答サイズ増大
    • 対処: DNSキャッシュサーバが、1,424オクテット以上のDNS応答を受信できるようにする

を行うこととなる。

1. トラストアンカーの更新

1.に対して、

  • DNSSEC検証が有効かどうか
  • ルートゾーン自動更新機能(RFC5011)が有効かどうか

で対処(トラストアンカーの更新)が変化する。

  • DNSSEC検証が有効になっていない
  • ルートゾーン自動更新機能が有効

上記のいずれかの場合は、対処は必要ない。

  • DNSSEC検証が有効な場合、かつ、ルートゾーン自動更新が設定されていない場合

は、トラストアンカーの更新作業が必要になる。

  • BIND
    • 手動更新: named.conftrusted-keysディレクティブで鍵を指定
    • 自動更新:
      1. named.confmanaged-keysディレクティブで現在の鍵(KSK-2010)を指定
      2. 作業ディレクトリ中のmanaged-keys.bindに更新後の鍵(KSK-2017)が追加されているか確認
2. DNS応答サイズ増大への対応
  1. TCPによるDNSの通信が可能な設定になっているかを確認
  2. EDNS0の応答を受信できるかを確認
    • BIND
      • named.confの中で、 edns noで無効にしていないことを確認(デフォルト: yes)
      • max-udp-sizeedns-udp-sizeの値を小さく制限していないことを確認(デフォルト: 4096)
  3. 大きなサイズのDNS応答を受け取ることができることを確認

メーカ・アプリ別の対処

メーカ・アプリ別の対処を以下に記す。

1. BIND
  • 前提: ファイアウォールやルータでTCP53の通信が許可されていることを確認

All versions of BIND 9 since BIND 9.7 can support DNSSEC as currently deployed in the global DNS.

参考: BIND DNSSEC Guide

BIND開発元のドキュメントより、DNSSEC検証機能は9.7以降のバージョンでサポートされているとのこと。

# named -v

でバージョン確認。

dig +bufsize=4096 +short rs.dns-oarc.net txt

rst.x4090.rs.dns-oarc.net. rst.x4058.x4090.rs.dns-oarc.net. rst.x4064.x4058.x4090.rs.dns-oarc.net. "xxx.xxx.xxx.xxx sent EDNS buffer size 4096" "xxx.xxx.xxx.xxx DNS reply size limit is at least 4090" "Tested at 2017-09-06 06:18:02 UTC" ~~~

at least 4090、つまり1424オクテット以上なので、DNS応答サイズへの対応はOKということが分かる。

トラストアンカーの更新については省略。

2. Windowsサーバ

対応不要とのこと。

Q1. Windows の DNS サーバーにおいてルート ゾーン KSK の更新に伴い、対策を実施する必要があるのか。

A1. 結論として、Windows OS の DNS サーバーにおいては DNSSEC の構成の有無に関わらずルート ゾーン KSK の更新に伴う対策は不要です。

一般的には、ルート ゾーン KSK を管理しているパブリックのルート DNS サーバー (権威ある DNS サーバー) に対して明示的に DNSSEC を利用するように構成されているか否かが判断基準となります。
このため、DNSSEC を構成せずに DNS サーバーを利用している環境においては、今回の更新に伴う対策は必要なく、具体的な影響もないと判断できます。

Windows において DNSSEC を利用するように構成されている場合 “Windows Server 2012” 以降の OS であれば RFC5011 (トラストアンカーの自動更新) に準拠しているため、DNS サーバーは自動更新が有効であり、対策は不要です。
更に、Windows Server 2008 R2、Windows Server 2008 ではハッシュ アルゴリズムとして "RSA/SHA-256" に非対応であり、今回更新されるパブリックのルート DNS サーバーは "RSA/SHA-256" のみ対応しているため、DNSSEC を設定することができません。
このため、Windows Server 2008 R2 および Windows Server 2008 についても対策は不要となります。

参考: ルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性 – Ask the Network & AD Support Team

参考サイト

追記

2017/10/11に予定されていた新しい鍵による署名の開始が延期されるそうです。理由はKSKロールオーバーに対応できていないリゾルバが予想以上に多かったため。延期時期は2018年第1四半期とのことですが、これはリゾルバのKSKロールオーバー対応の状況に依る、とのことです。

タグ: 単語・用語,ニュース・時事・トレンド

 



関連する記事一覧