Subject: [dnsext] New Version Notification for draft-barton-clone-dns-labels-fun-profit-00

From: Doug Barton <[email-masked]>
Date: Mon, 07 Mar 2011 05:56:25 -0800

As promised I've managed to squeak this draft in under the wire. As I
say in the Foreword I expect that it will need some polishing, and if
the group chooses to adopt the document I look forward to getting lots
of help with that. :)

Doug

http://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit-00

- -------- Original Message --------
Subject: New Version Notification for
draft-barton-clone-dns-labels-fun-profit-00
Date: Mon,  7 Mar 2011 05:47:21 -0800 (PST)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]

A new version of I-D, draft-barton-clone-dns-labels-fun-profit-00.txt
has been successfully submitted by Douglas Barton and posted to the IETF
repository.

Filename:	 draft-barton-clone-dns-labels-fun-profit
Revision:	 00
Title:		 Cloning Domain Name System (DNS) Labels for Fun and Profit
Creation_date:	 2011-03-07
WG ID:		 Independent Submission
Number_of_pages: 11

Abstract:
This document describes a method for making one or more Domain Name
System (DNS) labels behave in the DNS "as if" they were actually an
entirely different label.  E.g., the delegee for the example.org zone
could define bar.example.org to be a CLONE of foo.example.org.  This
method is designed to meet the needs of those managing
Internationalized Domain Name (IDN) zones that have been determined
to be semantically similar, and therefore should be treated "as if"
they were identical.  This method can also be used more generally to
handle situations where currently either CNAME or DNAME Resource
Records are being used.

A key design goal for the CLONE method is that except for DNSSEC
support all of the semantic benefits are available by updating the
authoritative servers for the zone.  Therefore unless DNSSEC support
for the CLONEd zones is required there is no dependency on end users
being behind a CLONE-Aware resolving name server.

Foreword

[RFC Editor, please remove this Section at publication time.
Thanks.]

This is my first draft, please be gentle. :) I'm definitely open to
the possibility that there are better ways to accomplish the concepts
presented herein.  I'm sure that there are a non-zero number of
errors in the formatting, references, etc.  Also Sections 2 and 3 may
be under-specified, unclear, or unworkable.  So please don't be
afraid to offer (constructive) criticism.

TODO:

Update/add/improve references?

Add/improve examples?

Revision History:
1.  -00 Initial version

The IETF Secretariat.

_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 7 Mar 2011 07:47:58 -0800

On Mar 7, 2011, at 5:56 AM, Doug Barton wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 

Interesting, but a couple of comments:

For the non-CLONE aware case (no EDNS0 option in query), I think instead of returning "as if" its an alias, INSTEAD it should be a CNAME or DNAME with TTL=0 with the part the authority is responsible for canonicalized.  (TTL=0 prevents the problems inherent for both CNAME and DNAME combined).  

That way, (using ASCII as an example)

cLIent.othErS.myTlD DNAME cLIent.othErS.mytld TTL=0
otERs.mYtLD CNAME otERs.mytld TTL=0

Why?  Because this way the systems underneath the authority in the hierarchy don't have any worry about the canonicalization: its precanonicalized for their viewpoint, which means if the main authority and clients have DIFFERENT notions of canonicalization, each level in the hierarchy does not have to concern itself about other levels in the hierarchy, just their own.

