In message <[email protected]>, "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. > > 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. Garbage. You don't add DS records until there are DNSKEYs for the algorithm and you remove all DS records for the old algorithm *before* you remove the DNSKEY for the old algorithm. If you fail to do this you will introduce validation failures. You can have DS records that don't correspond to a DNSKEY but the algorithm MUST match one that does correspond to a DNSKEY. This lets you publish a single KSK DNSKEY per algorithm. > > 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.=20 > 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=20 > 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 DS records have a DNSSEC algorithm which matches the DNSKEY and a DS hash algorithm. You can compute a DS record without knowing the DNSSEC algorithm. You can match DS records to DNSKEY records without knowing the DNSSEC algorithm. You do need to know the DS hash algorithm and there are no private DS hash algorithms. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
