Mark Andrews, Thursday, April 12, 2012 11:43 PM: > -----Original Message----- > From: Mark Andrews [mailto:ma...@isc.org] > Sent: Thursday, April 12, 2012 11:43 PM > To: Stephan Lagerholm > Cc: Ralf Weber; Marc Lampo; Nicholas Weaver; dnsop@ietf.org; Livingood, > Jason > Subject: Re: [DNSOP] on "Negative Trust Anchors" > > In message > <dd056a31a84cfc4ab501bd56d1e14bbbd2e...@exchange.secure64.com>, "Steph > an Lagerholm" writes: > > Mark Andrews Thursday, April 12, 2012 6:10 PM: > > > > > > On 12.04.2012, at 14:21, Marc Lampo wrote: > > > > > > It holds an alternative possibility to overcome the problem > > > > > > - for operators of validating name servers - of failing > > > > > > domains because of DNSSEC. > > > > > > > > > > > > The alternative is to have a parent regularly (no frequency > > > > > > defined) check the coherence of DS information they have > > > > > > against DNSKEY information it finds published. > > > > > > If the parent detects "security lameness" (term used in > > > > > > RFC4641bis) its possible reaction could be to remove the DS > > > information. > > > > > > > > =3D> From my experience, "active parenting" is not a good > practice. > > > > Specifically in this case, you are assuming that the parent knows > > the > > > > algorithms used for the DS record. He would have to in order to > > > > validate. That might not always hold true. Additionally, the > > > > record > > > is > > > > not 'yours', it is just parked in your zone by the child. For the > > > > parent to Tamper with either the NS or DS is IMHO not a good > > > practice. > > >=20 > > > There is a difference between "Tamper" and "Hey, you stuffed up. > > > You need to fix the delegation or we will remove it as it is > causing > > >operational problems" and yes there *are* RFCs that permit this to > > >happen. > > > > Being Insecure is not necessary better than being Bogus. "Hey you got > > hacked, so we will remove the DS so that people can get to that bogus > > site" > > I said remove the delegation. Get their attention as doing anything > else doesn't work.
I have yet to understand how your parent to child DNS probes works. Specifically, if you can explain to me how you are distinguishing between: A) The DS and the DNSKEY does not match because there is an operational error at the child And B) The DS and the DNSKEY does not match because somebody is doing a "man in the middle" on my probes. Going back to the original claim that " alternative is to have a parent regularly check the coherence of DS information and that a possible reaction could be to remove the DS" I'm not supportive of such "active parenting" idea. I find the idea of negative trust anchors useful for recursive resolvers given that the operator of such recursive resolver uses a secure out of band technology to make sure that there is an operational mistake. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
