> On 21 Nov 2025, at 14:51, Paul Wouters <[email protected]> wrote: > > Bit 14 is the Delegation Extension (DE) flag. It indicates to a > validator that a referral MUST contain an NSEC or NSEC3 record to prove > presence or absence of types for the delegated name. > > Is it really meant that an NSEC(3) record must be returned along with > the actual present new RRtype ? > I assume this just needs to be rephrased > better. Likely what is meant is that NSEC(3) records for the range(s) of > new parental records needs to be included along with any actual records.
Just include the NSEC(3) record for the delegated name in the referral. This is already done for referrals containing unsigned delegations, as there needs to be an NSEC(3) record that proves absence of DS records. Since NSEC(3) records are NOT present in referrals containing signed delegations, there is no proof that these new delegation point records exist, and we do need the proof, hence the requirement to include NSEC(3) records. > (this might cause a huge amplification attack by malicious parents btw) Amplification attacks exist. While you don't have to be a parent to do that, you can already create a huge amplification attack as the parent, by including a large set of NS, DS, NSEC, NSEC3 and RRSIG records. Unless I misunderstood the hyperbole, of course. > Note that this also limits the use of these records to DNSSEC signed > parents. The indication is for the validator to check that NSEC(3) records are included. If the zone containing the delegation is not signed, it has been indicated by the absence of DS records in the parent of the zone containing the delegation. > I thought DELEG wanted to work also without DNSSEC in the > parent? You thought right. Roy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
