編集長の佐藤（@akihirosato1975）です。
6/28に行われたDNS Summer day 2017に行ってきました。
本来インフラエンジニア向けのイベントなので、最近はセキュリティ屋の仕事が多い自分の守備範囲とはちょっとずれますが、昨今はDNSサーバを狙った攻撃も多いので、いろいろ参考になる話も聞けたかと。
以下簡単に各セッションの感想を。（資料はDNS Summer dayのページからダウンロードできます）
・whois
題名こそ「whois」になってますが、中身はwhoisの後継プロトコルである「RDAP」とか、過去のwhois情報を参照できるようにする「whowas」などの話。確かにwhoisって、自分がInternetを触り始めた25年前にはもう存在してたサービスなので、いい加減後継は必要だよなと。
RDAPのccTLDレベルでの提供はまだ先になるらしいですが、いろいろ作業の自動化が捗りそうなので早く対応してほしいな、という感じです。
・root zoneのKSKロールオーバー
DNSSECでルートゾーンの2種類ある鍵のうち、適用期間の長い「KSK」の鍵が今回初めて更新されるので、それに向けて準備が必要かもという話。
具体的には今年の9/19にDNSの応答サイズが1280bytesを超える可能性があるらしく、その前後でトラブルが発生する可能性があり注意が必要、とのことです。
・BIND脆弱性情報の一部事前リークについて
これは講演というより会場の反応を見るセッションで、IETF方式でハミングの声の大きさで賛成・反対を測るシステム。
昨今BINDの脆弱性は多いので確かに困るわけですが、ナビプラスは既にBINDは全廃してnsd + unboundの構成に移行してるので、正直どちらでもいいという感じでした。
・CDNとCNAMEあれこれ
CDNを運営している立場から、DNSのCNAMEレコードの扱いとか、（CNAMEレコードが使えない）Naked DomainでCDNを使う場合の話などについて。
「同一ドメインで特定ディレクトリだけCDNに向けたい」とか「Naked Domainだと通常はOrigin Webサーバで一度リクエストを受けてからリダイレクトする事が多いが、広告代理店絡みで『リダイレクトも嫌だ』と言われる」といった無茶振りにどう対応しているかという話ですが、昨今は一部のDNSソフトやサービスで「いわゆるaliasレコード」を独自実装して対応したりするそうで。（aliasレコードについては資料参照）
他にも複数のCDNを併用して自動最適化を行う「マルチCDN」なんてものも紹介されてました。
・UnboundでPRSD対策の実装
ASAHIネットで、unboundのpython APIを使って、PRSD（水責め）攻撃に対する自動ブロッカーを実装した話。
基本的にはドメイン単位で、権威サーバから返ってくるDNS queryの内容を解析して、SERVFAILが多発している場合には当該ドメインへのqueryをブロックしてしまう仕組みとのこと。なので他のドメインへのqueryは通常通り通すため、他のユーザへ迷惑をかける割合が低い、帯域やメモリへの圧迫を防げるのが利点だそうです。
実際にqueryをブロックするしきい値の調整が「手動」だったり、複数のドメインを同一の権威DNSサーバが管理しているときにドメインも分散して攻撃されると原理上対応が難しいなど、決して万能な機能ではないっぽいですが、実装の公開についても「検討している」らしいので、ちょっと期待してます。
・災害から考えるDNSと地域インターネットサービス
JPRSと電力系NCCが、「.jprs」というドメインを使って、災害を想定して東京にある権威DNSとの通信ができなくなったときにローカルノードを利用して通信を継続できるようにできないかという実験の話。
実験自体はおもしろそうと思うんですが、電力系NCCの方々が自社の企業紹介レベルの話にとどまっていて、具体的な話があまり出なかったのが残念。
・増え続けるRR Type
昨今DNSに登録できるRR（リソースレコード）のtypeが増え続けているのに対し、実際どのRR typeが重要なのよ？という話。
いろいろ話は出てましたが、中でも時間を割いて説明していたのが、今年9月から本格利用が始まるらしい「CAA」レコード。SSL(TLS)証明書の更新に関係してくるRR typeで、ある程度きちんと対応しないと今後まずい可能性もあるので、これについては近いうちに別記事まとめたいと思います。
・TTLの現状について
前半は日本国内でのTTL時間の設定分布の話でしたが、面白かったのが後半の「よくTTLが短いとキャッシュDNSサーバのCPU負荷が上がるといわれているが、これは本当か都市伝説か」という話。
実際にはTTLの長さよりも、権威サーバのレスポンス状態の影響のほうが大きいそうなので（詳しくは資料参照）、権威サーバのレスポンス速度には気をつけましょう。
・BINDから他の実装へ
ライトニングトークからは、QTNetがBINDを捨てて商用製品に乗り換えた話。
QTNetではBINDからNominum社のキャッシュサーバに移行したそうで、キャッシュヒット率95%のときでパフォーマンスがBINDの10倍(!)になったそうな。
・BIND卒業できました？
またもやBIND絡みのセッションですが、こっちはどちらかというと「権威DNSでは、まだBINDを完全には捨てられない」という話。
講演ではIIJ/さくらインターネット/GMOインターネットの3社が登場しましたが、このうちBINDを完全に捨ててるのはさくらインターネットのみ（商用製品＋nsdの構成とのこと）。
「nsdだとゾーン転送がいけてないので、セカンダリのリレー層はBINDのみ（IIJ）」「nsdはリフレッシュのときに必ずゾーン転送を試みるので、シャドウマスタへのトラフィックが高い（さくら）」「nsdはつくりが雑で、reconfig時やzone_status系のコマンド実行時にパケットを一瞬取りこぼす（IIJ）」など、クリティカルな現場ではまだBINDを一部使わざるを得ないようです。
他にも「トラブル時のログではBINDが一番優秀（GMO）」「将来的にはknotDNSが良さげなので使ってみたいが、まだ枯れてない（IIJ）」なんて声もありました。