[レポート] 今年もDNSの夏！ DNS Summer Day 2019に参加しにきました（午前の部） #dnsops 【更新中】

DNS Summer Day 2019 が今年も開催されました！　本記事は速報ということで午前中のセッションについてレポートします。

情報の加筆、ならびに資料や画像などは追って更新しますのでご了承下さい。

DNS Summer Day 2019 とは

日本DNSオペレーターズグループ (DNSOPS.JP) 主催により開催されている、内外の DNS エンジニアが DNS について語るイベントです。

日本DNSオペレーターズグループ | DNS Summer Day 2019

DNSはインターネットにおける重要な基盤技術の一つです。そのため、DNSの安定運用がインターネット安定運用にそのまま直結します。 特に2020年東京オリンピック・パラリンピックを迎えるにあたって情報通信インフラの安全性・健全性を支える重要な要素として認識される一方で、 海賊版サイトのブロッキングに関する議論の中でDNSの本来の役割を捻じ曲げるべしというような議論も起きました。 このようなDNSの状況に鑑みて、DNSOPS.JPでは今年も引き続き DNS Summer Day を開催することといたしました。そして今年も協賛団体の方々にご登壇いただく予定です。

今年は去年と同じく、 フクラシア東京ステーション にて開催されています。協賛スポンサー各社のお陰で参加費は無料ということで感謝致します。

ちなみに、去年・一昨年開催の同イベントについても記事を公開しております。興味がおありでしたらこちらもご参照ください。

• DNSオペレータ達の夏の祭典・DNS Summer Day 2018に参加してきました ｜ DevelopersIO
• DNS Summer Day 2017に参加してきました #dnsops ｜ DevelopersIO

DNSとプライバシー

スピーカー情報

• 其田 学
  • 株式会社インターネットイニシアティブ

内容

• DNSメッセージ = 通信の一部
  • 何処に通信しようとしているのか、何をしようとしているのか
• 重要になってきたきっかけ = スノーデン事件
• RFC7258
• 従来のDNSはほぼUDPで平文で通信している
  • -> 盗聴、改ざんには脆弱
  • 可用性に特化したプロトコル
• DNSSEC
  • 完全性に対応したが、機密性は守られていない
• 新しいDNSプロトコルたち
  • フルサービスリゾルバ - 権威
    • QNAME minimization
      • 最小限の名前のみ権威DNSへ送る（上位権威に渡るクエリが最小限に抑えられる）
      • IIJのリゾルバは対応済み
    • DNS over TLS(DoT)
      • 将来的にリゾルバ - 権威感でも使われるようになるはず
  • スタブリゾルバ - フルサービスリゾルバ
    • DoT
    • DoH
      • POSTを使う（GETだとクエリストリングがログに残る）
      • HTTP/1,2,3(将来)
      • DNS over QUIC とは別物
    • DoDTLS(DoD)
      • 忘れてください（だれも実装できなかった
    • DoQ
      • HTTPではないQUICネイティブ
• フルサービスリゾルバは安全？
  • 暗号化もほどいている
  • 自前で持っていたらリスクは低い
    • 反復検索を盗聴されるリスクは残る
  • ISPのリゾルバは安全？
    • 必要であればクエリログは正当業務行為
  • Public DNSは？
    • 海外のものだと日本法が適用されません
• DNSプロバイダとしてのベストプラクティスがIETF draftにある
• Mozilla
  • TRR Request - DOH resolver policy
  • データの透明性や保存期間など、ブロッキングと改ざんの禁止
  • 全体的にハードルが高い
  • public iij は TRR Requestに準拠
• Q&A
  • public iij でDNSパディングは対応しているか？
    • してない

Measures against cache poisoning attacks using IP fragmentation in DNS

スピーカー情報

• 藤原 和典
  • 株式会社日本レジストリサービス（JPRS）

内容

• OARC 30 で発表したものと同じ
• https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-00
• 攻撃のキーアイディア
  • 遠隔のアタッカーがpath MTUを設定できる、悪用してフラグメントをコントロールできる
  • 攻撃パケットを作ることは難しくない（むしろ簡単）、送るのは一定の難しさ
• IPv4は古いLinuxのみ
• IPv6だとLinux4.xやFreeBSDでも有効(1280まで)
• なぜfragmentをつかうと毒入れが簡単になるのか？
  • フラグメントされた二つ目以降のパケットはよわい
• 対策
  • EDNS0のサイズを小さくする -> DNSSECに影響
    • https://twitter.com/tss_ontap_o/status/1144433189407956992
  • DNSではできるだけフラグメンテーションを避けるような実装にする
    • MTUが小さいネットワークでDNS名前解決ができなくなる
• まとめ
  • path MTU は脆弱
  • IPフラグメンテーションが行われると毒入れが容易になります
  • 古いLinuxに影響があります（まだ使われていますよね？）
  • フラグメンテーションを避けるのは可能
• QA
  • Linux 5.1.x でもダメだったんだけど？
    • ディストロで差があるかも（未検証
  • フラグメントを落とす設定にしているとデバッグしづらくなる、というコメント

Flag Day - それでは、次は？

スピーカー情報

• Jan Hilberath
  • Open-Xchange

内容

• DNS flag dayを行った
• 実施した理由 - DNSは複雑なので
  • 開発ミスがおきる、ベンダがワークアラウンドを追加する
  • コードメンテナンスが増加
  • 今回はEDNSワークアラウンドの削除をやった
• 予想 = 5.6%の増加
  • 中国系プロバイダが心配
• 結果
  • 成功した