(Note, I don't know what final TTL the client will see, this is something that needs to be checked)

The more important configuration is probably the model of 

CARNS STUB  <----> Non-CARNS Resolver <---> CARNS Auth.

As it is far more likely that clients will upgrade (EG, as part of the browser or OS) rather than resolver authorities in many cases.  

I do not know if unknown EDNS0 options are likely to be passed from the stub to the authority through the intermediary resolver, which may instead require doing a parallel query for a CLONE RR (akin to how A and AAAA records are looked up in parallel by many hosts, rather than having a 'Support IPv6' EDNS0 option.)

The CLONE RR really needs to be a "canonicalization program", describing a set of character/word transformations that should be applied, NOT just a simple pointer.[1]  This enables CLONEs to be DNSSEC signed offline.  Otherwise, if you want DNSSEC EVEN FOR CLONE-aware clients, you need to...

Discuss online signing.  There is nothing which prevents the slaves from dynamically signing and caching the results, or dynamically querying a MASTER and caching the results (so no key distribution to the slave authorities).  The load is more than reasonable WITH caching (~100+ signatures/cluster node/second should be reasonable to accomplish, and such nodes should cost on the order of $.20/hr total cost amortized out over 3 years). 

More important, the caching can make it NOT 'single point of failure' in practice (and thus DOS resistant in practice as well), because although the canonicalization space is near exponential, the canonicalization in PRACTICE is probably much smaller [2], and that smaller space in practice could even be prefetched so online signatures are only needed in the exceptional cases of not-seen-before biZZArO canonicalizations being required..

[1]  I believe that if CLONE is just a simple pointer, it is unnecessary, because 0 TTL CNAMES and DNAMES can accomplish the same thing.  The value in a CLONE-type new RR and associated EDNS0 signaling lies in allowing it to work with the offline DNSSEC signature model.

[2]  How to determine the canonicalization space:  For a given language and canonicalization, take a large corpus of text (probably an email corpus would be the best, as this represents 'what people type in a computer'), and pass it through the canonicalization.  This gives you an estimate on how canonicalization needs to happen in practice, how well signature caching works, etc.  

EG, (although not needed for ASCII), its clear that for ASCII only a few canonicalizations are all that happen in practice, even if the input space possible is huge.  People type www.google.com, WWW.google.COM, www.Google.COM, etc, NOT wWw.goOGLe.COm.

---

From: John Levine <[email-masked]>
Date: 7 Mar 2011 20:37:33 -0000

>Title:		 Cloning Domain Name System (DNS) Labels for Fun and Profit

Looks promising.

In section 3, why does a CARNS have to make future queries to the
preferred version?  Is it to improve cacheing, or is there something
else about it that I'm missing?

In 1.1, "truly equal" is really an application issue.  From a user's
point of view, if a web browser changes the name in the displayed URL
to the preferred one, the names aren't equal, and if it shows what you
entered, they are, regardless of what bits the DNS might have
returned, Ditto mail programs changing domains in mail addresses and
so forth.  With that in mind, I don't see the fact that the
application can tell which name is preferred as a significant issue.

R's,
John

---

From: Doug Barton <[email-masked]>
Date: Mon, 07 Mar 2011 17:04:41 -0800

>> Title: Cloning Domain Name System (DNS) Labels for Fun and Profit

Thanks. :)

> else about it that I'm missing?

Yes, and to reduce overall traffic, decrease processing power on the
authorities, etc.

> In 1.1, "truly equal" is really an application issue.

The point I was trying to make there was that I'm attempting to provide
a DNS solution to equivalence, not enter the debate on what "equal"
means. :) If you think I need to clarify that I can add some text, but
I'm hoping that the reference to the aliasing draft will help there.

> From a user's point of view, if a web browser changes the name in the
> displayed URL to the preferred one, the names aren't equal, and if it
> shows what you entered, they are, regardless of what bits the DNS
> might have returned,

Right, I think you're getting the idea of what I'm proposing. Users 
don't care about DNS. :)

> Ditto mail programs changing domains in mail addresses and so forth.
> With that in mind, I don't see the fact that the application can tell
> which name is preferred as a significant issue.

In most cases I think you're right. The idea behind CLONES is to give 
the application the ability to determine this in case it *is* 
significant for some reason.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Doug Barton <[email-masked]>
Date: Mon, 07 Mar 2011 17:33:07 -0800

