Subject: Re: [dnsext] Re: We need a better problem statement

From: Doug Barton <[email-masked]>
Date: Sat, 19 Dec 2009 20:09:29 -0800

Andrew Draper wrote:
> Hi,
> 
> I'm sending this off list but please feel free to post your response to
> the list if you think that's useful.
> 
> I'm not against your proposal, but I think you've done a poor job in
> describing it and so it may not get the reception it deserves.
> 
> I read your previous posts, I've also read this response several times
> and think I understand the proposal a bit better.  Let me try and
> rephrase it to see whether I'm right...

Thank you for taking the time to do this. I am choosing to reply to
the list, so I've left the vast majority of your message intact.

> Lets say the zones are set up as you suggest, and that the resolver is
> asking for www.variant1.tld
> 
> - The CLONE RR must not occur at the same location as any other RR

At the same location, for the same label. Full stop.

> - For new resolvers the authoritative server which holds the CLONE RR
> (in the parent if the zone being cloned is at a zone cut) will send a
> response which contains the CLONE RR itself and will then follow the
> CLONE RR in a similar way to following DNAME.  It can provide all the
> DNSSEC information needed to validate the response.  The difference
> between this and following DNAME is that CLONE also redirects the name
> being cloned.

That's not exactly what I had in mind.

First, I'm assuming some sort of signaling mechanism (TBD) for the
resolver to indicate that it understands CLONE if it receives one. I
am _guessing_ (and here I freely confess that my protocol fu is weak)
that we can use the same mechanism as is used for "recursion desired."

But assuming that the authoritative server knows that the resolver can
understand CLONE, an example:

The resolver queries for the A record for www.variant1.tld. In the
authoritative server "variant1.tld" is set up as a CLONE of
"domain.tld." The relevant output of a dig command would look like this:

;; QUESTION SECTION:
;www.variant1.tld.		IN	A

;; ANSWER SECTION:
variant1.tld.		1800	IN	CLONE	domain.tld.

;; ADDITIONAL SECTION:
www.domain.tld.		1800	IN	A	1.2.3.4

Now I'm not overly concerned about which stuff goes in which sections,
and DNSSEC complicates this of course, but hopefully you get the idea.

The resolver can then return the answer "1.2.3.4" to the end user just
as if the "real" domain was variant1.tld.

What the resolver should do for subsequent queries in variant1.tld is
open to discussion. I would argue that for the TTL of the CLONE record
it should simply query for ${label}.domain.tld and handle the
conversion internally, but I would not object to someone proposing a
good reason that all queries should go out from the resolver as they
came in.

> [I think you may have described using rewriting in this case, but that
> seems more complex than just sending the raw data to the resolver. 

The rewriting I am proposing in the authoritative server is only for
resolvers that are not CLONE-aware.

> - For old resolvers the parent authoritative server will rewrite the
> query using the CLONE RR, answer it (returning a delegation to ns1.label
> etc) and then rewrite the response back using the reverse of the CLONE
> RR so that the response looks as if the zone file held the records:
>     variant1 NS ns1.label
>              NS ns2.label

I'm sorry, I didn't quite follow that. What I'm suggesting for queries
from non-CLONE resolvers is that the authoritative server return the
answers AS IF the question had actually been for a label in
domain.tld. I think there should also be some sort of "signal" (I'm
purposely not using the term "flag" here, although that would work if
it's protocol'ifically appropriate) that the response is actually
CLONE'ed, but to the resolver (and thus to the end user) everything
will look like variant1.tld is the real domain.

So in the case of the parent authoritative server as you described
above, the answer is yes, it would return a referral for variant1.tld
that contained the answer as if the query had been for a label in
domain.tld.

> - The old resolver will next ask the child authoritative server for
> www.variant.tld.  If the child has been set up with variant.tld as a
> different view onto label.tld then this works fine.  If the child has a
> zone file for variant.tld containing the same CLONE RR as was in the
> parent then the clone rewriting happens here too, giving the same
> behaviour.

Yes! Two small adjustments, I think that there probably should be a
definition of how the CLONE RR should work at the child but I'm not
suggesting that we mandate the mechanism of how the child
authoritative name server should accomplish the configuration part of
it. The other thing that you mentioned here that I forgot to mention
is that in the event that the child authoritative server is not
CLONE-irific (but the parent is) they can still use the "point
different zones at the same zone file trick."

> - For resolvers that understand DNSSEC but not CLONE the response will
> not validate.  As you say, there is no hope for such resolvers if we add
> new redirection types.

Right again!

> Have I got this right?

You got almost all of it right, and your response helped me think
through how to better explain the areas that did not match what I had
in mind, so thank you again.

Of course I'm not ruling out the possibility that what I have in mind
is not actually a good idea. :)

> If so then the cleverness is in reducing the amount of synthesis needed
> in the authoritative server for old clients - it only needs to
> synthesise one record which could be precomputed if necessary. 

I think that's right. I think that "the cleverness" would also be in
the fact that 95% of the solution is in the hands of the parent
authoritative servers, and (modulo DNSSEC) is fully compatible with
older resolvers.

> It could
> be precomputed and signed if the tools supported it, which would make
> the DNSSEC && !CLONE clients work too.

This part I'm not sure matches what I have in mind. The CLONE record
would be signed of course, but that's not going to help non-CLONE
resolvers. CLONE resolvers would use the DNSSEC information in
domain.tld to validate the answers.

> The cost is that the child zone needs to publish multiple copies of the
> same zone so it can support old clients, but that is partially
> automated.

Well, if the configuration happens in the config file only, you're not
even dealing with multiple copies of the zone, just an internal
"sleight of hand." If the software implementation requires a zone file
my idea is that the zone file have just one record, although
implementors would probably prefer that it have at least an SOA in
addition to the CLONE RR.

Doug

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/