[Unbound-users] Increase RRset poisoning resistance

[7v5w7go9ub0o]

Ondřej Surý wrote:
>> 1. "poison a single address record" attack.
>>
>> This is when an attacker tries to match the qid/port of a request. This is
>> clearly is not an issue with unbound, which is well designed in
>> terms of randomness, and has first-rate test results; e.g.
>>
>>  <https://www.dns-oarc.net/oarc/services/porttest> )
> 
> Argh, not again...  Kaminsky-style attack is not about port randomization.
> Read his papers from doxpara.com...   It's just much more easier to poison
> cache if you don't do random ports.

Argh yes ...... The basic system design weakness remains.

But as a consequence of good randomness, the *likelihood* of being 
poisoned by an unverified response is reduced to almost zero - quite 
acceptable. In this first type of attack.

> 
>> Suggestion: That unbound incorporate additional logic to defend against a
>> "poisoned authority record" attack - logic in addition to its superior
>> port/qid randomization?
>>
>> This additional logic is: that an exact match, not merely an "in-bailiwick"
>> match be required before unbound would accept glue/RR record additions or
>> updates.
>>
>> It seems to me that little harm would result if unbound were instructed
>> to accept glue/RR records only from *exact* matches, and not from *inexact*,
>> but in-bailiwick authority records.
> 
> "seems to" and "little harm" are really dangerous words in context of DNS.
> There are lot of servers in the wild which doesn't do the right thing, there
> is a lot of inconsistencies in DNS data and that "little harm" you are speaking
> about could cause severe damage.

Well......yes, it ....... could .....

But we really don't know, do we! This second type of attack is much more 
threatening than the first, and no one else has any answers. FWICT
DNSSEC won't defend against it.

You're very likely right - it is not perfect. But it may prove to be 
very good in many applications.

Unbound is under active development at a time of "danger";  this is a
perfect opportunity to test some radical approaches that may work well 
99% of the time.

Put the option in with a default setting to "off"; not activated. Put a
little note next to it that this option is for beta testing.

This would allow folks to test it. It may work quite well in many
situations; not so well in others. A log entry could record when an
in-bailiwick RR record was rejected.

> 
> But I think this is not right place to discuss that.  This issue is
> spreads across
> platforms and servers and the right place (or just better place) to
> discuss this is
> namedroppers list (mailling list of dnsext working group @ ietf).  And
> you should
> probably start by reading archives before making suggestions, so you
> are not rehashing
> issues already discussed.

I will do that. Thank you.