RFC8020 要約メモ

  
Updates: 1034, 2308                                             S. Huque
Category: Standards Track                                  Verisign Labs
ISSN: 2070-1721                                            November 2016

NXDOMAIN: There Really Is Nothing Underneath

Abstract

The DNS protocol [RFC1035] defines response code 3 as "Name Error", or "NXDOMAIN" [RFC2308], which means that the queried domain name does not exist in the DNS. Since domain names are represented as a tree of labels ([RFC1034], Section 3.1), nonexistence of a node implies nonexistence of the entire subtree rooted at this node.

ドメイン名はラベルの木構造なのだから、あるノードが存在しない ("Name Error" or "NXDOMAIN") というなら、そのノードを根とする枝(サブツリー)全体が存在しないってこと。

Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name.
Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver.

ネガティブキャッシングは RFC 2181 にはオプションだって書いてあるけど、とても有効なのでもはやオプションだとは追うべきじゃない。

1.用語

"Negative caching" - the storage of knowledge that something does not exist. We can store the knowledge that a record has a particular value. We can also do the reverse, that is, to store the knowledge that a record does not exist. It is the storage of knowledge that something does not exist, cannot or does not give an answer that we call negative caching.

「ネガティブキャッシング」 - 何かが存在しないという知識の記憶。何かが存在しないという記憶があったらそれを Answer で答え(られ)ないというのがネガティブキャッシング。

"NXDOMAIN" - an alternate expression for the "Name Error" RCODE as described in [RFC1035 Section 4.1.1] and the two terms are used interchangeably in this document.

RFC 1035 では "Name Error" コードと言っているものの別表現。この文書ではどちらも互換なものとして両方使っている。

"NODATA" - a pseudo RCODE which indicates that the name is valid, for the given class, but are no records of the given type. A NODATA response has to be inferred from the answer.

"NODATA" - 名前としてはクラスに存在するが、問い合わせられたタイプのレコードはないという擬似レコード。(擬似なので) Answer から (そうであると) 推察されるべきなのが NODATA。

"FORWARDER" - a nameserver used to resolve queries instead of directly using the authoritative nameserver chain. The forwarder typically either has better access to the internet, or maintains a bigger cache which may be shared amongst many resolvers. (snip) However if you are being used as a forwarder the query will have the recursion desired flag set.

「フォワーダ」- 権威サーバを追う代わりに名前解決に使われるネームサーバ。インターネットにより良いアクセスを行ったり、多くのリゾルバたちと共有したりしてより大きなキャッシュを維持したりするのによく使われる。(RDフラグをセットして使う)

"QNAME": defined in [RFC1034] and in [RFC1035], Section 4.1.2, but, because [RFC2308] provides a different definition, we repeat the original one here: the QNAME is the domain name in the question section.

"QNAME" - Question Section のドメイン名 (RFC2308 では CNAME の(連鎖の最後の)値も指す)

"Denied name": the domain name whose existence has been denied by a response RCODE of NXDOMAIN. In most cases, it is the QNAME but, because of [RFC6604], it is not always the case.

"Denied name" (不存在名?) - NXDOMAIN 応答によって存在を否定されたドメイン名

2. Rule

When an iterative caching DNS resolver receives an NXDOMAIN response, it SHOULD store it in its cache and then all names and resource record sets (RRsets) at or below that node SHOULD be considered unreachable. Subsequent queries for such names SHOULD elicit an NXDOMAIN response.

反復検索するキャッシング DNS リゾルバは受け取った NXDOMAIN 応答をキャッシュに登録すべきであり、そのノードおよびそこから下のすべての名前と RRsets は存在しない (unreachable) と考えるべきである。

But, if a resolver has cached data under the NXDOMAIN cut, it MAY continue to send it as a reply (until the TTL of this cached data expires), since this may avoid additional processing when a query is received. Section 6 provides more information about this.

しかし、NXDOMAIN cut より下のデータをすでにキャッシュしていたら、TTL が切れるまではそれを応答してもよい。(それは避けうるかもしれないが)

The fact that a subtree does not exist is not forever: [RFC2308], Section 3, already describes the amount of time that an NXDOMAIN response may be cached (the "negative TTL").

RFC 2308 にあるように不存在は永遠ではなく、negative TTL の間だけ NXDOMAIN をキャッシュしてよい。

Warning: if there is a chain of CNAME (or DNAME), the name that does not exist is the last of the chain ([RFC6604]) and not the QNAME. The NXDOMAIN stored in the cache is for the denied name, not always for the QNAME.

