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

日本DNSオペレーターズグループ (DNSOPS.JP) 主催の DNS Summer Day が今年も開催されました。この記事では午前中に行われた 6 セッションについてレポートします。
2019.06.28

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メッセージ = 通信の一部
    • 何処に通信しようとしているのか、何をしようとしているのか
  • 重要になってきたきっかけ = スノーデン事件
  • 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 のまとめ

スピーカー情報

  • 坂口 俊文

資料

内容

  • ファジングツールを開発した目的
    • プログラミング習得、プロトコルの理解、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 まで開催しています!

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

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