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

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

#レポート

#DNS

渡辺聖剛

2019.06.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

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 のまとめ

スピーカー情報

坂口俊文

資料

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でリアルタイムに参照してみる