On 03/07/2011 07:47, Nicholas Weaver wrote:
>> As promised I've managed to squeak this draft in under the wire. As
>> I say in the Foreword I expect that it will need some polishing,
>> and if the group chooses to adopt the document I look forward to
>> getting lots of help with that. :)
>
> Interesting,

Thanks. :)

> but a couple of comments:
>
> For the non-CLONE aware case (no EDNS0 option in query), I think
> instead of returning "as if" its an alias, INSTEAD it should be a
> CNAME or DNAME with TTL=0 with the part the authority is responsible
> for canonicalized.

All due respect, I think you're missing the whole point. :)  Users want 
to be able to use the variant labels (including things like being on the 
RHS of NS and MX records) so the idea is to deal with them on a basis 
that is as equal as possible.

> CARNS STUB<---->  Non-CARNS Resolver<--->  CARNS Auth.

I hadn't considered the idea of making a stub CLONE-Aware, but I like 
it. :)

> As it is far more likely that clients will upgrade (EG, as part of
> the browser or OS) rather than resolver authorities in many cases.
>
> I do not know if unknown EDNS0 options are likely to be passed from
> the stub to the authority through the intermediary resolver,

I'm not sure what the default behavior is there, but if the actual 
resolver is not CLONE-Aware then sending the option wouldn't help since 
it wouldn't understand any CLONE RRs that it received back.

> The CLONE RR really needs to be a "canonicalization program",
> describing a set of character/word transformations that should be
> applied, NOT just a simple pointer.[1]

How would you represent the canonicalization?

> This enables CLONEs to be
> DNSSEC signed offline.  Otherwise, if you want DNSSEC EVEN FOR
> CLONE-aware clients, you need to...
>
>
> Discuss online signing.

I'm not sure why, but I'm happy to be educated. The idea I have in mind 
is that the zone for the preferred label can be DNSSEC signed in the 
regular way, and a CLONE-Aware resolver can validate responses for the 
CLONE labels "as if" they had been responses for the preferred labels.

Thanks again for the comments. :)

Doug

> [1]  I believe that if CLONE is just a simple pointer, it is
> unnecessary, because 0 TTL CNAMES and DNAMES can accomplish the same
> thing.  The value in a CLONE-type new RR and associated EDNS0
> signaling lies in allowing it to work with the offline DNSSEC
> signature model.

--

---

From: John Levine <[email-masked]>
Date: 8 Mar 2011 02:51:53 -0000

>I hadn't considered the idea of making a stub CLONE-Aware, but I like 

To me, much of the appeal of CLONE is that it allows me to configure
my applications to handle foo.example and all of its clones.  So at
least on the server side, CLONE-aware queries are likely to be pretty
common.

>How would you represent the canonicalization?

The rats at the bottom of that hole have extremely sharp, nasty,
Turing-complete teeth.

R's,
John

---

From: Alex Bligh <[email-masked]>
Date: Tue, 08 Mar 2011 09:24:17 +0000

--On 7 March 2011 17:33:07 -0800 Doug Barton <[email-masked]> wrote:

> I think you're missing the whole point. :)  Users want to be able to use
> the variant labels (including things like being on the RHS of NS and MX
> records) so the idea is to deal with them on a basis that is as equal as
> possible.

(I've read the draft but am thinking about it before commenting, so don't
take this as a comment on the draft).

I am not sure Nick is missing the point. We do not *know* that users want
to use the variant labels on the RHS of NS and MX records (beyond the
obvious truism that it would be nice to do everything). I am guessing that
most users want to use the variant labels in URLs and email addresses, and
that's it.

Suzanne Woolf is attempting to gather some matrix of requirements and
balance them against disruption. Until such point (that might be never),
all we've got is different proposed solutions with different functionality.
What you're saying is that CLONE (apparently) allows the RHS of an NS
record to be a variant too, which differentiates it from (e.g.) a
CNAME/DNAME combination.

