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

[Mark Andrews]

In message <D1250A19.9A81%edward.lewis at icann.org>, Edward Lewis writes:
> >
> >Why don't we just implement TSIG signed updates...
> 
> In the sense of "baby steps first" - what I'm driving towards "error
> detection", ensuring that the zone-to-be is in line with it's environment.
> Getting to "error correction" is the next level, but complicates things.

Why do we need "baby steps"?  

> >> 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.
> 
> The point was missed - the solution to this has to rely on updating tools,
> not expecting folks to modify code, write a few scripts, set up cron jobs.
>  As someone familiar with coding, I could write this up for myself, but in
> general operations staff aren't going to develop anything very detailed.

key "user" {
	algorithm "hmac-sha256";
	secret "xxxxxxxxxxxx";
};

zone example.net {
	...
	dnssec-update-parent { key user [server <server> ] };
};

or

zone example.net {
        ...
        dnssec-update-parent {
		name "user";
		password "xxxxxxxxxxxx";
		[parent <zone>];
		[server <server>];
		[port <server>];
	};
};

The server would then use the credentials to send a signed update
request with the required DS records.  It is trivial to work out
the parent zone provided normal delegations are being done.  It is
also possible to find where to send the update requests to
automatically.

> >> 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.
> 
> Okay, but, the queries are sent to IP addresses held in configurations or
> in authoritative data, not relying on what is learned at sea.  They
> certainly don't iterate.

Yes, they do iterate and have done for over 15 years now.  Just
because you havn't noticed that they do this doesn't mean that it
is not been being done.

> I could quibble and say that messages sent by AXFR clients (RFC 5936),
> which are called queries, aren't exactly the same as queries sent when
> resolving a name - they share format and software but the trust model is
> different.  And that matters here because I've held the belief that
> authoritative servers do not want to base their answers (authoritative
> answers) on information learned from outside their bailiwick.
> 
> >> 3) Authoritative servers don't know anything about the parent zone.
> >
> >Discoverable.
> 
> True, unless (as mentioned later) the master is firewalled off from the
> Internet (okay, lame argument).  Yet we don't have tools that do this.
> Why not?

nsupdate will update the parent zone automatically if the first
record of the update section is a DS record (remove or add).

6ffc3748 (Mark Andrews           2010-05-18 06:18:23 +0000 3093)                tmprdataset = ISC_LIST_HEAD(firstname->list);
64c43af4 (Mark Andrews           2010-03-09 03:46:12 +0000 3094)                if (section == DNS_SECTION_UPDATE &&
64c43af4 (Mark Andrews           2010-03-09 03:46:12 +0000 3095)                    !dns_name_equal(firstname, dns_rootname) &&
6ffc3748 (Mark Andrews           2010-05-18 06:18:23 +0000 3096)                    tmprdataset->type == dns_rdatatype_ds) {
64c43af4 (Mark Andrews           2010-03-09 03:46:12 +0000 3097)                    unsigned int labels = dns_name_countlabels(name);
64c43af4 (Mark Andrews           2010-03-09 03:46:12 +0000 3098)                    dns_name_getlabelsequence(name, 1, labels - 1, name);
64c43af4 (Mark Andrews           2010-03-09 03:46:12 +0000 3099)                }

It could be made more robust by looping over all the update section
looking for DS records but it works for the usual case.

For NS it needs to be a explict decision as they exist at both the parent
and the child.  I have a feature request to add a "at parent" directive
to nsupdate to handle this.

The following will send a signed update to the parent zone.

% nsupdate
key name secret
update del zone ds
update add zone ttl ds ...
send
quit
%

> >> 4) The owners of the zone and the operator of the DNS are not always the
> >> same entity (person, company).
> >
> >Doesn't matter.
> 
> (I don't know what you mean by "doesn't matter" other than you are
> disagreeing.)

It doesn't matter.  All that matters is that credentials to do the
update are with the party that needs to initiate the update.

> I raised this impediment to try to point the solution into tools (and
> standards) and not relying on processes.  The world we live in has managed
> to build business relationships that do not align with the needed
> communications to make things work smoothly.  (This is why I called DNSSEC
> "clumsy" at a Centr meeting in October 2013 - clumsy as in, it can be made
> to work but needs more expertise than is evidently available in the labor
> market.  Evident by the frequency of defects.)
> 
> >I've already submitted a draft that would make this all possible.
> >
> >Sending signed UPDATE messages is relatively trivial.
> 
> Which one?  Is there an implementation of this?  Any operational
> experience?
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org