## page was renamed from DNS/1/RFC/5452 ## page was renamed from DNS/基礎知識/RFC/5452 ## page was renamed from DNS/RFC/5452 #pragma section-numbers off == DNS/RFC/5452 == <> <> [[../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 <> == 6. Accepting Only In-Domain Records == 偽返答に対しては効果がない、と言えよう。 Aレコードを問い合わせたときに、CNAMEとその先のAが返ってくることがある。  tssさんの調査ではBINDはここのAは受け入れないそうだが、その理由がなになのか、明らかではない。 -- ToshinoriMaeno <> 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 <> == 9. Forgery Countermeasures == 提案はあるのだが、どれくらい実装されているのだろうか、現状の調査が必要です。 -- ToshinoriMaeno <> {{{ This document recommends the use of UDP source port number randomization to extend the effective DNS transaction ID beyond the available 16 bits. }}} この程度では不十分というのが我々の判断です。 -- ToshinoriMaeno <> Source port randomization in DNS was first implemented and possibly invented by Dan J. Bernstein. CNAMEについての考察はない模様。-- ToshinoriMaeno <>