* Alex Bligh: > --On 21 October 2009 08:34:39 +0000 Florian Weimer <fwei...@bfk.de> 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.
If it is not delegated, it will be signed (as Mark pointed out). > Necessarily, ARPA. will have no records for LOCAL.ARPA Then its non-existence will be signed. > 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. Right. (Otherwise, you wouldn't use class IN for this stuff.) > 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. Don't worry too much about spoofing from off-path attackers. ISPs have plenty of means to prevent it (granted, for IPv4 directly over Ethernet, there's no standard way of doing things which conserves address space, but that's a different issue). As I've tried to explain, spoofing by the resolver operator itself is the relevant issue here. It breaks the proposed protocol. Please tell me how I can explain this in a better way---perhaps I shouldn't say "spoofing" but "DNS rewriting", "NXDOMAIN redirection", "Sitefinder", "online help page", or something else, but it's really spoofing. Note that this problem will not go away when you bring LOCAL.ARPA or DOMAIN.LOCAL.ARPA into existence. People say "NXDOMAIN redirection" but they really mean "arbitrary DNS manipulation". It doesn't stop at NODATA response or the second level of the tree. -- Florian Weimer <fwei...@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
