IDCF テックブログ

IDCF テックブログ

クラウド・データセンターを提供するIDCフロンティアの公式テックブログ

ルートゾーンKSKロールオーバー 影響と対策方法

DNS IDCFクラウド

こんにちは、酒巻です。
今回は今年最も注目されるDNS関連イベント、"ルートゾーンKSKロールオーバー"について書いていきます。

今年に入ってから各所で話題に上がることも多く、日頃あまりDNSに馴染みのない方でも何度か耳にしたことがあるのではないでしょうか。

既に準備を終えた方も多くいらっしゃるとは思いますが、いま一度皆さんと一緒に、対応のポイントについて直前のおさらいをしていきます。

なおこの記事では、それぞれのサーバーの役割を下記のように定義します。

  • キャッシュDNSサーバー：DNSクライアントからの様々なドメイン名の名前解決要求を受け取って再帰的な名前解決を行うDNSサーバー

  • 権威DNSサーバー：ある特定のゾーンに関するレコードデータを管理し、そのゾーンに関する問合せに対してのみゾーンの権威として応答を返すDNSサーバー


<2017/09/21 追記>
下記2点を追記しました。
・ルートゾーンKSKロールオーバーの具体的な実施時間について
・1,400オクテット超の応答の受信確認方法について、BIND 9.10以降では正しく動かない

<2017/09/29 追記>
下記を追記しました。
・ルートゾーンKSKロールオーバー 実施延期について

DNSSECのおさらい

「そもそも『KSK』ってナニそれおいしいの？」という方向けに、まずはざっとDNSSECについて説明します。 DNSSECについて十分理解されているかたは読み飛ばして下さい。

DNSSECに対応した権威DNSサーバーでは、管理対象のゾーンについて、

　① 「従来のリソースレコード(AやMXといったレコード)」
　② 「①をゾーンの管理者しか知らない秘密鍵で署名したレコード」
　③ 「②で使用した秘密鍵と対になる公開鍵のレコード」

が公開されます。

一方、DNSSEC検証を有効にしたキャッシュDNSサーバーでは、上記の①～③の情報を権威DNSサーバーから取得し、③で②のレコードを解読した結果と①を突き合わせ、一致すれば取得した①のレコードは正しい、と判定します。

ただ、これだけでは検証としては不完全であることは、すぐに分かりますよね。

何故なら、DNSSECはそもそも①に対する毒入れ対策のために生まれたものですが、①への毒入れが可能である以上、当然②や③についても毒入れの危険性があり、上記の検証プロセスの拠り所である③の正しさがそもそも保証されていないからです。

③の正しさを検証するには、親ゾーンの権威DNSサーバーの助けを借ります。

子ゾーンの管理者は、子ゾーンの権威DNSサーバーで①～③を公開することと併せて、親ゾーンの権威DNSサーバーに、

　④ 「③(と等価な情報)を親ゾーンの秘密鍵で署名したレコード」

を登録してもらいます。
勿論、親ゾーンの権威DNSサーバーでは④と共に

　⑤ 「④の署名に使った秘密鍵と対になる親ゾーンの公開鍵のレコード」

も公開されています。

親ゾーンの権威DNSサーバーから取得した④、及び⑤の情報が信用できるなら、⑤を使って④を解読した結果が③と一致すれば、③の正しさが保証されたことになります。

このように、DNSSEC検証の正当性は、「子ゾーンの公開鍵を、信頼出来る親ゾーンが保証する」という信頼の連鎖によって担保されています。

では、最上位のゾーンであるルートゾーンの公開鍵は誰が保証してくれるのか？というと、それは「キャッシュDNSサーバー自身」ということになります。

キャッシュDNSサーバーにはあらかじめ「信頼できるルートゾーンの公開鍵情報」を持たせておき、ルートゾーンの権威DNSサーバーから取得したルートゾーンの公開鍵と自身が持っている公開鍵情報が一致すれば、入手したルートゾーンの公開鍵は正しい、と判定されます。
この、「キャッシュDNSサーバーに予め持たせる公開鍵情報」は、「トラストアンカー(Trust Ancher)」と呼ばれます。

