An explicit exception could be made for "locally served zones," which would include RFC1918 zones. We've thought a lot about this problem in homenet; the conclusion we ultimately drew is that it's way too hard to try to come up with a ToFu solution that adds value, and anything that's not automatic is useless. So we concluded that if you want DNSSEC, the right way to do it is to have a delegation from the root. If you don't have the wherewithal to do that, you don't get DNSSEC on the homenet.
We also considered the case of DNSSEC for reverse mapping zones. I don't know if I can safely say "we" here because I just presented my conclusion and nobody argued with it. But my conclusion was that I couldn't think of a threat model that justified the complexity of signing a locally-served reverse mapping zone. The reverse mapping zone is of very limited utility. People occasionally use it for authentication, but I think there's a pretty clear lack of consensus in the IETF that this is a good idea, since it gets shouted down every time anyone mentions it. The other use is for annotating logs. That's just not something that's useful enough that attacking it makes sense even if the attack is easy. Any complexity that is added to make the attack harder than it already is is simply adding risk, not removing it. Because of the experience with homenet, I actually sort of disagree with you about needing a general solution for this. I think that the general solution for this is not to do it. If there are some specific corner cases where doing it makes sense, then yes, having a document that talks about the problem and how to mitigate the risks makes sense, but the mitigation strategy is most likely always going to be solution-specific anyway, as it is here. On Tue, Nov 27, 2018 at 10:02 AM Tony Finch <d...@dotat.at> wrote: > Ted Lemon <mel...@fugue.com> wrote: > > > > Snipped and edited to add numbering for reference... > > > 4. Split DNS, DNSSEC, trust anchor required because the hidden zone is > > under or at an unsigned delegation > > > > 5. Split DNS, DNSSEC, trust anchor required because the hidden zone has > > a secure delegation that won't validate > > [ snip lots of stuff I agree with ] > > > In cases four and five, you care enough to set up DNSSEC, but either > > can't be arsed to do it right, or don't have control over the delegation > > point and so can't do it right. In the former case, I would argue that > > we should just say too bad. In the latter case, we have just protected > > the end user from being attacked by saying too bad. > > Case 4 is pretty common for RFC 1918 reverse DNS :-) > > Really, I don't think this is (just) a VPN issue: the question of how to > install DNSSEC trust anchors for private zones has not been solved for the > general case, so a VPN-only patch seems premature and unhelpfully specific > to me. > > Tony. > -- > f.anthony.n.finch <d...@dotat.at> http://dotat.at/ > an equitable and peaceful international order >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
