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

[Mark Elkins]

On 15/04/2017 17:24, Joe Abley wrote:
> Hi Mark!
>
> On 15 Apr 2017, at 11:11, Mark Elkins <mje at posix.co.za> 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.

Opps, we do this for the ZA ccTLD - so I guess I should know better.
Then again, its a ccTLD. I don't think even many ccTLD's do this?

I personally don't do this for AFRINIC reverse DNS zones though. I don't
think many people do DNSSEC on reverse zones, I'm one of the few. One
solution could be to have a opt-out flag, or simply not do the "delete" bit.
Perhaps then just a warning indication whenever one visits the Reverse
Delegation  part of the my.afrinic.net website would be enough.


> 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".

Hmm..Reminds me that  I have asked previously if we could have some sort
of (non-mail) automated, secure way of doing DNSSEC updates at AFRINIC,
either EPP or something, but that's another topic.

> 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.

I agree.

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za