2013/05/29日本インターネツトエクスチェンジ株式会社日本DNSオペレーターズグループ石田嘉樹
apan Internet Exchange
Agenda ✓DNSSEC対応✓権威DNSのDNSSEC対応✓キャツシュDNSのDNSSEC対応
ipan Internet Exchange
Agenda ✓DNSSEC対応✓権威DNSのDNSSEC対応✓キャツシュDNSのDNSSEC対応
lapan Internet Exchange
DNSSEC対応✓DNSSEC対応には■署名側■検証側の両方の対応が必要対応
Japan Internet Exchange
DNSSEC対応◆署名側の対応✓レジストリ✓レジストラ✓DNSホスティング◆検証側✓上位アプリ✓企業／組織✓ISP ■権威DNSサーバで■キャツシュDNSサーの対応バでの対応それぞれのサーバでのDNSSEC対応について紹介
5
Japan Internet Exchange
Agenda ^DNSSEC対応✓権威DNSのDNSSEC対応✓キャツシュDNSのDNSSEC対応
lapan Internet Exchange

✓ 2種類の署名鍵の公開■ KSK ■ ZSK ✓署名(RRSIG)の公開■問い合わせに対して署名を応答する✓不在証明■「存在しない」ことを証明✓下位ゾーンの委譲(delegation) ■下位ゾーンのKSK相当(ハツシュ値)を自ら署名して公開■信頼の連鎖を形成
pan Internet Exchange

✓通常の権威DNSサーバの運用✓準備作業■ DNSSECに対応した最新のソフトウェア● BIND9 (9.7系以降でISCのサポートのあるもの) ● NSD (3.2系の最新のもの)口鍵の作成とゾーンの署名にldns等が必要■サーバの時刻同期●署名に有効期限が存在■ 512バイト超のDNS応答への対応● EDNSO, TCPフォールバックおよび|Pフラグメントへの対応●サーバ自身のフィルタおよびミドルボックス
8
ban Internet Exchange
権威DNSサーバのDNSSEC対応✓DNSSEC対応に伴って新たに発生する事項① RRへの署名／署名の更新②署名鍵の定期的な更新(ロールオーバー) ③下位ゾーンのDSレコードの追加と署名✓自ゾーンのDSレコードを上位ゾーン(の管理者)に通知■レジストラを介してレジストリへ通知
lapan Internet Exchange

✓ゾーン内の各レコードに対するRRSIGの生成✓不在証明の生成✓ゾーンを編集したら必ず署名✓ゾーンを編集しなくても定期的に署名署名には有効期間(有効時限)が存在放置したまま有効期間が過ぎると署名が無効になり名前が引けなくなる
apan Internet Exchange

✓同じ鍵を長期間使い続けることは危険DNSSECに限らずSSL/TLS/SSH等でも同様リスクの程度は暗号アルゴリズム、鍵長、期間に依存✓リスクを低減させるため鍵を更新■定期的な更新■イベントドリブンでの更新✓ DNSSECでは定期的な更新を推奨
apan Internet Exchange

✓DNSではキャツシュが分散して存在●鍵に関する情報、署名に関する情報も分散●TTLが過ぎていない間はどこかのキャツシュDNSサーバ上で保持されている可能性●鍵の更新時にキャツシュされている更新前の情報との整合性まで気をつけることが必要✓鍵の更新は段階を踏んで実行●権威DNSサーバのDNSSEC対応で面倒かつ最もトラブルを引き起こしやすい作業
✓運用上の必要性から鍵を3つの状態で管理■ Published ●鍵がゾーン上で公開されているが、署名・検証には使われていない■ Active ●公開され、署名・検証に使われる■ Inactive ●署名・検証には使われないが、ゾーン上で公開されている。
an Internet Exchange

✓KSKとZSKの両方で更新が必要■更新頻度はKSKとZSKで別■KSKについては上位ゾーンのDSの更新も必要✓ベストプラクティス的な手法が存在■ZSKについては事前公開法■KSKについては二重署名法✓キャツシュされている情報でも不整合が発生しないための運用上の手法
apan Internet Exchange

