要約

  • ANYは質問の型であり、質問する名前のワイルドカードやゾーン転送ではない。キャッシュから得た回答も、すべての権威データの一覧とは限らない。
  • RFC 8482は、空でない小さな応答を普通に保存させることで、同じANY問い合わせの繰り返しを減らす任意の方法を示した。
  • 合成HINFOは既存の形式を利用できる一方、本来のHINFOをキャッシュで隠す場合がある。TTLは現在の負荷を減らす時間であると同時に、方針変更が遅れて届く時間にもなり得る。

名前の欄は消えていない

問い合わせの種類をANYに変えると、何でも返ってくるように思える。しかしDNSの質問には、何という名前について、どの型を、どのクラスで尋ねるかという区別がある。型を広げても、名前を指定する作業まで消えるわけではない。

1987年11月の RFC 1034 は、QNAME、QTYPE、QCLASSを分けている。QTYPEのANYはQNAME中のワイルドカードではなく、ゾーン転送のためのAXFRでもない。一つの名前を調べる質問から、ゾーン内のすべての名前を列挙する機能は生まれない。

同じ文書の処理手順は、ゾーンのデータとキャッシュも分ける。キャッシュに一致する情報があれば、それを回答に使う経路がある。その場所に、権威サーバーが知る全種類の情報がそろっている保証はない。

つまりANYを情報の棚卸しに使う前には、二つの期待を外す必要がある。すべての名前を返す質問ではなく、ある名前についても常に全種類を集め直して返す質問とは限らない。

星印から「一部または全部」へ

RFC 1035 では、質問型255は星印で表されていた。実装で一般的に使われる呼び名がANYである。広い言葉ではあるが、具体的な応答の範囲を無条件に拡大する言葉ではない。

現在の IANA DNSパラメーター登録表 は、255をサーバーが利用できるレコードの一部または全部を求めるものとして説明している。一方、HINFOはホスト情報を表す型13として残っている。

登録表から分かるのは識別子とその意味だ。現在のサーバーがどれほど同じ方式を使っているか、あるいはある型が実際にどれだけ利用されるかという調査結果ではない。

この意味の整理に具体的な応答方法を与えたのが、2019年1月の RFC 8482 だった。RFC 1034とRFC 1035を更新する標準化過程の文書であり、送受信側双方に任意の動作を示している。ANYそのものを廃止したわけではない。

断ったはずが、別の相手へ質問が続く

ANYには正当な用途がある。文書は、デバッグや、ある名前についてサーバーの状態を調べる作業を挙げる。メール用のMX、A、AAAAなどを一度の質問で得ようとする使い方もあった。

ただしアプリケーションは、その質問が必ず権威サーバーに届き、既存の全RRsetを集めると仮定してはならない。必要な結果が得られない場合の別の手段が要る。質問回数を減らす便利さと、必要な情報を必ず入手する責任は別だった。

応答側にも事情があった。小さなUDP質問が大きな回答を引き出せると、送信元を偽る反射型の攻撃に利用しやすくなる。従来のANY応答を作るために余分な処理を必要とする実装もあった。情報をまとめて収集されることへの懸念も、文書に記された理由の一つである。

これはANYを使う人すべてが攻撃者だという意味ではない。また、回答を小さくしても、他の公開DNS情報が秘密になるわけではない。ここで現在の攻撃件数や削減率を測っているのでもない。

検討された案には、通常のANY応答を提供しないことを新しい応答コードで示す方法があった。しかしRFC 8482によれば、知らないコードを受けたリゾルバーは、利用できる他の権威サーバーにも同じ質問を送った。拒否を明確にするつもりが、問い合わせを終わらせられなかったのである。

そこで、空でないRRsetを返す。既存のクライアントには、普通にキャッシュできるものが残る。新しい拒否の意味を覚えさせなくても、同じ名前へのANYの繰り返しを減らせる。文書が説明するこの比較を、すべてのエラーが常に同じ再試行を起こすという一般則にはできない。

一組返すことと、一組を削ること

RFC 8482がここで扱うのは、存在する名前、クラスIN、質問型ANYである。明示された変更以外では通常の手順に従う。存在しない名前を勝手に存在することにしてよいわけではない。

最初の方法は、その名前にあるRRsetを一つ、または少数選んで返すものだ。文書は、利用可能な他の集合が省かれたことを知らせる信号はないと明記する。この回答にTXTがないことだけでは、TXTそのものが存在しないとは言えない。

RRsetの単位にも注意が要る。1997年7月の RFC 2181 は、名前、クラス、型が同じで、データが異なり得るレコード群を一組とする。複数のアドレスを含む組から、適当に一つだけ抜き出して組全体を返した扱いにはできない。