• 次のFlag Day
  • DNS Flag Day 2020
• TCP対応をすすめる必要
  • UDPだと
    • スプーフィングなど
  • TCPだけにしない理由
    • TCPは4倍遅い
    • UDPでも小さなパケットなら問題ない
• 調査
  • TCPだと7%で失敗
  • また中国のプロバイダでエラーが高い
• ソフトウェアアップデートは必要か？
  • メジャーなOSSなら必要ない
  • 設定変更が場合により必要
    • TCP有効化
    • EDNS Buffer Size
    • Firewallの確認
• digでテスト可能
  • Webベースのツールは開発中、できあがったらDNS Flag Dayのサイトで公開
• 詳しくは
  • サイト、ML、GitHub issue
• Q&A
  • Flag Day 2019 で一部影響があった、機器メーカの対応が遅かった、次は影響が少ないと思っている
    • OSSならいっしょに対応する、メーカーも対応すべき

dnsdist - DNSトラフィックに特化したオープンソースの多機能ロードバランシンサー

スピーカー情報

• 麻生 龍一
  • Open-Xchange

内容

• dnsdist — dnsdist documentation
• DNSトラフィックに特化したOSSロードバランサー
• Luaによる柔軟な設定
• DNSバックエンドを選ばない
  • 後ろにフルリゾルバでも権威サーバでもok
• CLIあり（同じバイナリ）
• 機能
  • DNSを意識したLB
    • オリジン選択に過去のクエリを意識
  • 条件を満たす問い合わせに対するアクション = ルール
  • キャッシュ（リバプロ的な）
  • DoT,DoHのエンドポイント
  • ビルトインのWebサーバで統計情報表示
• ルール = セレクタ + アクション
  • セレクタ = 問い合わせ元、問い合わせドメイン、オプションなど
  • アクション = 振り分け先やドロップなど
  • 動的なルール生成（1秒おき）
    • Rate Limitみたいなことができる
• DoH,DoT
  • DNSサーバのフロントでdelegate
• ぜひ使ってみてください
• Q&A
  • ヘルスチェックを止めさせる方法はあるか
    • 1.3はない、RCの1.4でヘルスチェックの間隔を設定できるようになる
  • NATですかDSRですか？（NATだとステート持つのがつらい
    • 基本的には通る（NAT的
    • L4というよりはL7プロキシのようなイメージ
  • 通すことでQPS性能は？
    • 単純な場合 1CPUコアで数十万QPSまではいける雰囲気
  • 同一ソースIPソースポートからのクエリでカウントしない実装もある、これはどうか？
    • ちゃんとカウントする
  • 脆弱性の実績
    • 随時公開されている（アドバイザリー

Fuzzing Tool のまとめ

スピーカー情報

• 坂口 俊文

資料

• Fuzzing Full Resolverのまとめ - Speaker Deck

内容

• ファジングツールを開発した目的
  • プログラミング習得、プロトコルの理解、LTネタ
  • 汎用的なファジングツールには負けてられない
  • HackerOneのBug Bounty Programでお小遣い稼ぎ
• ファジングとは
  • バグや未知の脆弱性を検出するセキュリティテスト
  • 最初に権威サーバとして正規の応答を作成し、それを改変してからフルリゾルバへ送信
  • フルリゾルバが異常終了する原因を探る
• 実績紹介
  • Knot Resolver
  • PowerDNS
  • BIND
• まとめ
  • DNSSECなどのDNSの理解は、まだまだこれから
  • PowerDNS Bug BountyにてReword x3
  • ありがとうございました > PowerDNS
• Q&A
  • なぜDNSに拘っている？
  • たまたま。他をやっている時間が無い
    • カミンスキーアタックのキャッシュポイズニングがきっかけ
  • 発見したけど公開されていないものとかあるか？
    • 軽微なものが1件、対象はオフレコ

DNSTAPでDNSペイロードを可視化してみる

スピーカー情報

• 櫻井 俊和
  • 株式会社オプテージ

内容

• DNSTAP
  • DNSペイロードを見る方法
  • パケットキャプチャ
  • クエリログ
  • たいへん
• DSCも検証した
  • Pcapベース
  • ぱっと見るには十分だけが、調査ツールにとして使うにはつらいところがある
  • DNSTAPがよさげ
• DNSTAP
  • dnstap.info
  • Protocol Bufferベース、軽い
  • メジャーな実装はカバーしている
  • ./conifigure --enable-dnstap
  • Utility tools
    • golung-dnstap -> 公式、これを使う
    • dnstap-read
    • dnstap-ldns
• golung-dnstap
  • output format に json verbose -> 機械処理にするにはこれがよさそう
• 可視化
  • Clickhouse + Apache Kafka (+ Zookeeper)
  • dnstap -> fluentd -> kafka -> ClickHouse -> Grafana
• fluentd はパフォーマンス的につらかったので断念
  • input (multi processに対応していない)
• fluentdの代替
  • fluent-agent-lite -> kafkaに渡すところに独自実装要
  • flume -> 重い
• そもそも JSON ネストを整形するのにパフォーマンス要件を満たせない
• golung-dnstap kafka output を書いた
• kafkaからclickhouseへの取り込み
  • こちらも問題がでていて識者氏ー
• デモ
  • dnsperfで負荷をかけてGrafanaでリアルタイムに参照してみる

本日(6/28) 17:45 まで開催しています！

事前登録は不要、飛び込みでも参加できます。

東京駅の目の前という便利なロケーションと言うことで、興味が沸いた方は参加してみるのもよいと思います！