3 ms·
> No need to worry about expiration -- the DS record has none. > the DS record is signed by an RRSIG record that has an expiration You've just contradicted yo
by crotchfire 3y ago
> No need to worry about expiration -- the DS record has none.
> the DS record is signed by an RRSIG record that has an expiration
You've just contradicted yourself.
> No need to worry about expiration
If that were true, which it isn't, a MITM could keep feeding old signatures to the victim.
You seem to have little idea what you're talking about.
- cryptonector 3y ago> > No need to worry about expiration -- the DS record has none. > > the DS record is signed by an RRSIG record that has an expiration > You've just contradicted yourself. No contradiction there. I said that the DS RR doesn't have an expiration, and that's correct. The RRSIG RR has an expiration, but because the custom is that the zone operator resigns the contents periodically, it's a non-issue. The child delegation's operator doesn't have to take special action to have their DS "renewed", they only have to take special action to rotate the child zone's public keys. You don't have to worry about expiration because the parent should keep re-signing their zone. The expiration allows you to "revoke" by telling the parent the new keys and then delete the DS RRs for the old keys at a convenient time.