イベントレポート

Internet Week 2020

利便性の追求で、DNSのリソースレコードの種類が増える ほか

~今年の「DNS DAY」の話題から

利便性の追求で、DNSのリソースレコードの種類が増える

 JPRSの藤原和典氏による「DNSプロトコルの進化」では、2016年以降のDNSプロトコルの標準化状況を中心に解説が行われた。今回は、その中からDNS関係者の関心が高そうな話題に絞って取り上げる。

 最初に取り上げるのは、RFC 8767「Serving Stale Data to Improve DNS Resiliency」の話題である。これは、何らかの理由で所定の権威DNSサーバーから応答が得られなかった場合、サービスの停止を回避するために期限切れになったキャッシュデータを用いた名前解決を可能にしようとする提案である(図22)。仕様としては、期限切れとなったのち、最大7日までのデータをTTL 30(30秒)で応答するようだ。すでに実装も進んでいるとのことである。

図22 RFC 8767「Serving Stale Data to Improve DNS Resiliency」

 SVCBリソースレコード(RR)とHTTPS RRは現在ドラフト段階にある提案で、インターネット上のサービスへのアクセスに関する指示をクライアントに提供するためのものである。HTTPS RRは、HTTPS接続のためのSVCBのバリエーションの1つである(図23)。

図23 SVCB RRとHTTPS RRの解説(1)

 これらのRRを使用するとゾーン頂点(APEX)に別名を書けるため、ウェブサイトをCDNに対応させる際、ゾーン頂点にCNAMEを書けないという問題に対応できるようになる。すぐにでも使いたい管理者は多いのではないだろうか。スライドの例には、以下のように書かれている。

 @ 7200 IN HTTPS 0 pool.svc.example.

 この意味は、HTTPSサービスではゾーンファイルのドメイン名(@)に対し、「pool.svc.example.」という別名を割り当てる、ということになる。

 藤原氏によると、理論については合意がされつつあるとのこと。提案の著者の所属がGoogleおよびAkamai Technologiesであり、謝辞にApple、Mozilla、CloudflareといったウェブブラウザーベンダーやCDNの関係者が並んでいることから、すぐに実装が進む可能性があるということである(図24、図25)。

図24 SVCB RRとHTTPS RRの解説(2)
図25 SVCB RRとHTTPS RRの解説(3)

 RFC 8914「Extended DNS Errors」は、EDNS0を用いてDNSエラーに関する追加情報を提供できるようにするためのプロトコル拡張方式である(図26)。これまで、DNSのRCODEでは名前解決でエラーが起こったことしか分からず、原因追求がしにくいという問題があったが、これによりDNSエラーに関する追加情報をクライアントに返せるようになる。管理者にとっても、名前解決トラブルの切り分けに有用な情報となるのではないだろうか。

図26 RFC 8914「Extended DNS Errors」の説明

 最後に、「draft-ietf-dnsop-avoid-fragmentation」を取り上げる。これは、IPフラグメンテーションを使ったDNSのキャッシュ汚染攻撃対策においてIPフラグメンテーションを回避するため、問い合わせを送る側・受け取る側の双方でPath MTUの値を意識し、フラグメントしない範囲でDNS応答をUDPで送るようにしようと提案するものである(図27)。そのためのEDNS0バッファサイズの設定値はPath MTUからIPヘッダーとUDPヘッダーのサイズを引いた値になり、DNS Flag Day 2020では、1232を推奨している。DNS管理者の皆様は、運用中のサーバーのEDNS0のバッファサイズの設定を見直してみていただきたい。

図27 draft-ietf-dnsop-avoid-fragmentation

 以前のDNSにおける標準化では、新しいデータが追加されてもリソースレコードの種類をあまり増やさない方向にあった。しかし、2009年に発行されたRFC 5507「Design Choices When Expanding the DNS」で「新しいデータをDNSに追加する場合、リソースレコードの追加が好ましい」とされて以降、新たなリソースレコードを追加する方向で標準化が進められるようになっている。そのため、適切に情報収集をしていかないと大事な部分を見落とすことにもなりかねない。その意味で、IETFから出る情報をきちんと追いかけることの重要性が高まっている。ISOC-JPやJPNIC、JPRSなどから定期的に報告も出ているので、チェックするようにしてみてはいかがだろうか。

 今回、初めての完全オンライン開催ということで、どうなるか心配が無かったといえば嘘になる。しかし、発表された内容を見る限り杞憂であったし、出される情報の量・密度ともに、対面での開催と変わらないものであった。ここで書いた内容は、全体のほんの一部でしかない。講演者には多くの質問が投げかけられ、丁寧に答えていた。

 DNS DAYの終了後、日本DNSオペレーターズグループが主催する「日本DNSオペレーターズグループ BoF」も行われたが、そちらも盛況であった。11月に発表されたキャッシュポイズニングの手法「SAD DNS」に関する情報共有など、興味深い話も多く有意義であった。来年のInternet Weekが楽しみである。