警告: CNAME (や DNAME) の連鎖がある場合、存在しないのは連鎖の最後の名前であって QNAME ではない。キャッシュに登録される NXDOMAIN は "denied name" であって、いつも QNAME というわけではない。

As an example of the consequence of these rules, consider two successive queries to a resolver with a nonexisting domain 'foo.example': the first is for 'foo.example' (which results in an NXDOMAIN) and the second for 'bar.foo.example' (which also results in an NXDOMAIN).

ルールから導かれる帰結の例として、'foo.example' と 'bar.foo.example' の存在しない2つの名前が続けて引かれた場合を考えて見る。

 
Many resolvers today will forward both queries.

今日の多くのリゾルバは両方とも query を先へ投げることになる。

However, following the rules in this document ("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response, as a sign of nonexistence, and then immediately return an NXDOMAIN response for the second query, without transmitting it to an authoritative server.

しかし、"NXDOMAIN cut" を扱うこの文書のルールに従えば、最初の NXDOMAIN 応答をキャッシュしたら二つ目の query には権威サーバに転送することなく即座に NXDOMAIN 応答を返すことになる。

3. RFC のアップデート

3.1 RFC 1034 のアップデート

This document clarifies possible ambiguities in [RFC1034] that did not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719]) from nonexistent names, and it refers to subsequent documents that do.

本文書は RFC 1034 が Empty Non-Terminal (ENT) 名を不存在名と明確に区別していないと思われる曖昧さを明確にする。

3.2 RFC 2308 のアップデート

RFC2308 Section 5 の第2段落にはこうある

A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response.

Name error のキャッシュは同じ <QNAME, QCLASS> の別な query に対して否定応答を返すのに使われる。

この文書では以下のように改める

A negative answer that resulted from a name error (NXDOMAIN) should be cached such that it can be retrieved and returned in response to another query for the same <QNAME, QCLASS> that resulted in the cached negative response, or where the QNAME is a descendant of the original QNAME and the QCLASS is the same.

Name error (NXDOMAIN) のキャッシュは、同じ <QNAME, QCLASS> か QNAME が同じで元の QNAME の子孫の QNAME に対して否定応答を返すのに使われる。

(詳しくはSection 2)

4. 利益

上記の例のように2つの query が 1つですむなどキャッシュの効率化や権威サーバへのトラフック減に資すので DNS 全体のエコシステムの利益になる。

RFC 7816 の QNAME minimization に特に資する。(NXDOMAIN に遭遇したら検索をすぐに終わらせられるから)

"NXDOMAIN cut" は suffix がないことがわかればランダム QNAME 攻撃を緩和するのに役立つかもしれない。(balakrichenan-dafa888)
管理者が suffix に query を投げてやれば、"NXDOMAIN cut" により NXDOMAIN を受け取ったリゾルバは権威サーバへの query の転送をやめるだろう。
(NXDOMAIN に SOA レコードがあれば NXDOMAIN を見つけるのにさらに都合が良い。Appendix A 参照)

5. 可能性のある問題

example という TLD があったとする。foobar.example は存在しない。anything.foobar.example には NXDOMAIN が返る。ある管理者がトリックを使って組織内で使う office.foobar.example をローカルな権威サーバに向けたとしよう。先に foobar.example の不存在の名前が引かれてしまうと、office もないことにされてしまう。こういう設定は稀なので本文書ではサポートの必要なしとする。

今日、可能性のある別な問題がわかっている。ENT に対して NODATA ではなく NXDOMAIN を返してしまう権威サーバがみつかっている。

そういうネームサーバは絶対に間違いだが常に存在する。そしてそれらの振る舞いは DNSSEC と不整合である。”NXDOMAIN cut" の利点を活かすためには、こいつらのサポートする意味はほとんどない。

6. 実装の考慮

(省略)

7. セキュリティの考慮

The technique described in this document may help against a denial-of-service attack named "random qnames" described in Section 4.
If a resolver does not validate the answers with DNSSEC, or if the zone is not signed, the resolver can of course be poisoned with a false NXDOMAIN, thus, "deleting" a part of the domain name tree. This denial-of-service attack is already possible without the rules of this document (but "NXDOMAIN cut" may increase its effects). The only solution is to use DNSSEC.

注: この章は間違い。DNSSEC をつかっても DoS は可能。

以上