[dns-operations] What would it take...

[Edward Lewis]

...to prevent another DS<-->DNSKEY mishap from happening again?

I'm presenting the message to the DNS Operations list of DNS-OARC.  (Being
subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF
participant or talking as a past operator of DNS or as ....)

In short, think about when a name server loads a zone with a DNSKEY set in
it.  If, at the parent zone, there is a DS set and none of it's contents
refer to a record in the DNSKEY set, all DNSSEC validating queries will
declare everything in the zone broken.

So, why can't the name server find the DS set, run a check and barf if
there's a problem?  Barf - either refusing to load the zone or refusing to
change the zone that is already running.

Here are some impediments:

1) The entity responsible for the set up is not likely to be a programmer.
2) Authoritative servers don't launch queries.
3) Authoritative servers don't know anything about the parent zone.
4) The owners of the zone and the operator of the DNS are not always the
same entity (person, company).

#1 - The implications of this is - tools/components are needed.  One option
are management/diagnostic tools.  Another option is an embedded in the name
server component.  More tools is great when you are the jockey, more
embedded components is great when you are the customer.

#2 - Software can do what it wants - but sometimes hidden masters are
shielded with the public Internet.  (I'll assume the case is that the parent
and child zones are on separate sets of machines - when this is't true, we
don't have the problem.)  I bet though, that it wouldn't be hard to convince
the operators of hidden masters to allow them access port 53 outside the
firewall.

#3 - There's a brute force way to overcome this, come down the root to find
the cut point.  Or this can be configured somehow (but I hate pinning).  Or
maybe just doing a straight forward use of a validating recursive server
(but that's more tools, see #1).

#4 - This is a critical aspect of the problem.  Even if the customer tells
the DNS hosting company to roll keys, the customer has to be the one who
finds the registrar to ensure the DS set is correct in the registry.  That's
four participants with the most important (customer) the least capable (or
they probably wouldn't be a customer).  Failing to automate away the
customer's problem will kill the effort, certainly stall scaling.

The first step is for the operations community to cobble together a solution
to this problem.  Perhaps a proposal goes to the IETF for the proper review
and legal protection.  And if there's a need to change other policies, an
IETF document might be the greatest asset.

This is one way to make DNSSEC less clumsy.

Please - if there are more impediments, suggest them.  I may have missed
something.  If you disagree with an impediment, speak out.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150310/dc41f48b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150310/dc41f48b/attachment.bin>