Re: [DNSOP] Fw: New Version Notification for draft-bellis-dns-recursive-discovery-00

[Alex Bligh <[e-mail]>]

--On 21 October 2009 08:34:39 +0000 Florian Weimer <[e-mail]> wrote:

>>> Mark, I din't think this is true given how the proposed protocol
>>> works.  For a start, you often cannot fetch the DNSKEY RR for ARPA
>>> before running the protocol.
>>
>> Indeed LOCAL.ARPA would need to be unsigned.
>
> Not really.  Why would it need to exist in the public tree at all?
> All we need is agreement from both ICANN and IETF that LOCAL.ARPA is
> reserved and not to be delegated in the official tree.

OK, let's try this one again. LOCAL.ARPA is not delegated at all.
It is unsigned.

Necessarily, ARPA. will have no records for LOCAL.ARPA (except
perhaps pointing at a sink). Each of the individual LOCAL.ARPA
instances run by recursive nameservers have different administrators.
Whilst it would be theoretically possible to sign them, this would
achieve no purpose as anyone operating a recursive nameserver would
need to sign them.

Moreover the queries into DOMAIN.LOCAL.ARPA are going to be made
in an environment where we suspect DNSSEC queries don't work, as
there is, ex hypothesi, possible a misbehaving proxy in the way.
Therefore, queries will likely be made with DO clear (that
should be in the draft too).

So there are two separate security risks: cache poisoning on the
recursive server (this needs addressing and I have some ideas),
and a theoretical Kaminsky style attack on the individual
non-DNSSEC queries to DOMAIN.LOCAL.ARPA. There are some obvious
mitigation strategies here (such as uRPF on customer facing edges
and not taking source IP addresses from critical server ranges
on other edges), but I'm not sure that ultimately this one needs
addressing. Firstly, it can only be used against individual
clients and requires some heuristic knowledge of when the query
is going to be made. Secondly, all you "win" is the ability
to spoof insecure queries. However, it would be possible to
avoid even this, e.g. with a nonce in the QNAME.

-- 
Alex Bligh