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

[Mark Andrews]

In message <D124B0CE.9A2E%edward.lewis at icann.org>, Edward Lewis writes:
> Content-transfer-encoding: 7bit
> 
> ...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.

Why don't we just implement TSIG signed updates to the parent and
send a UPDATE message to the parent?  What is so hard about a
username/password pair which is all that TSIG is.
 
> Here are some impediments:
> 
> 1) The entity responsible for the set up is not likely to be a programmer.

Doesn't matter. People do username/password pairs all the time.

> 2) Authoritative servers don't launch queries.

Has NEVER been true.  SOA/IXFR queries are done regularly by
authoritative servers.  For over the last decade queries for
nameserver addresses have been done for NOTIFY.

> 3) Authoritative servers don't know anything about the parent zone.

Discoverable.

> 4) The owners of the zone and the operator of the DNS are not always the
> same entity (person, company).

Doesn't matter.

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

I've already submitted a draft that would make this all possible.

Sending signed UPDATE messages is relatively trivial.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org