以上がDNSSECの基本的な仕組みですが、実際のDNSSECの運用では、鍵管理の運用コストに配慮して、各々のゾーンで2種類の鍵ペアが使われています。一つはゾーンのレコードを署名するための"Zone Signing Key"(ZSK)、もう一つはZSKを署名するための"Key Sigining Key"(KSK)です。

さらに、同じ鍵を長く使い続けているとそれだけ鍵の危殆化リスクも高まるため、適切な間隔で新しい鍵ペアに交換して新しい鍵でレコードを署名し直す必要があります。この鍵の更新作業が「鍵のロールオ―バー(Key Rollover)」と呼ばれており、一般にはZSKは1～3ヵ月、KSKは1～2年で更新することが推奨されています。

ルートゾーンKSKロールオーバーの特殊事情

さて、改めて言うまでもなく、"ルートゾーンKSKロールオーバー"というのはルートゾーンのKSKの更新のことなのですが、前述のKSKの一般的な更新間隔を見れば分かる通り、単なるKSKの更新ならば、これまでにも様々なゾーンで何度も行われており、さほど珍しいことではありません。

にもかかわらず、何故今回に限ってこれだけ騒がれているのでしょう。

その理由は、次の3点だと思います。

(1) ルートゾーンのKSKが全ての信頼の連鎖の起点であること
(2) KSK更新に合わせて、キャッシュDNSサーバー側でもトラストアンカーを追加する必要があること
(3) ルートゾーンでは今回が初めてのKSK更新であること

こういった事情により、今回各所で多くの注意喚起が行われているのだと思います。

KSK更新に伴う影響と要注意日

ICANNが発表している情報によれば、今回のKSK更新作業は2017年の7月～2018年の3月にかけて幾つかのステップを経て行われる予定です。
その期間中で特に注意が必要なのが、2017年9月19日と2017年10月11日(2018年第1四半期に延期されました)です。

ルートゾーンの公開鍵情報のレコード(DNSKEYレコード)の応答サイズは、その時々のKSK/ZSKの公開鍵の公開状況によって変化しますが、KSK更新作業期間中には、DNSKEYレコードとその署名レコード(RRSIGレコード)の応答サイズの合計が1,400オクテットを超える期間が何度か発生します。

IPv6の最小Path MTUは1,280オクテット、またIPv4のPath MTUも大体1,200～1,400オクテット程度の場合が多いため、応答サイズが1,400オクテットを超えた場合、IPフラグメントが発生してDNSKEYレコードの問合せに対する応答を受信できなくなる可能性があります。

2017年9月19日は、KSK更新作業期間中ではじめてDNSKEYとそのRRSIGレコードの応答サイズが1,400オクテットを超える日です。
<2017/09/21 追記>
2017年09月19日 23:00頃 (日本時間) (09月19日 14:00 UTC)に実施されました。
参考：https://lists.dns-oarc.net/pipermail/dns-operations/2017-September/016723.html

また、2017年10月11日には実際に新しいKSKによる署名に切り換わります。 従って、それまでにキャッシュDNSサーバーに新KSKのトラストアンカーが追加されている必要があります。
<2017/09/29 追記>
ICANNより、10月11日に予定されていたKSKロールオーバーを実施延期すると発表がありました。2018年第1四半期に予定されているようです。
再度延期される可能性もありますが、早めに確認しておきましょう。
参考：https://www.nic.ad.jp/ja/topics/2017/20170928-01.html

必要な準備

まず、キャッシュDNSサーバーがDNSSEC検証を行っている・いないにかかわらず、前述の1,400オクテット超の応答の受信確認を行っておきましょう。

具体的には、次のように実行します。
<2017/09/21 追記>
下記の方法は、BIND 9.10以降では正しく動きませんのでご注意ください。
参考：https://kb.isc.org/article/AA-00210/

dig @キャッシュDNSサーバーのIPアドレス +bufsize=4096 +short rs.dns-oarc.net txt
  • 実行例
$ dig @127.0.0.1 +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.
"116.91.131.134 DNS reply size limit is at least 4090"
"116.91.131.134 sent EDNS buffer size 4096"
"Tested at 2017-08-07 02:00:33 UTC"

上記実行例のように、"at least"の後ろの数値が"1424"以上であることを確認します。