Out of interest, /why/ is a variant being on the RHS of an NS or MX record
useful? This is never visible to end users, and in the majority of use
cases thus far brought up, the RHS of the NS or the MX record gets to be
one user-illegible string beginning "xn--" rather than another illegible
string beginning "xn--".

-- 
Alex Bligh

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 8 Mar 2011 10:41:05 +0000

> most users want to use the variant labels in URLs and email addresses, and

+1 on the point that we don't know. The problem statement draft is the
attempt to capture the landscape but if you've read the -00 it's
fairly clear we don't know *that* much.

> record to be a variant too, which differentiates it from (e.g.) a

The -00 of the problem statement draft has been out for a couple of
weeks and we hope to ship a -01 before the Prague cutoff. I think Alex
and Doug have both sent comments, and more are welcome but we need
anything for the -01 in the next few days.

(I don't think I'll have time to read CLONE and add a description for
the -01, but if someone wants it in there alongside the attempts to
describe shadow zones and the assorted xNAMEs, send text.)

> one user-illegible string beginning "xn--" rather than another illegible

There have been a couple of comments from apps folks on this,
particularly Patrik Faltstrom, suggesting a possible use case in which
the alias is part of a resolution chain, i.e. underlying a URI. This
argument supposes that some user-illegible strings are nonetheless
useful for applications and application-facing services.

Suzanne

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 8 Mar 2011 07:53:35 -0800

On Mar 7, 2011, at 5:33 PM, Doug Barton wrote:
> I hadn't considered the idea of making a stub CLONE-Aware, but I like it. :)

This came up in private discussion when it was clear I had a different model (resolver change) vs I can't remember who (stub change).

The result was I was convinced I was wrong:  I was convinced that Stub change is actually far more likely.  

EG, take arabic.  With a resolver change model, every resolver which has at least a few arabic clients needs to upgrade, which is effectively everyone.  But most resolvers won't substantially benefit, so why bother upgrading?

But with stub changes, ONLY those who actually benefit substantially need to change.

> I'm not sure what the default behavior is there, but if the actual resolver is not CLONE-Aware then sending the option wouldn't help since it wouldn't understand any CLONE RRs that it received back.

Hmmm, which again makes me think the model might need to be more like how AAAA records are handeled: Do a parallel fetch for CLONE and use the result if it arrives within X ms of the cached record you were looking for, as unknown RTYPEs (mostly) work, and when they don't, the stub should be bypassing the configured recursive resolver anyway.

> How would you represent the canonicalization?

Basically, it boils down to the following requirement space for DNSSEC to work with CLONE-type operations:

1:  If the input space is small, DNSSEC can be done statically.

2:  If the input space is huge, but, IN PRACTICE, the used input space is small, dynamic signatures and caching works without introducing single-points-of-failure in practice.  [1]

It can be new RRs (CLONE), it can be abusing existing RRs (0-TTL CNAME/DNAME), but dynamic DNSSEC signatures are REQUIRED unless you use new RRs which support many-to-one mappings.

3:  If the input space is huge and, in practice, the used input space is large, the solution space is either:

a)  Dynamic signatures which ARE a single-point-of-failure and DOS target

b)  New RRs which represents MANY-to-one mappings, where only a few such RRs can cover the entire space for a given name (enables static signatures)

c)  "Paint the mountain pink and slap an SEP ('Somebody Else's Problem) field on it".  Its far better than having to try to explain the suspicious new moon...

This is why I believe that a CLONE type record needs to be a 'canonicalization program' or a pointer to how to do the canonicalization (namely, a pointer to a program), because in order for DNSSEC to work without static signatures in case 2 or 3 (which is, I believe, what is to be addressed), CLONE records need to be many-to-one mappings and not one-to-one mappings, and the only way to do truly generic many-to-one mappings is to sign a program that the recipient can use to compute the mapping.

Which is, admittedly, a MUCH harder problem but necessary if dynamic signatures are off the table (as some in this group have advocated).

