Subject: [DNSOP] CSYNC. Or CDS. Or something completely different.

From: Matthijs Mekking <[email-masked]>
Date: Wed, 06 Nov 2013 11:19:18 +0100

Hi,

In yesterday's meeting, it was not clear to everyone why there are two
approaches to synchronize records between child and parent. Also, a
"new" approach by Mark was being discussed, doing the synchronization
with an UPDATE message.

First of all, Mark's approach is not new, this has already been
discussed in 2010 [1] [2]. At that time, people thought this would not
fit in the traditional RRR model, but I feel that consensus has shifted
now, probably because the use cases became more clear (thanks Paul!) [3]
[4].

Also, back then there was more merit for a pull strategy (like CDS) than
a push strategy, mainly because of scaling concerns with the push strategy.

I am very much in favor of having CSYNC to announce what RRtypes to
synchronize and use CDS (or CDNSKEY) to announce the data for Delegation
Signer synchronization. CSYNC only is not enough for DS/DNSKEY
synchronization:

1.
CSYNC's way of doing DS/DNSKEY synchronization is complex. That is
because there are many corner cases. I like simple. CDS is simple ("copy
this"). Now that might not be a good reason for having a separate
solution for DS/DNSKEY syncing. Or maybe it is? Anyway, there's more:

2.
CSYNC cannot handle the use case where the child announces the digest
algorithm (what CSYNC can do is announce that there is a CDS (or
CDNSKEY) record that needs to be dealt with).

3.
With CDS, you can support all kinds of rollovers, like Double-DS
(pre-publish DS, swap DNSKEY if old DS RRset has expired from all
caches). How would you do Double-DS with CSYNC only?

4.
Last but not least, I really appreciate the argument that Joe Abley made
yesterday: with CDS it is very clear what the intentions of the child
zone are, providing a sort of audit-trail that can be used for example
for monitoring (sorry if I misquote you, I don't remember your exact
words, it was quite late in my time zone). This is something CSYNC also
cannot do without additional RRtypes.

I hope this helps in understanding why we have CSYNC and CDS (not one or
the other).

Best regards,
  Matthijs

[1] http://datatracker.ietf.org/doc/draft-mekking-dnsop-auto-cpsync/
[2] http://tools.ietf.org/wg/dnsop/minutes?item=minutes78.html
[3]
http://datatracker.ietf.org/doc/draft-wouters-dnsop-secure-update-use-cases/
[4] http://tools.ietf.org/wg/dnsop/minutes?item=minutes-84-dnsop.html

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Nov 2013 12:08:51 +1100

> "new" approach by Mark was being discussed, doing the synchronization

It was obvious when UPDATE was being developed.

What was hard was getting past the stupid reaction that sending a
UPDATE request to a Registry controlled devices violates the RRR
arrangments even if the change is authorised by the Registrar as
it is the Registrant communicating the the Registry.  Guess what
every time the Registrant does a DNS lookup in the Registry zone
it is talking directly with the Registry.

All the scraping etc. is a reaction to that.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Wed, 6 Nov 2013 17:15:46 -0800

On 2013-11-06, at 17:08, Mark Andrews <[email-masked]> wrote:

> Guess what

You're conflating registry services with DNS services. This is a common mistake.

Joe

---

From: Edward Lewis <[email-masked]>
Date: Thu, 7 Nov 2013 08:32:49 -0500

> You're conflating registry services with DNS services. This is a common mistake.

And registrant with DNS service provider ... the world's a bit more complicated than RRR or not.

I'm confused by Mark's sentence beyond that comment.  A registrant per se has no reason to do a DNS lookup so I don't get why "Registrant does a DNS lookup" is meaningful. The registrant's relying parties that do lookups.  Using different terminology - customers of enterprises do the lookups, not the enterprises.  Where the enterprise (registrant) has employed a DNS service provider and separately a registrar, the enterprise may be completely hands-off the DNS.  And then there's the place the name is registered...

One gap in such a scenario is bridging between the DNS service operator and the domain name registrar.  Today there is absolutely no standard protocol (I mean "rules of engagement" not "XML/JSON-based language") there.

...I'm mindful of the wide range of use cases.  I'm just focusing on one here that is still not addressed in any of the proposals I've seen to date.

(FWIW, this is a necessary piece of work but I'm doubtful the answer lies within the port 53 protocol.)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Why is it that people who fear government monitoring of social media are
surprised to learn that I avoid contributing to social media?

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 7 Nov 2013 06:54:20 -0800

On 11/7/13 5:32 AM, Edward Lewis wrote:
>
> I'm confused by Mark's sentence beyond that comment.  A registrant per 
> se has no reason to do a DNS lookup so I don't get why "Registrant 
> does a DNS lookup" is meaningful. The registrant's relying parties 
> that do lookups.  Using different terminology - customers of 
> enterprises do the lookups, not the enterprises.  Where the enterprise 
> (registrant) has employed a DNS service provider and separately a 
> registrar, the enterprise may be completely hands-off the DNS.  And 
> then there's the place the name is registered...
>
> One gap in such a scenario is bridging between the DNS service 
> operator and the domain name registrar.  Today there is absolutely no 
> standard protocol (I mean "rules of engagement" not "XML/JSON-based 
> language") there.
>
> ...I'm mindful of the wide range of use cases.  I'm just focusing on 
> one here that is still not addressed in any of the proposals I've seen 
> to date.

I believe that all these examples went out of their way to specifically 
not address the DNS Service operator <-> domain name registrar bridge, 
lest they be accused of trying to enforce a process upon those folks, 
which would not take kindly to such things.
> lies within the port 53 protocol.)

This may be the bigger discussion, and it may be the ultimate answer.  
But (my opinion) is that we should do our due diligence.

tim

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Nov 2013 07:00:39 +1100

> which would not take kindly to such things.

No my example covered service operator or anyone other M2M update
which is what we are trying to achieve.

The service operator has one or more TSIG which authenticates the
updates he/she is permitted to make.

Today with nameservers you can say this TSIG can update this
<name,type> tuple and a second TSIG can update everything at <name>
and a third TSIG can update the same name and a list other types a
fourth TSIG can update name and all subdomains.  Now when updating
a parent zone you don't necessarially need all that flexability but
you do need some of it.

The Registrant establishes the update policy though the web interface
and configures the software that will be doing the updates with the
appropriate keys.  This may be done directly or indirectly through
the use of a agent.

All that is required to do this is for the nameserver (or other
piece of software with the ability to update the registry and hence
the zone) performing the update have access to the private key and
a description/table of what that key is permitted to do.

Mark