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. > > > > => 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. > > 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" > Parents are already REQUIRED to make these sorts of checks of the > records involved in the delegation according to RFC 1034. If you do an algorithm rollover, then you will have two DS at the parent but only one will correspond to a DNSKEY at the zone. > As for not knowing the DS algorithm what is just garbage. For DS > records to be useful the algorithms need to be well known. There are > no private DS algorithms. That is not how I read RFC 4034, section 5.1.2 and appendix A.1. What am I missing? "The algorithm number used by the DS RR is identical to the algorithm number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm number types." 5 RSA/SHA-1 [RSASHA1] y [RFC3110] MANDATORY 252 Indirect [INDIRECT] n - 253 Private [PRIVATEDNS] y see below OPTIONAL 254 Private [PRIVATEOID] y see below OPTIONAL 255 reserved /S _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
