メモ的ななにか

@Maleic1618

RFC 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Part 2)

ひとりRFCの旅 Advent Calender

こんにちは、まれいんです。

この記事は ひとりRFCの旅 Advent Calender 8日目の記事です。

qiita.com

今回も前回に引き続き、RFC 5155を読んでいきます。

RFC 7129? 知らない子ですね...

予告していた通り、権威サーバのNSEC3の配置と返すべき応答(そしてリゾルバの検証)についてみていきます。

どのようなNSEC3リソースレコードを持っておくべきか

RFCが定める、権威サーバ側のNSEC3についての要求は以下です。 文章をリストアップしつつ引用します。

  • ゾーン内に権威を持つRRsetを保持する所有者名は、対応するNSEC3 RRを持たなければならない(MUST)。
  • 未署名委任に対応する所有者名は、対応するNSEC3 RRを保持してもよい(MAY)。
  • ただし、対応するNSEC3 RRが存在しない場合は、委任の次近接名をカバーするOpt-Out NSEC3 RRが存在しなければならない(MUST)。
  • 他の権威を持たないRRはNSEC3 RRには表記されない。
  • 空の非終端(empty non-terminals)は、Opt-Out NSEC3 RRがカバーする"Insecure"な委任から派生しているのでない限り、対応するNSEC3 RRを持たなければならない(MUST)。
  • (TTL, タイプビットマップについては省略)

どのような応答を返すべきか

ここでは権威サーバ側がどのような応答を返すべきかについて触れます。 RFCには同様にリゾルバ側はどのような検証を行うべきかについて触れられていますが、権威サーバ側が分かれば検証すべき内容も分かってくると思われるので、ここでは触れないこととします。

Closest Encloser の証明

この後、あるドメイン名がクエリ名に対するclosest encloserであることを証明する必要がちょくちょく出てきます。

closest encloserは「存在するドメイン名の中で最長の後方一致するもの」なので、

  • 存在することを証明するためにそのドメインが存在することを証明するために、そのドメイン名のNSEC3
  • 最長の後方一致であることを示すために(=つまりnext closer nameの不在を証明するために)、next closer nameをカバーするNSEC3

の2つが必要となります。(当然これらは一致している場合もあります)

NXDOMAIN

クエリ名が存在しないことを示すには、クエリ名そのもの、またはその親ドメイン名の不在を示すことに加えて、ワイルドカードケアでクエリ名のSource of synthesisの不在を示す必要があります。

以下の応答があればOKです。

  • closest encloserのドメイン名のNSEC3
  • next closer nameをカバーするNSEC3
  • *.<closest encloser> をカバーするNSEC3

DSリソースレコード以外のNODATA

(存在する)クエリ名にクエリタイプのリソースレコードがないことが分かればよいので、以下の応答があればOKです。

  • クエリ名のNSEC3

DSリソースレコードのNODATA

「DSリソースレコードがある ⇔ "secure" な委任」ですから、「DSリソースレコードがない ⇔ 自分に権威があるドメイン名 or "insecure"に委任されたゾーン下のドメイン名」であることに注意する必要があります。

自分に権威がある場合は、対応するNSEC3が存在するのでそれを返せばOKです。

"insecure"に委任されたゾーン化のドメイン名である場合は、どこかで委任されているはずです。 委任点のドメインについてはNSEC3リソースレコードがあってもよくてもよいということになっていました。(上記の記載を引用)

未署名委任に対応する所有者名は、対応するNSEC3 RRを保持してもよい(MAY)。

対応するNSEC3があればそれを返せばOKです。

ない場合はclosest provable encloserのNSEC3とnext closer nameをカバーするOpt-Out NSEC3を返せば、"insecure"な委任をされていることが分かります。

Wildcard no data

Source of synthesisとなるワイルドカードはあるものの、そのワイルドカードドメインに対応するクエリタイプのリソースレコードが存在していない場合です。

ワイルドカードドメインに対応するクエリタイプのリソースレコードがないことと、前述のワイルドカードドメインがクエリ名のSource of synthesisであることを示す必要があります。

というわけで以下の応答があればOKです。

Wildcard Answer

ワイルドカードによる一致で応答が返された場合、そのワイルドカードの一致が正しいことを示さなければなりません。

というわけで以下が示されればOKです。

NSEC3の署名者名に対する応答

クエリ名 = あるハッシュ化ドメイン名 の場合は場合分けが必要です。

  • クエリ名が(あるハッシュ化ドメイン名と同一であると同時に)そもそもあるドメイン名(Empty non-terminalsかもしれない)と同一である場合で、このときはこのドメイン名についての応答を返します。(NOERROR or NODATA)
  • そうでない場合はNXDOMAINを返します。

名前衝突時

クエリ名に対応するハッシュが、既存のハッシュ化ドメイン名とうっかり衝突してしまった場合です。 この場合は適切な不在証明ができないため、SERVFAILを返します。