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

From: Wes Hardaker <[email-masked]>
Date: Tue, 13 May 2014 13:25:05 -0700

Paul Hoffman <[email-masked]> writes:

>> 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.
>
> That is a good summary; maybe it should be added to the end of Section
> 1.

Ed/Paul,

Sorry for the delay in getting back to you.  A number of non-work
emergencies came up I had to deal with first.

Anyway, I think maybe the right thing to do is add text saying that
the parental agent may wish to offer another configuration entry to
specify which master agent to poll when checking.  IE, rather than
pulling a random NS, actually allow for a directed master that isn't
anycast or is potentially even a hidden master.  This would take care of
much of this concern, no?  And this is already in the text:

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

And I'll add the following paragraph below this as well:

  Parental agents MAY offer a programmatic interface to let children
  indicate that new CSYNC records and data are available for polling.

The problem, of course, is that the whole reason for this solution
instead of an update push is that the whole "who do you talk" to problem
comes about.  So, your notion of "the parental agent gets notified
reliably" is super-difficult to implement in today's deployed world.  I
agree, that CSYNC isn't ideal, but it's the best choice we have in
today's environment.
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 13 May 2014 14:26:24 -0700

Edward Lewis <[email-masked]> writes:

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

I think your out-of-bailiwick use cases are certainly problematic, and
not designed to be covered by this document.  IE, there is no way to
indicate whether to pull glue from siblings or not within a particular
zone, nor should there be.  All you can say to pull is the NS record,
which the CSYNC record provides.  Clearly siblings are out of bailiwick
and I don't think there is much to do or say here.

The harder case you pointed out is when it is a child of the child
(or maybe more clearly: grandchild of the parent) that holds the address
records for the NS record.  Clearly this gives the impression that the
child has some control over the address and when it's safe to pull vs
when its not.  The CSYNC record can't really convey there is a zone
break in this case, nor do I want the parent to attempt to determine in
multiple-sub-levels that a zone break exists.  So how about this as a
new sub-section of the operational considerations section:

   4.3.  Out-of-balliwick NS Records

      When a zone contains NS records where the domain-name pointed at does
      not fall within the zone itself, there is no way for the parent to
      safely update the associated glue records.  Thus, the child DNS
      operator MAY indicate that the NS records should be synchronized, and
      may set any glue record flags (A, AAAA) as well, but the parent will
      only update those glue records which are below the child's delegation
      point.

      Children deploying NS records pointing to domain-names within their
      own children (the "grandchildren") SHOULD ensure the grandchildren's
      associated glue records are properly set before publishing the CSYNC
      record.  I.E., it is imperative that proper communication of
      synchronization efforts exist between the child and the grandchild.

[more later on the other subjects; I'm not ignoring them; just splitting them]
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 13 May 2014 16:01:04 -0700

Edward Lewis <[email-masked]> writes:

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

The whole reason for that was to appease some of the people that wanted
to provide a system where the transfer was automatic (reducing
copy/paste errors), but wouldn't be done until a user pushed a button.
IE, setting immediate=0 allows the operator to signal "copy the data but
wait till I'm around to push the button", where "button" is out of
scope.  Personally, I agree, I think having it always be immediate would
be simpler and better.  But there was clear consensus in the WG to
support both options.

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

We cover DNSSEC errors, but not general errors, you're right.  Changed:

OLD:

 	If DNSSEC fails to validate all of the data returned for
 	these queries as "secure", then this CSYNC record MUST NOT be
 	processed.

NEW:

	If a failure occurs of any kind while trying to obtain any
	of the required data, or if DNSSEC fails to validate all of
	the data returned for these queries as "secure", then this
	CSYNC record MUST NOT be processed.

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

Whomever was most annoyed at it not working?  Who debugs problems with
nameservers today?  Both!
-- 
Wes Hardaker
Parsons