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

Edward Lewis edward.lewis at icann.org
Wed Mar 11 01:19:36 UTC 2015

On 3/10/15, 16:45, "Mark Andrews" <marka at isc.org> wrote:
>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.

>> Here are some impediments:
>> 1) The entity responsible for the set up is not likely to be a
>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.

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

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.

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?

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

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
-------------- 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/20150311/f7a345ef/attachment.bin>

More information about the dns-operations mailing list