✓ ZSK:事前公開法■新しい鍵を署名に先駆けて公開する手法■署名は常に一つの鍵でのみ■鍵の公開と署名のタイミングが別■手順1.新鍵を公開(公開のみで署名には使わない) 2. DNSKEYのTTL以上の時間後まで待つ(新旧の鍵がキャツシュサーバで見えるようになる） 3.署名に使う鍵を新鍵に切替(旧鍵はゾーンには残す) 4. RRSIGのTTL以上の時間後まで待つ（旧鍵による署名がキャツシュサーバから消滅) 5旧雑を削除
✓ZSK:事前公開法
✓KSK：二重署名法■レコードを新旧2つの鍵で別々に署名● KSKはZSKを署名するものであるため対象は少ない■上位ゾーンとのDSレコードのやり取りを最小(ロールオーバー毎に1回)にするための手順■手順新鍵を公開し新旧両方の鍵で署名2. DNSKEYのTTL以上の時間後まで待つ(新旧の鍵がキャツシュサーバで見えるようになる） 3.上位ゾーンに登録するDSを新鍵のものに変更4.上位ゾーンのTTL以上の時間後まで待つ(旧鍵のDSがキャツシュサーバから消滅）旧鍵と旧鍵による署名を削除
✓KSK：二重署名法キャツシュに新旧の|キャツシュに新旧の
KSK (新) ③下位ゾーンのDSレコードの登✓下位ゾーンから渡されるDSレコードの管理✓作業としてDSレコードの更新(追加／削除)が発生✓KSKの更新ごとに作業が発生✓レジストリ・レジストラ間は何らかのl/Fを介して通知(EPPやWeb Ul等)
apan Internet Exchange

✓手順とパラメータの決定■ゾーンに署名するためにはパラーメータと手順を事前に定めることが必要■手順●ゾーンの更新●ゾーンの署名●ZSKの更新●KSKの更新
pan Internet Exchange

✓決定するパラメータ■暗号アルゴリズムと鍵長● RSASHA256が一般的● KSK 2048bit, ZSK 1024bit ●楕円曲線暗号も利用可能(ECDSA, GOST)ロ署名が短くなるというメリット口対応していないパツケージ等も存在口様々な要因から直近の普及は見込薄
■不在証明
●計算量が少ないがゾーンの情報をすべて辿れるNSEC ●計算量が多いがゾーン情報は辿られないNSEC3
✓決定するパラメータ■鍵の更新間隔●KSKは1年程度●ZSKは1, 2か月程度が標準的■署名有効期間●ゾーン内レコードの最長TTLより長くする●SOA expireより長くする●2週間から2カ月程度が標準的
pan Internet Exchange
権威DNSサーバの運用✓レジストラの対応状況の確認■すべてのレジストラが対応している状況ではない■DS取次を提供するレジストラであることが必須✓DNSSEC対応による定常的な運用負荷は増加■鍵の管理(鍵の生成と更新) ■署名の管理(ゾーンの署名と更新) ■DSの登録(上位ゾーンとの定期的なやり取り)
apan Internet Exchange
権威DNSサーバの運用✓権威DNSサーバの構成の見直し■サーバ負荷の上昇に伴うシステム数の見直し■ソフトウェアの変更やアプライアンスの導入■Hidden Masterの導入■HSMの導入
pan Internet Exchange

✓Hidden Master構成への変更■外部に非公開のサーバをマスターサーム■マスターではゾーン管理と鍵と署名の管理のみ■スレーブにゾーン転送■問合せへの応答はスレーブのみ■マスターサーバでの変更を確認後に公開Hidden example.jp. IN NS master.example.jp. example.jp. NS slave1.example.jp. I N IN NS slave.example.jp. IN NS slave2.example.jp.
25
apan Internet Exchange

✓ HSM (ハードウェア・セキュリティ・モジュール)の導入■ハードウェアによる鍵の管理■「HSMを利用したDNSSECの運用に関する考察」 http://dnssec.jp/?page_id=792 ■コストとの見合いhttp://dnssec.jp/?page_id=792より
26
権威DNSサーバの運用✓運用負荷を低減するために■手順書の作成■構成の変更(ハード、ソフト、アプライアンス) ■ツールの導入による自動化■アウトソーシングの検討
Japan Internet Exchange

✓ qmailからメイルが送信できなくなる問題■ gmailが行うANYの問い合わせに512バイト以上の応答が返ってくるドメインにメイルが送信不能● qmailの不具合●非公式パツチで対応可能口http://www.ckdhr.com/ckd/qmail-103.patch ■ DNSSECで署名すると応答パケットサイズが５１２バイトを超える● DNSSEC以外でも512バイト超だと同様の不具合が発生■ 1週間後のバウンスメールにより不達が判明●送信側は設定変更なしのため受信側の問題と認識●受信側(署名を行った側)では気づけず■このqmailの不具合によりDNSSEC対応に二の足を踏むドメインも存在Agenda ^DNSSEC対応✓権威DNSのDNSSEC対応✓キャツシュDNSのDNSSEC対応
apan Internet Exchange
キャツシュDNSサーバの役割✓通常のキャツシュDNSの機能✓DNSSECの署名の検証✓RRsetの正当性を検証
ban Internet Exchange

apan Internet Exchange

✓検証結果による応答■DSが登録されていない●署名されていない：ad bitなしでRRsetを応答(Indeterminate) ●署名されている: ad bitなしでRRsetを応答(Insecure) ■DSが登録されている●検証に成功：ad bit付きでRRsetを応答(Secure) ●検証に失敗：SERVFAILを応答(Bogus)
an Internet Exchange

✓通常のキャツシュDNSサーバの運用に追加✓準備作業■ DNSSECに対応した最新のソフトウェア● BIND9 (9.7系以降でISCのサポートのあるもの) ● Unboud (1.4系の最新のもの) ■サーバの時刻同期●署名に有効期限が存在■ 512バイト超のDNS応答への対応● EDNSO, TCPフォールバックおよびIPフラグメントへの対応●サーバ自身のフィルタおよびミドルボックス
✓設定の追加■BINDは設定追加とトラストアンカーの設定■ Unboundはトラストアンカーの設定■Rootゾーンのトラストアンカー (TA)の追加●何らかの方法で.のDNSKEY (KSK)を取得口DNSで取得□Webから取得●取得したDNSKEYが正しいかの確認ロハツシュ値の確認
34
pan Internet Exchange
キャツシュDNSサーバのDNSSEC対応✓トラストアンカーの自動更新の設定■５年毎にトラストアンカーの更新が必要■RFC5011に自動更新が規定■次の更新が最初の更新(導入されて5年経っていない）
pan Internet Exchange

✓設定の確認■検証出来ていることを確認●サーバ上でdigを利用して確認■配下のスタブリゾルバ(端末)で確認●検証用のWebサーバへの接続✓日常的な運用業務■権威DNSサーバのように定期的に作業が発生するわけではない■トラブル対応による運用負荷は少なくない
apan Internet Exchange
36

✓定期的に発生する作業は不要✓監視と対応は不可欠■権威DNSサーバ側での不具合に対応■監視とトラブルシューティングの負荷が増大■トラブル解決のための方針と手順が必要
✓監視とトラブルシューティング■ドメインの検証失敗の監視■検証失敗はポイズニングではなく権威DNS側の署名失敗がほとんど●権威DNSの署名失敗によりキャツシュDNS側で署名検評に失敗●検証失敗はSERVFAILとなるためユーザが接続不能●DNSSEC対応キャツシュDNSでのみ名前解決が失敗■影響の大きいゾーン(ルートに近いゾーン)で生じるとインパクトが巨大
apan Internet Exchange

✓監視とトラブルシューティング(続き) ■監視を行いトラブル時に対応■対応策①相手が復旧するまで待つロ　ユーザへの告知ロ　場合によっては何らかの方法での先方への通知②検証を一時的に中断ロ　影響が大きい場合ロ　ソフトウェアにより検証そのものの中断か該当するゾーンのみの中断かのいずれかにより対応まとめ✓DNSSEC対応は署名側と検証側の両輪が揃ってはじめて実現✓署名側の権威DNSサーバは定常的に作業が以来✓検証側のキャツシュDNSサーバは監視とトラブル時の対応手順の準備が必要
pan Internet Exchange

41

43
訪れ✓本資料を作成するにあたり■其田学氏(三洋ITソリューションズ(株)) ■松戸正和氏(㈱日本レジストリサービス) ■山口崇徳氏(株)インターネツトイニシアティブ)の3氏にご協力いただきました。
Japan Internet Exchange
Japan Internet Exchange