修正前の挙動:BIND 9 ・委任先ドメイン名の IPアドレスを、応答を待たずに並列で問い合わせる →Aレコード、AAAAレコード両方を問い合わせるので 2倍 →攻撃対象の権威DNSサーバーが IPv6通信可能な場合、さらに 2倍 #dnsops
2020-06-26 10:19:29修正前の挙動:Unbound: ・委任先ドメイン名の IPアドレスを、応答を待たずに並列で問い合わせる →BIND 9と比べると、応答がないときの並列度は控えめ →総数には上限がなく、委任先がいくつあっても全て問い合わせている模様 #dnsops
2020-06-26 10:20:20論文で提案された対策: ・派生した追加の問い合わせ数を制限 →権威DNSサーバーの名前解決が必要な場合、その回数に上限を設ける →並列度は実装任せだが、問い合わせ数を制限する形となる #dnsops
2020-06-26 10:21:07・対策として効果があり、副作用も軽微と主張 ・論文では他にもいくつかの対策が提案されている →多数の委任を含む応答を検知 →fetch-limit #dnsops
2020-06-26 10:22:04修正後の挙動: ・派生した追加の問い合わせ総数が制限されるようになった ・BIND 9 →権威DNSサーバーの名前解決を試みた回数が 4回を超えていて、委任先の権威DNSサーバーが 5個を超えている場合に打ち切る #dnsops
2020-06-26 10:22:51Akamai(CacheServe)はどこ? ・論文のサイトに掲載がない ・影響がないから入っていない? ・オープンソースではないから、一般の方は手に入れることが難しいから? #dnsops
2020-06-26 10:29:43CacheServe 7.5.1.1 の動作: ・参照先の NS のアドレスを一つだけ解決しようとする ・NXDOMAINだと別のものを ・A と AAAA を合計 12まで問い合わせ、全て NXDOMAIN の場合は諦めて、SERVFAIL 応答 #dnsops
2020-06-26 10:33:56名前解決のメッセージ数: ・論文では、通常の名前解決についても、理論上 3回のクエリで済むところ非常に多くのパケットが見られると指摘 #dnsops
2020-06-26 10:36:14・CacheServe による microsoft\.com の結果の内訳 (11クエリ) →ルート・プライミング (1) →ルート、com.、microsoft\.com. のクエリと応答 (3) →予備的なNS (3) #dnsops
2020-06-26 10:36:17参照先 NS 8つ (12) で十分なのか?: ・委任の情報は通常のキャッシュとは別に丁寧に管理 ・参照 NS の名前とそのアドレス解決状況を (不存在を含め) 保持 #dnsops
2020-06-26 10:37:12あらかじめ NS のアドレスを解決しておかなくて良い?: ・CacheServe では一つずつ行っている →未解決の NS のアドレスをひとつ解決しておく →徐々に、委任情報のテーブルにアドレスや RTT の情報が埋まっていく #dnsops
2020-06-26 10:39:23その他: ・Success-Based Rate-Limiting →権威DNSサーバーへの問い合わせ状況と失敗をモニタし、独自のアルゴリズムで自動的にクエリを調整 #dnsops
2020-06-26 10:40:42・Prefetch Extension →権威DNSサーバーからの応答が得られない場合に限って TTL が満了したキャッシュから応答 #dnsops
2020-06-26 10:40:44なぜ準備できていたのか?: ・開発当初より通信事業者を主なターゲットとしており、パフォーマンスだけではなく、セキュリティ、信頼性、可用性を重視 ・経験を活かしつつ、新しく作り直すことができた ・世界中の通信事業者における利用からのフィードバック #dnsops
2020-06-26 10:41:55・現場や研究者などからの意見に対応 →例)キャッシュポイズニングに対しても、カミンスキー攻撃の発表前にも後にも継続的に様々な対策を実施 #dnsops
2020-06-26 10:42:54