Subject: [DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

From: Brian Dickson <[email-masked]>
Date: Fri, 31 Oct 2014 17:17:57 -0700

I think it is good to minimize disruption caused by broken DNSSEC domains,
for all the reasons listed in the document.

However, I also believe there is a second-order negative effect of
implementing NTAs as described.

Validating stub resolvers and validating forwarding resolvers, will still
break.

I do have a suggestion, which I hope is worth exploring and considering.

For anyone using an open, well-known resolver (either provided by their
ISP, or operated as a "public service"), include instructions on use of a
provider-specific DLV and provider-specific "alternative trust anchor
(DNSKEY)".

Whenever it is necessary to over-ride broken DNSSEC zones, most likely on
the Secure Entry Point, do the following:
(1) Add a KSK to the apex DNSKEY RRset. For convenience use the same KSK
for all such instances, and publish the public DNSKEY used.
(2) Sign the apex DNSKEY RRset with this new KSK
(3) Add this KSK into the DLV operated by the resolver operator at the
appropriate location. For example, if example.com is broken, put the KSK at
example.com.dlv.example.net, if the operator of the public resolver is
example.net.
(4) Observe successful validation of example.com by anyone configured to
use dlv.example.net as their DLV.

I haven't tried this, and there might be some specific modifications to
what I described needed to make the configuration correct/functional. I
don't believe it introduces new insecurities to anyone who already has
placed trust in the resolver at example.net.
(Is it the case that things that use DLV validate the chain of trust to the
DLV itself, from the root, if there is not a separate trust anchor for the
DLV zone? That would be optimal, security-wise, I believe.)

Thoughts?

Brian Dickson