若しくは、Verisign Labs の DNSSEC Key Size Testのサイトを利用することも出来ます。 サイトにWebブラウザでアクセスして、上から4項目まで"PASS"、5項目だけ"FAIL"と表示されることを確認します。(当然、確認したいキャッシュDNSサーバーを使ってWebブラウザが名前解決を行う必要があります)

  • 実行例

f:id:hisakama:20170817122002p:plain

さらに、DNSSEC検証を行っている場合は、新KSKのトラストアンカーが追加されていることを確認します。

具体的な確認方法は、ご利用中のDNSソフトウェア製品によって異なるため、ご自分で調べていただく必要があります。 ここでは参考までに、CentOS 7.xのBIND RPMパッケージを利用している環境での例を挙げておきます。

  • 参考例の環境
[root@bind9 ~]# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
[root@bind9 ~]# named -v
BIND 9.9.4-RedHat-9.9.4-50.el7_3.1 (Extended Support Version)

※ named.confはRPMパッケージ既定のファイルを変更せずに使用
※ chrootは行っていません

参考例の環境では、ルートゾーンのトラストアンカーは、BIND自身によって"RFC5011"の仕様に従って自動更新されます。
トラストアンカーは"/var/named/dynamic/managed-keys.bind"というファイルで管理されていますので、中身を確認します。

[root@bind9 ~]# cat /var/named/dynamic/managed-keys.bind
$ORIGIN .
$TTL 0  ; 0 seconds
@                       IN SOA  . . (
                                2          ; serial
                                0          ; refresh (0 seconds)
                                0          ; retry (0 seconds)
                                0          ; expire (0 seconds)
                                0          ; minimum (0 seconds)
                                )
                        KEYDATA 20170808025709 20170807025709 19700101000000 257 3 8 (
                                AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQ
                                bSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh
                                /RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWA
                                JQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXp
                                oY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3
                                LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGO
                                Yl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGc
                                LmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
                                ) ; KSK; alg = RSASHA256; key id = 19036
                        KEYDATA 20170808025709 20170807025709 19700101000000 257 3 8 (
                                AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
                                iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
                                7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
                                LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
                                efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
                                pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
                                A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
                                9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
                                ) ; KSK; alg = RSASHA256; key id = 20326

1つ目のKEYDATA(key id = 19036)が現行のKSKのトラストアンカーで、2つ目のKEYDATA(key id = 20326)に新しいKSKのトラストアンカーが追加されています。

まとめ

ルートゾーンのKSKの更新による影響と準備について簡潔にまとめます。

影響

  • ルートサーバーのDNSKEYレコード応答サイズが増加し、IPフラグメントが発生してキャッシュDNSサーバーが応答を受信できなくなる可能性がある
  • DNSSEC検証を行っている場合、新KSKによる署名開始後は、現行のトラストアンカーを使ったDNSKEYの検証が出来なくなる

準備すること

  • キャッシュDNSサーバーが、少なくとも1,424オクテット以上のDNS応答を受信できるようにする
  • DNSSEC検証を行っている場合は、さらにキャッシュDNSサーバーに新KSKのトラストアンカーを信頼済みの状態で追加する

IDCFの対応状況

最後に、IDCFでの対応状況について記載します。

KSKロールオーバーによりIPフラグメントが発生し名前解決ができなくなる問題について、 EDNS0は1220byteで制限していますが、IDCF提供のDNSサービス(IDCFクラウドDNS・リゾルバ)は 想定される1400byteを超えるパケットに対してTCPフォールバックで受信処理されるため影響はありません。

また、IDCFクラウドのテンプレートにて作成された仮想マシンでは、TCPフォールバックで受信処理される 仮想ルーター（KSKロールオーバー対策済）及びIDCFクラウド標準リゾルバが 問い合わせ先のリゾルバとして指定されている観点からもKSKロールオーバーの影響はありません。

IDCFクラウドの仮想マシンでiptables/firewalldを用いた制御を行っている場合、TCP port 53の通信を塞がないようにご注意ください。

"ルートゾーンKSKロールオーバー"による影響範囲はかなり広いので、早めに確認し、準備をしておきましょう。

参考:

Copyright © IDC Frontier Inc.