選んだ組は通常の完全性を保つ。必要な組が全部入らなければ、切り詰めの規則が関係する。返す型を少なくすることと、一つの組を不完全にすることは違う。

TCビットも、この区別を消すものではない。必要なRRsetが全部収まらない場合の処理と、意図的に少数の型を選ぶことを混同してはならない。TCが立っていない回答を見ても、その名前の全種類を列挙し終えた証明にはならない。

CPU欄に入った標準番号

二つ目の方法は、該当する名前にCNAMEがない場合にHINFOを合成するものだ。一件のHINFOで、CPUの文字列をRFC8482、OSの文字列を空にすることが推奨される。ゾーンの保存データへ恒久的にそのレコードを書き足す要求ではない。

HINFO自体は古い。RFC 1035はCPUとOSの二つの文字列を定義し、同じ種類の機械やOSに応じてFTPなどが処理を変えられる用途を説明した。新しい方法は、その既存の形を借りる。

明示的にこの方法で作られたレコードなら、CPU欄のRFC番号は実測したプロセッサーの種類ではない。空のOS欄も長さゼロの文字列として存在し、機械にOSがないという調査結果ではない。

とはいえ、受信したHINFOの値だけから、必ずこの仕様による合成だと決めることはできない。RFC 8482は、その推定を根拠に特別な処理をすることを戒めている。文字列は、合成された由来を確実に証明する印ではない。

一方で、通常の保存は認められる。文書は、対応するHINFOがキャッシュにあるときANYを抑制する任意の動作や、普通にキャッシュから答える方法も述べる。キャッシュしてよいことと、任意のレコードの作成経路を断定してよいことは、同じではない。

元の用途には、空席ではなかった

合成HINFOがキャッシュに入ると、後でHINFOを直接求めた質問にもその内容が返され、ゾーンに残る本来のHINFOを隠す場合がある。RFC 8482はこの副作用を明示した。

従来のホスト情報を実際に利用するゾーンでは、既存RRsetを返す方法や別の型を選ぶべきだとする。作者たちが当時HINFOはまれだと考えていたとしても、利用者が一人もいないことにはならない。その観察を、現在の普及率として使うこともできない。

三つ目の方法は、利用者が欲しそうな情報を推測し、存在するCNAME、MX、A、AAAAの組を返して、TXTやDNSKEYなどを省くものだ。必要に合うアプリケーションもある一方、他の最小化方法より回答が大きくなることがあり、意図を必ず理解できるわけでもない。

したがって、合成HINFOだけが正解なのではない。既存の意味を使い続ける環境を考慮し、方法を選ぶ余地も設計の一部だった。

キャッシュに残す時間は、変更を待つ時間にもなる

合成HINFOのTTLは、同じ発信側が同じ名前に頻繁にANYを繰り返すのを抑える程度に長くする。しかし長すぎれば、その後の応答方針の変更を反映しにくい。RFC 8482は設定可能な値として扱い、万人向けの秒数を指定していない。

RFC 2181が述べるようにTTLは保持の上限であり、必ずその時間まで保持する義務ではない。全リゾルバーが同時に忘れる保証も、権威側の設定変更で遠隔キャッシュが一斉に消える保証もない。

この時間的な効果こそ、問い合わせを減らす理由だった。同時に、古い方針の効果が局所変更の後にも残り得る理由でもある。便利さを説明するときだけ持続性を持ち出し、変更の話では消してしまうことはできない。

省略と不存在を分ける

1998年3月の RFC 2308 は、名前のエラーであるNXDOMAINと、有効な名前に求めた型がないことを回答内容から判断するNODATAを区別する。NODATAは独立した応答コードではない。否定的な回答のキャッシュにはSOAなどの条件が関係する。

ANYに対してHINFOや少数の組が返ったことは、すべての省略された型に対する否定ではない。アプリケーションが必要とする型は、その型として問い合わせなければならない。

署名も範囲を広げない。2001年12月の RFC 3225 で説明されるDOは、DNSSECの安全性に関するレコードを受け取れるという通知であり、検証済みの意味ではない。

RFC 8482は各方法の署名条件を残している。合成の場合、DOが一で、応答側が署名付きゾーンと知っていれば有効なRRSIGが必要で、DOがゼロならその分岐では省くことが推奨される。小さくする目的が、その条件を免除するわけではない。返した組の真正性と、返さなかった型を含めた一覧の完全性は別である。

また、TCPでは通常、UDPでは最小というように、転送方式によって方針を変えることも許される。ただしそれは例であり、TCPへ変えればどこでも全部の情報が出るという約束ではない。