Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] New Proposal: Lame delegations in AFRINIC reverse DNS

Joe Abley jabley at
Sat Apr 15 15:24:10 UTC 2017

Hi Mark!

On 15 Apr 2017, at 11:11, Mark Elkins <mje at> wrote:

> It could even be extended to check for "lame" DNSSEC material (DS
> Records that no longer associate with any "DNSKEY" records in the
> delegated zone) and check and report on that if it goes "bad", even
> deleting bad DS records?

There's a valid use-case that would fall foul of that particular idea -- that of publishing a DS RRSet in the parent that refers to (in part) one or more standby DNSKEYs that are not yet published, but would be published if there was some kind of emergency. Such standby keys could be used as part of a disaster recovery plan.

By publishing DS records for both keys (the active and the standby) validation will proceed regardless of which KSK is actually being used to serve the child zone.

Pulling DS records from the parent for the non-active KSK would break validation for end-users in the event that a disaster recovery plan had to be exercised.

I think this kind of thing is probably more interesting to managers of zones whose parent is complicated to deal with (e.g. TLD zones) but it's still useful in the case of automated fail-over where you really don't want a manual step "click here when you've changed the DS records at the registry and waited double whatever TTL they are using to make sure the changes are noticed by validators".

For the lame delegation policy, I completely agree, I think it's at worst benign and at best useful. Other RIRs have significant experience with this (I seem to remember Ed Lewis implementing a similar policy at ARIN around 2002); there might be opportunities for some code reuse that could make implementation at AfriNIC even easier.


More information about the RPD mailing list