Subject: [Int-dir] Request for quick review of a DISCUSS

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Apr 2014 16:01:23 -0400

On the topic of things ADs do, one of them is to try to notice issues in specs from other areas that relate to their area and come up with answers.   There's currently a DISCUSS on a CDNI document that could use more DNS fu than I happen to have—I think I see a problem with it, but I do not know how much effort ought to be expended addressing the problem.

The DISCUSS can be found here:

http://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ballot/

It's the one I put on the document.   If anybody is interested in digging a little deeper, please let the coordinator know, and I can pass along more of the discussion that's happened so far.

Thanks!

---

From: 神明達哉 <[email-masked]>
Date: Thu, 10 Apr 2014 15:24:05 -0700

At Thu, 10 Apr 2014 16:01:23 -0400,

> It's the one I put on the document.   If anybody is interested in digging a little deeper, please let the coordinator know, and I can pass along more of the discussion that's happened so far.

So you're asking about this one, right?

>> In 3.4:
>>        The Request Router returns a DNS CNAME response by "stacking" the
>>        distinguished identifier for Operator B onto the original CDN-
>>        Domain (e.g., b.cdn.csp.example), plus an NS record that maps
>>        b.cdn.csp.example to B's Request Router.
>>
>>    2.  The end-user does a DNS lookup using the modified CDN-Domain
>>        (i.e., b.cdn.csp.example).  This causes B's Request Router to
>>        respond with a suitable delivery node.
>>
>> What's up with the NS record here?   Are you relying on glue to make sure that
>> the query goes to the right nameserver?

Adding the NS record in this case doesn't make much sense, at least in
practice, to me either.  But perhaps the intent is a possible
optimization: since the CNAME target (b.cdn.csp.example) is a
subdomain of the "current" qname (cdn.csp.example), a recursive server
would have to send the renamed query (from cdn.csp.example to
b.cdn.csp.example) to the same (set of) name server, just to get the
delegation anyway, so there might be a recursive server implementation
that just skips this additional query and immediately follows the
delegation.

But I don't know of such a recursive server implementation.  At least
neither BIND 9 nor unbound seems to skip the "redundant" query in this
case.

And this NS (with CNAME) shouldn't be "necessary".  Any reasonable
recursive server implementation should resend the query for
b.cdn.csp.example, get the delegation, and then follow it.

So, asking the authors for the intent would be good, and whatever it
is, it would be helpful to point out that it's either unnecessary or
doesn't work as intended.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 10 Apr 2014 15:32:47 -0700

I forgot to say this...

>>        b.cdn.csp.example to B's Request Router.

depending on the authoritative server implementation, you can see this
NS record anyway.  For example, BIND 9 would include NS for
b.cdn.csp.example in the authority section.  So perhaps the author
just tries to describe the behavior of some specific implementation.
But, as explained in my previous response, it's quite likely to be
useless for the resolver in practice, and wouldn't have to be
mentioned here.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Apr 2014 18:35:54 -0400

The authors in fact intended to include the NS record as glue and intended that it determine which name server was queried to resolve the name specified in the CNAME response.   I don't want to send the whole conversation to the int-dir mailing list, but if you would like I will send it to you.   The same goes for anybody else who is interested in looking at it.

---

From: 神明達哉 <[email-masked]>
Date: Thu, 10 Apr 2014 17:12:28 -0700

At Thu, 10 Apr 2014 18:35:54 -0400,
Ted Lemon <[email-masked]> wrote:

> The authors in fact intended to include the NS record as glue and
> intended that it determine which name server was queried to resolve
> the name specified in the CNAME response.   I don't want to send the
> whole conversation to the int-dir mailing list, but if you would
> like I will send it to you.   The same goes for anybody else who is
> interested in looking at it.

>From a quick read of the followup discussion (sent to me off-list),
the authors seem to assume the "glue" NS sent with the CNAME is used
by the resolver.  As I explained in my first message, that's simply
not the case, at least for two popular resolver implementations.  The
resolver will send the revised query (for the CNAME target) to the
best available server for the resolver.  It may be the uCDN, or if the
resolver cached something before, that server.  But it's not the
"glue" NS returned with the CNAME.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Apr 2014 20:25:35 -0400

Thanks, that's very helpful.   Do you have any thoughts about the DNSSEC question?  :)

I guess if the glue records aren't going to be used anyway, the question of whether they validate is immaterial.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 11 Apr 2014 09:55:27 -0700

At Thu, 10 Apr 2014 20:25:35 -0400,

> Thanks, that's very helpful.   Do you have any thoughts about the DNSSEC question?  :)

Regarding DNSSEC, the concern is how to sign this CNAME at the
"request router at Operator A"?

cdn.csp.example. CNAME b.cdn.csp.example.

That could be expensive but shouldn't be impossible in principle, as
you said in your message to the authors.

And, perhaps it can be even less expensive, depending on the
operational assumptions.  I've only read Section 3.4 of the draft, but
according to that it doesn't seem to be very dynamic.  That is, the
uCDN knows all possible dCDNs and how to generate the unique
identifier (such as "b" in this example) for each dCDN, and changes to
the set of dCDNS are relatively rare events.  If so, I can imagine
making the signing quite static: the uCDN could compute valid
signatures for all possible CNAMEs beforehand, and just return the
appropriate CNAME + its RRSIG(s) depending on the client information.
Technically, however, you should also increment the SOA serial every
time you change the returned CNAME and therefore re-sign it, so if you
don't do that it's still cheating.

In any case, these are not a DNSSEC implication because of the "glue"
NS record.  It's more about supporting DNSSEC for a zone
(conceptually) changing so rapidly, essentially at the query rate.

If the concern is how to make the delegation from cdn.csp.example. to
b.cdn.csp.example secure in terms of DNSSEC, i.e., adding a valid DS
and its signature, it's relevant to the glue NS record in some sense.
Depending on the operational assumption, this might actually be an
easier problem: if the delegation relationship itself is stable (i.e.,
the dDNS zone keeps either signed or unsigned, and if signed its KSK
doesn't change so often), the uDNS could simply include the DS (or not
include it if the child zone is unsigned) and sign it.  It doesn't
become invalid even if the CNAME changes, so it wouldn't be that
different from usual parent-child issues in terms of DNSSEC.

--
jinmei