[1] Dynamically generated signatures, however, are NOT a single point of failure NOR a DOS opportunity IF the 'in practice' canonicalization space is small.  This can be measured by applying the canonicalization transformation to a large written corpus (eg, a target-language email corpus).

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Mar 2011 12:46:57 -0800

On 03/07/2011 18:51, John Levine wrote:
>> >it.:)

Fair point. Anyone have good references on stubs setting EDNS options? :)

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Mar 2011 13:02:55 -0800

> take this as a comment on the draft).

Ok.

> most users want to use the variant labels in URLs and email addresses, and

What I've heard from that community is that they want the most out of 
the variants that they can get. Perhaps Vaggelis can say more about 
that. However in the end I don't think we're going to get a definitive 
answer that is going to satisfy "us" as technologists. Users don't 
understand what they want to the level of technical detail that will 
satisfy us, so I think we need to try and provide as much flexibility as 
possible.

That said, I think that as DNSSEC becomes more widely deployed that 
using the variants for these purposes is going to be less attractive 
unless we can provide a solution. Obviously I have a strong feeling that 
the solution I'm offering is the right one, but I don't claim to be 
omniscient. :)

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Mar 2011 13:22:05 -0800

On 03/08/2011 07:53, Nicholas Weaver wrote:
> This came up in private discussion when it was clear I had a
> different model (resolver change) vs I can't remember who (stub
> change).
>
> EG, take arabic.  With a resolver change model, every resolver which
> has at least a few arabic clients needs to upgrade, which is
> effectively everyone.  But most resolvers won't substantially
> benefit, so why bother upgrading?

I'm not sure how stub change relates to Arabic, can you please expand on 
that? Specifically my understanding is that the "hard parts" of dealing 
with Arabic are located in the application layer so that what gets 
handed to the stub is the punycode. At the punycode layer what 
differentiates Arabic from other issues?

> But with stub changes, ONLY those who actually benefit substantially

I think that concept has a lot of validity. OTOH the reason I'm 
suggesting a method that only requires authoritative server updates for 
all of the benefit other than DNSSEC.

>>> As it is far more likely that clients will upgrade (EG, as part
>>> of the browser or OS) rather than resolver authorities in many
>>> cases.
>>>
>>> I do not know if unknown EDNS0 options are likely to be passed
>>> from the stub to the authority through the intermediary
>>> resolver,
>>
>> resolver is not CLONE-Aware then sending the option wouldn't help
>> since it wouldn't understand any CLONE RRs that it received back.
>
> Hmmm, which again makes me think the model might need to be more like
> how AAAA records are handeled: Do a parallel fetch for CLONE and use
> the result if it arrives within X ms of the cached record you were
> looking for, as unknown RTYPEs (mostly) work, and when they don't,
> the stub should be bypassing the configured recursive resolver
> anyway.

This method of operation is very different than what I'm proposing, but 
I'd be interested in whether other people think that it would be an 
improvement.

>>> describing a set of character/word transformations that should
>>> be applied, NOT just a simple pointer.[1]
>>
> Basically, it boils down to the following requirement space for
> DNSSEC to work with CLONE-type operations:

I'm sorry, I didn't understand your answer at all. I see dynamic signing 
as orthogonal to what I'm proposing, but if someone else wants to try 
and illuminate me, please feel free. :)

Doug

--

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 8 Mar 2011 13:37:32 -0800

On Mar 8, 2011, at 1:22 PM, Doug Barton wrote:
> I'm not sure how stub change relates to Arabic, can you please expand on that? Specifically my understanding is that the "hard parts" of dealing with Arabic are located in the application layer so that what gets handed to the stub is the punycode. At the punycode layer what differentiates Arabic from other issues?

Its just the incentive issue.  The stub is located on the system that has 100% benefit or none, so those who want the benefit do the upgrade and get it.

