Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-child-syncronization

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Apr 2014 12:12:05 -0400

Not that this matters, but this is the first look I have had at this document.

I’ll start with a heavy dose of skepticism as this is intended for the standards track.

This is “impossible to implement”:

2.3.2.  Child Nameserver Selection

   Parental agents will need to poll child nameservers in search of
   CSYNC records and related data records.
One word - any cast.  (Okay, the spell checker says it is two words.)  A casual observer can estimate the rest of the elided comment.

But, truth be told, “polling” as described here is not necessary for this proposal.

I do have a more serious concern about where the parental agent gets it’s information.  I accept that a properly DNSSEC-signed CSYNC record is sufficient to indicate a child has a configuration that it wants to see replicated in the parent.  Tying this to serial numbers makes the CSYNC independent of the copy-on-the-server, meaning, this depends on the data space and not the server space.

Getting the NS set has one challenge, making sure the NS set comes from the same serial number version as the CSYNC.  When I issue “zone/IN/NS” I don’t see the serial number though.  I’d have to use the ANY query type to capture the SOA and NS set resident in the answering server (and hopefully we’ll assume an authoritative server).  Given: 
   Parental agents MAY offer a configuration interface to allow child
   operators to specify which nameserver should be considered the master
   to send data queries too.  This master may not be one of the
   publically listed nameservers in the NS set (i.e., it may be a
   "hidden master").
this issue is not a show stopper, but the “protocol implication” of not getting the SOA and NS in the same response is probably a significant note to add.

My concern with the glue records is more substantial.  There are two use cases to consider.

One case is where the addresses of the NS names are owned in a different (perhaps sub) zone.  The other case is where the addresses are in zone that is “above” the child but still under the parent - think multi-label deep parents.

In the first case, once I can get the CSYNC and SOA and NS to be “in sync” as far as what the child is declaring, it’s not as easy to guarantee the set of zones owning the address records agree.  And I say “set of zones” because, well, you can imagine.  What if…the zones in question here are not under the management of the child, pertinent here not as “control” but “not monitored” and they fall out of date or experience some other failure.  Or are not signed the same way the child is?

In the second case, to make this a bit clearer, the child zone is "store.franchise.example." delegated from the parent zone “example.”.  The NS set has names that are in corporate.example. which is also delegated from example (one-label deep).  The child zone could not know that the glue is needed because the names are out of bailiwick, but to the parent zone, they are.  This is, yes, a trick question.  The child administrator would need to know that address records are needed in the type bit map field even though they are “over there” tree-wise.

I do commend this observation (which is one of the problems I have with the CDS/CDNSKEY proposal):
2.3.1.  Error Reporting

   There is no inline mechanism for a parental agent to report errors to
   operators of child zones.  Thus, the only error reporting mechanisms
   must be out of band, such as through a web console or over email.

But I am dubious on the flag for “immediate.”  In my experience, I’ve never seen queue-jumping to every pay off unless the underlying system is over subscribed as it is.  If this system is oversubscribed,   there are bigger problems.  Normally I’d let this lie, but it reminds me of the key strength field in the KEY RR - a spectacular dud of a concept.   (KEY RR was the DNSSEC key holder before DNSKEY RR.)

These are my comments assuming that the proposal works as advertised.  I have my doubts regarding the use of the DNS to “pass messages” for a few reasons.  Out-boxes aren’t always cleared out (meaning old requests hang around).  In-boxes may not be checked regularly.  And the lack of a reverse channel is a pretty major obstacle - as the draft says, out of band communication is needed.  (This reminds me of a joke - you can talk to a diety, but if they talk back, check yourself into a hospital.)

PS - What if the parental agent tries to retrieve the AAAA records and gets no response - persistently?  I don’t mean “No Answer” I mean nothing back?  I’m picking on this (as opposed to A) as a somewhat more realistic operational happenstance.  Who would initiate the debugging of this, the parental agent who detects the failure but is mum, or the child whose patience is being tested?

On Apr 2, 2014, at 15:14, Tim Wicinski <[email-masked]> wrote:

> 
> All,
> 
> This is the beginning of the Working Group Last Call on Child To Parent Synchronization in DNS.
> The London update showed that this work is complete and ready to move forward.
> 
> The document can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-child-syncronization/
> http://www.ietf.org/id/draft-ietf-dnsop-child-syncronization-00.txt
> 
> Please take a moment to review the final versions and send up any comments.
> 
> This document willhave a 2 week period for comments, closing on April 16th, 2014.
> 
> thanks
> tim
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 6 Apr 2014 17:52:16 -0700

This document seems clear and reasonable. The author has done a good job of clearing up issues from earlier drafts.

FWIW, I disagree strongly with Ed Lewis' skepticism. See below.

> One word - any cast.  (Okay, the spell checker says it is two words.)  A casual observer can estimate the rest of the elided comment.

That does not make the document "impossible to implement", it makes it unreliable when the child's nameserver is anycast. That's why the document says not to do that in Section 2.2.1

> this issue is not a show stopper, but the “protocol implication” of not getting the SOA and NS in the same response is probably a significant note to add.

Again: isn't your concern covered by the four steps in Section 2.2.1?

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Sun, 6 Apr 2014 21:56:21 -0400

> That does not make the document "impossible to implement", it makes it unreliable when the child's nameserver is anycast. That's why the document says not to do that in Section 2.2.1

My comment wasn’t that the “document was impossible to implement” but that with the advent of any cast one can never query all of the name servers (from one location).

> Again: isn't your concern covered by the four steps in Section 2.2.1?

As far as the SOA and NS, that is a good approximation, but it doesn’t cover the A and AAAA records that could be elsewhere.

It is not that this stuff can’t work.  It’s that ideas like this (adding to the DNS protocol’s management toolset) are only ever approximations that run the risk of adding complications when things don’t go well.  The alternative is another protocol for this, and I expect a blank stare in return to the comment.  So in the mean time, I just want to call out the rough edges of these proposals.

The document does do a good job of handling as many as it can, but there’s still the underlying limitations of one-way-only message passing.   The only way this will work (in the sense of scale and stability over time) is if the parental agent gets notified reliably to check and the child’s (agent?) stays on the ball until the action is completed.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 6 Apr 2014 19:01:12 -0700

> It is not that this stuff can’t work.  It’s that ideas like this (adding to the DNS protocol’s management toolset) are only ever approximations that run the risk of adding complications when things…

Calling out rough edges is fine; those should be admitted in the documents in question. My review of draft-ietf-dnsop-child-syncronization says that the rough edges are called out; if you have particular places in the document that you think should have bigger warnings, point them out.

> The document does do a good job of handling as many as it can, but there’s still the underlying limitations of one-way-only message passing.   The only way this will work (in the sense of scale and…

That is a good summary; maybe it should be added to the end of Section 1.

--Paul Hoffman