[第117回IETF Meeting報告] DNS関連WG、及びDNS関連技術を用いた提案の状況

本記事では、第117回IETF Meetingにおける話題から、DNS関連WGの状況と、DNS関連技術を用いた提案の状況についてご紹介します。

dnsopはDNS Operationsに由来しており、権威DNSサーバー・フルリゾルバーや登録情報の管理など、DNSの運用全般に関するガイドラインの作成を目的としています。WGでは、運用上の課題に着目したDNSプロトコルの拡張・メンテナンスについても、活動項目としています。

DNSの用語を定義する、RFC 8499を更新する提案です。本提案はJPRSの藤原和典が共著者となっています。

本提案では、委任先のゾーンとネームサーバーホスト名の関係を表す用語の定義が、RFC 8499から変更されています。RFC 8499では内部名に相当する用語として「In-domain」と「In-bailiwick」の2種類が定義されていますが、bailiwickの定義が混乱を引き起こしているとして、In-bailiwickと外部名に相当する「Out-of-bailiwick」の双方を歴史的（historic）と見なして使用を避け、Out-of-bailiwickは無関係を意味する「Unrelated」とすることを提案しています（図1）。

また、WGでは不完全な委任を示す「lame delegation」の定義に関する議論が進められ、lame delegationが具体的に何を表しているかについて、明確な合意がないことが再確認されました。本提案では議論の結果を受け、lamedelegationについては歴史的と見なして使用を避け、定義が明確な他の用語・表現を優先して使うようにすべきである、としています。

本提案はこれまでの議論の結果、WGでの合意が形成され、IESGへの提出手続きが進められています。

DNSにおけるIPフラグメンテーション^[*1]を回避するための手法についてまとめた提案です。本提案はJPRSの藤原和典が第一著者となっています。

WGでは、提案で推奨事項の一つとなっているIPv4におけるDF（Don't Fragment flag）ビットの有効化が、すべてのDNSソフトウェアで実装されていない旨が報告されました。本提案はWGでの合意形成に向けたWG Last Callが実施された後、WGチェアの判断待ちの状態になっており、継続して作業が進められる予定になっています。

一つのDNSメッセージに含めることができる問い合わせの数は通常、1であることを明確にし、DNSの仕様を更新・補足するための提案です。

DNSメッセージのヘッダーには問い合わせ（Question）セクションの数を指定するパラメーター（QDCOUNT）が含まれており、QDCOUNTに1より大きな値を設定することで、一つのDNSメッセージで複数の問い合わせを送ることができるかのように見えます。

しかし、もし一つのDNSメッセージに問い合わせが複数個含まれていた場合、応答にセットされるAAビット^[*2]やRCODE^[*3]がどちらの問い合わせに対するものかを通知・判断する方法がないため、1より大きな値は意味を持ちません。

本提案では、現在使われている4種類のDNSメッセージ（0：通常問い合わせ、4：NOTIFY、5：UPDATE、6：DSO）におけるQDCOUNTの仕様を確認し、以下のように結論付けています。

• 通常問い合わせについては仕様が明確でないため、QDCOUNTに1より大きな値を設定してはならず、設定されていた場合は不正なメッセージとしてFORMERR（フォーマットエラー）を返さなければならない旨を追加定義し、仕様を明確化する
• NOTIFY・UPDATE・DSOについては仕様上、QDCOUNTに1より大きな値を含めてはならない旨が指定されているため、追加定義は不要である

WGでは上記を踏まえた議論が進められ、本提案は継続して作業を進めることになりました。

子のCDS/CDNSKEYリソースレコード（以下、RR）^[*4]やCSYNC RR^[*5]の変更によって自身のDS RRや委任情報を更新する場合、子の権威DNSサーバーにおける設定内容の一貫性の事前確認を必須とする提案です。

具体的には、親が子のCDS/CDNSKEY/CSYNC RRの変更を検知した場合、子のすべての権威DNSサーバーのCDS/CDNSKEY/CSYNC RRの設定内容を調べ、同一であることを確認した後に自身のRRを更新するようにすることで、運用上の信頼性を向上させます。

本提案について、親のDS RRの自動更新において子のCDS/CDNSKEY RRの一貫性の確認が必要であることについては特に異論はなく、継続して作業を進めることとなりました。

一方、CSYNC RRの変更を契機とした親の委任情報の自動更新については参加者から「CSYNC RRによる自動更新の仕組みは好きではない」「およそ15年前に.seで問題が発生したことがある」「子が全員同意することで親の委任情報を自動更新するという考え方は危険である」などの指摘があり、合意は得られませんでした。

参加者からは「CSYNCについては最初からやり直す必要があるかもしれない」という指摘もあり、今後、根本的な見直しが行われる可能性もあります。

ACME^[*6]に関する技術を取り扱うacme WGにおいて、従来のdns-01を拡張するdns-account-01という認証方式が提案されています。

ACMEではDNSを用いた認証方式として、dns-01が定義されています。dns-01では「_acme-challenge」という認証用のサブドメインに、認証局が準備したチャレンジ文字列をTXT RRで設定します。

dns-01を使って複数の認証局からサーバー証明書の発行を受ける場合、_acme-challengeサブドメインに複数のTXT RRを設定することになります。しかし、サービスプロバイダーが_acme-challengeにCNAME RRを設定する形で証明書発行サービスを提供しているケースなど、サービス仕様・サービス運用上の制限により、_acme-challengeに複数のTXT RRを設定できない場合があります。

dns-account-01では認証用のサブドメインを_acme-challengeから「_acme-challenge_ACMEアカウントに固有の文字列」に変更することで、認証用のサブドメインをACMEアカウントやサービスプロバイダーごとに分割できるようにし、こうしたケースでの不都合の発生の防止を図っています。