The recursive resolver only benefits for the few fraction of the clients behind it, so less incentive to upgrade.

> I'm sorry, I didn't understand your answer at all. I see dynamic signing as orthogonal to what I'm proposing, but if someone else wants to try and illuminate me, please feel free. :)

I'm of the opinion "If it can't do DNSSEC, we shouldn't do it".

Yes, DNSSEC makes life more complicated, but if we believe DNSSEC has ANY value, we MUST ensure that any proposed extensions to DNS, especially in how names are resolved, works with DNSSEC.  We shouldn't say "DNSSEC works only for ASCII" or "only for precanonicalized names".

Thus by that assumption and the assumption that this is for large-space canonicalization (so just static aliasing can't work), you MUST either do dynamic signing or have your CLONE RRs be a canonicalization program, not just a mapping from A->B. 

And there are some (NOT ME, but some) who don't like the idea of anything which requires dynamic signing.

And thus, dynamic signing is not orthoginal, as your current proposal requires dynamic signing for DNSSEC to work.

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Mar 2011 14:12:41 -0800

On 03/08/2011 13:37, Nicholas Weaver wrote:
>>> EG, take arabic.  With a resolver change model, every resolver
>>> which has at least a few arabic clients needs to upgrade, which
>>> is effectively everyone.  But most resolvers won't substantially
>> I'm not sure how stub change relates to Arabic, can you please
>> expand on that? Specifically my understanding is that the "hard
>> parts" of dealing with Arabic are located in the application layer
>> so that what gets handed to the stub is the punycode. At the
>> punycode layer what differentiates Arabic from other issues?
>
> Its just the incentive issue.  The stub is located on the system that
> has 100% benefit or none, so those who want the benefit do the
> upgrade and get it.

I think I understand what you're saying about incentive, I just want to 
be clear that there is nothing special about Arabic as it directly 
relates to the stub.

> I'm of the opinion "If it can't do DNSSEC, we shouldn't do it".

I agree with you, to some extent.

> Yes, DNSSEC makes life more complicated, but if we believe DNSSEC has
> ANY value, we MUST ensure that any proposed extensions to DNS,
> especially in how names are resolved, works with DNSSEC.  We
> shouldn't say "DNSSEC works only for ASCII" or "only for
> precanonicalized names".

The solution I'm proposing does allow for validation of the variant 
labels, but it requires a CLONE-Aware resolver (and/or perhaps stub).

I think now I'm seeing more about what you mean in regards to a CLONE 
method utilizing dynamic signing, but what I don't understand is how you 
handle the DNSKEY problem for CLONEs at the zone level?

> Thus by that assumption and the assumption that this is for
> large-space canonicalization (so just static aliasing can't work),
> you MUST either do dynamic signing or have your CLONE RRs be a
> canonicalization program, not just a mapping from A->B.
>
> And thus, dynamic signing is not orthoginal, as your current proposal
> requires dynamic signing for DNSSEC to work.

We'll have to agree to disagree on this. My proposal provides a 
mechanism for handling DNSSEC for the variants without dynamic signing, 
albeit it does require the resolver to be upgraded for it to work.

Meanwhile, I'm going to reply to your reply to my other thread here 
because I think it's relevant. If you're right that a non-CLONE-Aware 
resolver would pass the unknown RR if it's requested directly, then 
applications that are concerned about DNSSEC validation for the variants 
_could_ request the CLONES RR first, then handle the "transformation" to 
using the preferred version internally itself, or we could put that 
logic in the stub. If I understand other things you've written correctly 
you're saying that you don't want the stub/application layer to 
"pre-canonicalize" which I think what I'm suggesting in this paragraph 
would be, but I'm wondering why? To take IDNs as an example, we already 
require a "transformation" for U-label to A-label, so this wouldn't be 
that much different.

So how hard are things going to break if stubs start requesting an RR 
that the RNS doesn't understand?

Doug

--