MoinQ:

DNS/RFC/5452

Contents

  1. DNS/RFC/5452
  2. 受け入れられる返答
  3. 6. Accepting Only In-Domain Records
  4. 9. Forgery Countermeasures

../2181 (1997) 5.4.1. Ranking data

http://tools.ietf.org/html/rfc5452　　　(2009年1月）

これはいいことが書いてあった。 

Even a cryptographically secured DNS benefits from having the ability
to discard bogus responses quickly, as this potentially saves large
amounts of computation.

受け入れられる返答

To understand how this process works it is important to know what
makes a resolver accept a response.

   The following sentence in Section 5.3.3 of [RFC1034] presaged the
   present problem:

     The resolver should be highly paranoid in its parsing of responses.
     It should also check that the response matches the query it sent
     using the ID field in the response.

という状態なので、議論は RFC 1034 から一歩も進んでいない。 -- ToshinoriMaeno 2014-11-21 11:07:11

6. Accepting Only In-Domain Records

偽返答に対しては効果がない、と言えよう。

Aレコードを問い合わせたときに、CNAMEとその先のAが返ってくることがある。

-- ToshinoriMaeno 2013-11-23 05:21:41

RFC 5452 DNS Resilience against Forged Answers January 2009 

6. Accepting Only In-Domain Records

   Responses from authoritative nameservers often contain information
   that is not part of the zone for which we deem it authoritative.  As
   an example, a query for the MX record of a domain might get as its
   responses a mail exchanger in another domain, and additionally the IP
   address of this mail exchanger.

   If accepted uncritically, the resolver stands the chance of accepting
   data from an untrusted source.  Care must be taken to only accept
   data if it is known that the originator is authoritative for the
   QNAME or a parent of the QNAME.

   One very simple way to achieve this is to only accept data if it is
   part of the domain for which the query was intended.

この記述の前段がおかしいのだが、Kaminsky型攻撃を別にすれば、そして、性能を考慮しなければ、 問題にするほどのことではない。

だが、Kaminsky型攻撃の性能をあげさせることにつながるので、...

-- ToshinoriMaeno 2013-11-23 23:28:51

9. Forgery Countermeasures

-- ToshinoriMaeno 2014-11-21 11:08:52 

   This document recommends the use of UDP source port number
   randomization to extend the effective DNS transaction ID beyond the
   available 16 bits.

この程度では不十分というのが我々の判断です。 -- ToshinoriMaeno 2014-11-21 11:10:51

Source port randomization in DNS was first implemented and possibly invented by Dan J. Bernstein.

CNAMEについての考察はない模様。-- ToshinoriMaeno 2016-07-15 11:46:22