Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same"

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 11 Aug 2010 13:03:24 +0800

I have been involving in the icann idn process for many years.

if provisioning works, icann would have used provising.

Icann idn tlds need the solution such as bname.

----- Original Message ----- 
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 11, 2010 12:18 PM
Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same"

>>    4.  Provisioning only: document how to do what's needed by
>>    provisioning, and explain why the WG is not doing anything else.
> 
> Yeah.
> 
> Anyone been following the progress of the recent ICANN IDN TLDs?
> They're as good a live experiment in cloning trees via provisioning as
> we're likely to find.
> 
> R's,
> John
>

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 01:20:59 -0400

> if provisioning works, icann would have used provising.

Hmmn.  I see that CNNIC says in section 5 of their implementation plan for 
the IDN ccTLDs that they're making traditional and simplified Chinese 
domain names equivalent.  If they're not doing that by provisioning, what 
are they're doing instead?

http://www.cnnic.cn/html/Dir/2010/06/12/5852.htm

R's,
John

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 11 Aug 2010 13:40:34 +0800

provision is the policy based, not the technology based.

it is not a long term solution; it is a short solution.

long term solution needs the technology solution  such as bname.

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 02:05:38 -0400

> long term solution needs the technology solution  such as bname.

Not to refight old battles here, but provisioning the DNS, whether 
manually or automatically, is only a small part of making two domains "the 
same".

If the domains have web servers, the web servers need to be configured to 
accept names in both domains.  If the domains accept mail, the mail 
servers have to be configured to accept names in both domains, possibly 
including the MX records if the mail server is in a domain different from 
the two "the same" ones.  And so on and so forth for instant messaging, 
and every other protocol and subsystem that uses domain names.

Something like BNAME might make the provisioning of the DNS somewhat 
easier, but I would argue that wouldn't solve enough of the overall 
problem to be worth doing.

R's,
John

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 11 Aug 2010 14:30:41 +0800

----- Original Message ----- 
From: "John R. Levine" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 11, 2010 2:05 PM
Subject: Re: [dnsext] DNSEXT charter and treating DNS names as "the same"

> problem to be worth doing.

for domain name delegations,  the bname is perfect for domain name registry such as icann, tld operators.

---

From: [email-masked]
Date: Wed, 11 Aug 2010 20:36:35 +0900 (JST)

> From: "Jiankang YAO" <[email-masked]>

There are many solutions.

1. BNAME + Server configuration change for all servers.

   -> TLD's work is limited,
      but all registrants need to configure their servers.

2. New DNS software which generates synthesized CNAME with online signing
   for each query.
   + Server configuration change for all servers.

   -> Same as BNAME, but no DNS protocol change is required.
      Special DNS software solves BNAME problem.

   May I write prototype implemetation ?

3. Update IDNA. Implement TLD specific preprocess in the application.

   -> It does not need changes for TLDs, DNS protocols, servers.

   # I think it is a perfect solution, but too late to say.

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Aug 2010 09:56:58 -0400

Colleagues,

I'm writing this as co-chair, as an attempt to make the arguments on
both sides as clear as possible.  I know some of you have expressed
weariness at this topic, and would like less traffic on it.  I too
would like that, so I'm hopeful that we can come to speedy conclusions
about this topic and meet our aimed-for charter deadline in September.

> long term solution needs the technology solution  such as bname.

This claim keeps getting repeated, but without any supporting
argument.  Without a supporting argument, I don't believe it.

Here is the only argument I can think of.  Please tell me whether it
is the one (and only one) you would use.  For those who think that we
should not add more things to the DNS in order to solve some small
percentage of cases, please tell me whether you think the case in
question is big enough to meet the threshold where we might want to
add something to the protocol, or whether you can think of ways other
than BNAME (or something like it) to accomplish the same thing.

Here's the supporting argument: Suppose we have two domain names, N1
and N2.  These are to be delegated by parent P, such that there would
be two zones N1.P and N2.P.  Now, P's policy is that the zones N1 and
N2 are to be maintained such that a user arriving at any name X.N1.P
and a similar user arriving at any name X.N2.P will have an experience
as though they were "the same name".  (So, for instance, in a web
environment these would be "the same" web site; mail destined to
[email-masked] and to [email-masked] always reaches the same mailbox "user",
and so on.  This might need formal tightening, but for now this
ostensive definition will do.)

Under a provisioning-only regime, the requirement that N1.P and N2.P
be "the same name" cannot be guaranteed.  That is because under
provisioning, it would be necessary to duplicate all the zones all the
way down the tree, and there is no easy way in the DNS to check that
two zones are equivalent without walking the zone.

Is that the argument?

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Aug 2010 10:17:36 -0400

The difference is seen at the zone delegation points. And when I look
at the issues there, the objective of making one tree look like
another looks to raise security issues as far as I am concerned.

Lets take the example where .china is introduced with the idea that it
it is going to be a clone of .cn.

This objective is not objectionable in itself, but it is not free of
provisioning issues. Consider what happens when someone attempts to
access google.china. Their Web browser finds the record that asserts
*.china -> *.cn and attempts to access google.cn.

What Host header does the browser use?

Now before people start to say that this is an application issue. It
is certainly an issue that the proponents of any scheme have to
consider and provide an answer for. If someone wants to lay a rail
line over an existing road, they have to build the bridge. Any
proposals that fail to explain what the application level
considerations are should be rejected as incomplete. It is certainly
going to be a waste of time pitting them to IETF last call. The DNSEXT
WG cannot make a DNS proposal that breaks HTTP.

There are two options here. Either the host header is google.china, in
which case the Web server has no idea what to do with the request as
it does not serve that site. I really don't think we want Web servers
being required to work out what the browser meant when presented an
unknown host header Or the host header is google.cn in which case the
Web server is unaware that the user requested a different URL.

Probably the best approach would be to make the host header be the
mapper URL and create a new header to tell the Web server what the
original host was.

But whatever way you try to slice up the back end, you cannot make
this work without browsers being totally engaged in the DNS name
translation process. Today they simply call gethostbyname.

If you try to do transparent fixup in the DNS so that the client asks
for google.china and gets back the A records for google.cn from the
resolver, we now have a facility that can be used to establish
transparent redirects without browsers ever being aware that they were
redirected.

The only point where the browser is going to find out is when SSL
stops working because the site certificate is for a different domain.
So now the user is going to be told that the cert does not match.

On Wed, Aug 11, 2010 at 1:20 AM, John R. Levine <[email-masked]> wrote:
> the IDN ccTLDs that they're making traditional and simplified Chinese domain
> names equivalent.  If they're not doing that by provisioning, what are
> they're doing instead?
>

-- 
Website: http://hallambaker.com/

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 11 Aug 2010 16:22:38 +0200

> two zones are equivalent without walking the zone.

For me, yes, with the addition that it is not to me perfectly clear if the risk is zero that competition rules in various legislations might force the two zones N1.P and N2.P be delegated to entities according to some RFP process that MIGHT result in the two domains be run by two different registries.

Specifically if N1.P exists, and N2.P is to be allocated. A competitor to the registry for N1.P might very well ask to become the registry for N2.P, if N2.P was in reality delegated.

If instead N1.P is delegated, and N2.P was some pointer to N1.P, then that competition argument would not exist.

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Aug 2010 11:21:46 -0400

This is what I believe the argument is.

My point is that while provisioning is complex, introducing the
pointer does not eliminate the complexity. All that is achieved is
that the complexity is moved from the DNS provisioning process to the
application configuration process.

The provisioning problem also looks much worse if we look at the
abstract capabilities of DNS as opposed to how it is being used in
practice. In particular, DNS in theory allows for an almost infinite
hierarchy of delegations, each of which may involve a change of
authority. But in practice there are almost only ever two authorities
which are significant, There is the TLD registry and there is the
domain name holder.

At the domain holder level, I am very skeptical of the need for
hierarchy as we move from considering the DNS as being an
infrastructure for configuring machines and towards considering it as
a means for configuring services. With the exception of telnet/SSH and
their ilk, there is no Internet application where the machine name is
really relevant any more. I do not see any reason why the issues
driving this proposal would be relevant to SSH, FTP, NNTP or any
other.

If we move to using SRV records to advertise Web Services, much of the
pressure to use hierarchy at the domain holder level disappears. If
HTTP had used SRV from the start there would be no www.google.com,
there would be only google.com.

One way in which we might perhaps square this circle is if we instead
introduced a 'Did You Mean' Resource Record that is merely a variation
of 'NXDOMAIN'.

Such a record would have no processing semantics applied. If
applications chose to use such records in their I18N processing, they
are taking the full responsibility for working out what the
interpretation is and how to fix it.

One major difference is going to be in how applications treat
hyperlinks. A browser might well and sensibly work out how to be
liberal with user input. But being liberal with interpretation of URIs
is a very, very bad plan. If there is no sand in the shoe when the job
is done wrong, the Web soon becomes filled with unenumerated
variations of wrongness and instead of a specification we end up with
a set of heuristics. The result in this case would be links that only
work sometimes.

I am quite happy for a DYM record that can be used to facilitate user
interaction in anyboxes. That seems sensible enough. But going beyond
that gives me very bad feelings. I think it is at best a rat hole and
a time sink.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Aug 2010 11:23:08 -0400

Another consequence of the DYM approach is that there would be zero
impact on DNSSEC. Which is another reason I prefer it.

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 11 Aug 2010 23:34:34 +0800

----- Original Message ----- 
From: "Patrik Fältström" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 11, 2010 10:22 PM
Subject: Re: An argument why bname-style delegation is needed (was: [dnsext] DNSEXT charter and treating DNS names as "the same")

     Patrik

+1

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Aug 2010 12:33:21 -0300

> two zones are equivalent without walking the zone.

I think that is the argument.

And now I'll use another argument for *non*-Xname changes to DNS,
as an augmentation of what exists now, to facilitate both provisioning-only
mechanisms,
and to facilitate better-scaling DNSSEC signing.

What is missing, is a *server*-side (below-the-zone-cut) apex record, which
asserts all the names by which the zone is known.

This avoids client-side processing (chasing Xnames around), makes the
assertions authoritative, and permits cross-signing of the zone owner names
(note the plural!).

(It does not, of course, prevent operator error, e.g. duplicated, non-linked
zones which diverge content-wise, but which both assert multiple names. That
kind of error can occur today for a single zone, so this is not a new
problem at all.)

Above the zone cuts, all that is needed is delegations. The bundling, as it
were, is handled on the server _to which_ the delegations occur. And, the
bundling is further asserted via the new record type (whatever it is called
- zone alias, AKA, hello_my_name_is, etc.).

P would delegate N1 to servers N1_NS_i (for i in 1..N), and N2 to servers
N2_NS_i. (Those two sets could be identical, overlapping, or completely
independent, for policy reasons.)
However, the operator of P would expect that for a given SOA SN, N1.P and
N2.P would have identical content, and specifically that the new RR type
(e.g. AKA) at the apex of both zones (N1.P and N2.P) would contain both N1.P
and N2.P.
(NB - This validation would be trivial to automate, for enforcement
purposes, once such AKA records are supported by implementations.)

Example: say the new RRtype is AKA. We would expect to see, when looking at
the respective zones:

N1.P.   SOA  (stuff);
           NS whatever;
           AKA N1.P;
           AKA N2.P;

and

N2.P.   SOA  (stuff);
           NS whatever;
           AKA N1.P;
           AKA N2.P;

RRSIG records for the normal zone rdata records, could be signed by N1.P,
N2.P, or both.
The AKA RRset would need to be signed by all members of the AKA RRset (i.e.
one RRSIG whose signer is the RDATA, for all members of the AKA RRset).

Provisioning systems (on the child side) for specific implementations might
in fact use (new feature alert) hard-linking of zone data to multiple names,
thus guaranteeing synchronous zones and reducing space and signing
requirements.

And note that this would support zones with many names, such as N1.P, N2.P,
N1.Q, N2.Q, N1.X.Y, N1.A.B.C, and even N1 (i.e. its own TLD). P (by policy)
might insist on N1.P and N2.P, but that would *not* preclude additional AKA
records.

Having only portions of a tree have many more names, could be handled
(trivially) by delegating those portions, even to/on the same server(s).
E.g. smtp (under the identical N1.P and N2.P AKA zone) delegated to some NS
set, and on those servers, zone smtp.N1.P having apex AKA records smtp.N1.P,
smtp.N2.P, smtp.BIG-CO.example.com, smtp.N3.Q, smtp.N4.R, and
smtp.BIG-CO.co.CCtld.

Querying by any name "just" returns the right data, which is identical
independent of name. It works for all existing resolvers, modulo DNSSEC
validators having to have new logic to support AKA signing.
The AKA signing is basically just a way of validating independent paths for
SEP (secure entry points) to the same zone data, and ensuring that the use
of "sister" signatures is in fact authorized and valid.
At worst, the lack of AKA support will result in some variants of zones
being seen as insecure, and that can be resolved (pun not intended) by
adding appropriate RRSIG data until AKA support is sufficiently widespread.

This differs from the xNAME proposals in that the parent side is never doing
anything other than NS (and possibly DS), which supports pretty much any
model for delegation, including parallel registries operated by different
parties for IDN TLD variants. It also means that provisioning can begin now,
without changes required later, since the extra "goodness" is added below
the zone cut.

The most important features are:
No special server-side processing
No flag bits
No signaling required
No client-side query re-writing (xNAME)
Fully backwards compatible for non-DNSSEC
Mostly backwards compatible for DNSSEC validation
Deployment of AKA-supporting code encourages both DNSSEC and IDN deployment
Does not represent a significant barrier to DNSSEC deployment (no flag day)
Provisioning-only for IDN delegations
One-time-only new RRtype at a zone apex
Good scaling on RRSIGs for IDNs

Brian

---

From: Alex Bligh <[email-masked]>
Date: Wed, 11 Aug 2010 16:44:47 +0100

> argument.  Without a supporting argument, I don't believe it.

I'm not putting this to support the need for a protocol change,
but I had thought the argument was this:

Let us suppose that A1 needs to be equivalent to A2, B1 to B2 etc.

Provisioning type solutions work if one wishes to ensure
  x.A1
is equivalent to
  x.A2
for any X.

However, the servers to which they are delegated then need to run zones
for x.A1 and x.A2. That's not so bad (two zones).

Now suppose the problem is mapping
  x.Ai.Bj.Ck.Dl
to
  x.A1.B1.C1.D1
for any i, j, k, l. You have an O(a^n) problem in terms of the number of
zones that have to be supported at the left hand end. That's why you
'have' to make whole sections of tree map to whole other sections of
tree.

So the provisioning problem is /smallest/ at the TLD level, but largest
at the end user level (or whoever provides DNS for the end user).

I am guessing there is also an issue that if the number of equivalences
in one label is large, (say at the C label in the above), then the
end DNS config needs to know all equivalences of C, which is error
prone and might change over time.

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Aug 2010 11:55:53 -0400

No hat

> 'have' to make whole sections of tree map to whole other sections of

There have been arguments in favour of that position, yes.  I haven't
seen an argument why BNAME would solve it, however.

BNAME occludes things beneath it just as DNAME does.  So if (say) we
had Dl BNAME D1, we'd still need to do all the provisioning of Ck/C1,
Bj/B1, and so on.  No? 

> prone and might change over time.

Also true, but it also still needs someone to provision the BNAMEs as
opposed to (say) the DNAMEs + apex records if needed.  I think,
anyway.  If someone has an argument why I'm wrong (and I'm fully
prepared to be.  I am, for better or worse, unafraid of being made a
fool of in public), please educate me.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 11 Aug 2010 17:35:16 +0100

> had Dl BNAME D1, we'd still need to do all the provisioning of Ck/C1,

I think a desirable xNAME quality would reduce this to a O(n) problem,
so you could just do

D2. IN xNAME D1.
D3. IN xNAME D1.
D4. IN xNAME D1.

...

C2.D1. IN xNAME C1.D1.
C3.D1. IN xNAME C1.D1.
C4.D1. IN xNAME C1.D1.

...

B2.C1.D1. IN xNAME B1.C1.D1.
B3.C1.D1. IN xNAME B1.C1.D1.
B4.C1.D1. IN xNAME B1.C1.D1.

...

A2.B1.C1.D1. IN xNAME A1.B1.C1.D1.
A3.B1.C1.D1. IN xNAME A1.B1.C1.D1.
A4.B1.C1.D1. IN xNAME A1.B1.C1.D1.

...

x.A1.B1.C1.D1. IN (whatever)

IE you never need to consider records for (e.g. Bj.Ck.Dl. for j!=1 or k!=1).
I can't see how a provisioning based system has that quality. Doesn't
that mean at the Ai level, you'd need 4*4^3 entries.

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Aug 2010 12:39:45 -0400

> I think a desirable xNAME quality would reduce this to a O(n) problem,

Excellent!  We have another concisely-worded requirement.  Suzanne,
can you add this to the list?  Thanks

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: John Levine <[email-masked]>
Date: 11 Aug 2010 17:23:31 -0000

>A4.B1.C1.D1. IN xNAME A1.B1.C1.D1.

I must be missing something.  Let's assume that C1.D1 is delegated to
someone other than the operator of D1.  Who publishes the third and
fourth groups of xNAME records?  If it's the operator of D1, how does
he find out what xNAMEs he needs to publish?  If it's the operator of
C1.D1, how does the TLD ensure that the delegated operators are
publishing all of the xNAME records they're supposed to?

And of course, if they're serious about equivalence, who verifies that
all of the mail, web, etc. applications are properly aliasing all of
the An.Bn.Cn.Dn names?

Here's the one-senence version of why I think provisioning is the way
to go (with a hat tip to Phill): To make two domains usefully
equivalent, the amount of application provisioning necessary down at
the leaves will be so large that any savings from an xNAME hack up in
the DNS tree are lost in the noise.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Aug 2010 18:34:58 +0100

> application configuration process.

That isn't quite correct: the application configuration requirements are
the same in both cases. BNAME moves complexity from domain provisioning
to client resolvers.

> introduced a 'Did You Mean' Resource Record that is merely a variation

This moves complexity from the provisioning process to the client
application, and requires application code changes not just configuration.
(It reminds me of the old SMTP canonicalization requirement, i.e.
CNAME-based mail domain rewrites.)

To me this all looks like various efforts to offload costs from the people
who want multiple parallel domains to their users.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST FAIR ISLE: VARIABLE, BECOMING NORTHEASTERLY, 3 OR 4. SLIGHT OR
MODERATE. RAIN OR SHOWERS. MODERATE OR GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Aug 2010 13:48:47 -0400

Yes, we cannot eliminate the complexity, we can only move it around.

Looking at the impact that this proposal has on SSL, there is no way
that we can make this work without the application layer being aware
that it is taking place.

If *.china is created as an alias for *.cn, then as a CA, I am going
to have to know to tell all my customers that they need to replace
their existing SSL certificates with new ones with an additional alias
for the *.china version of their name. This is not an issue that can
be addressed in the DNS alone.

I think that the proper place to compartmentalize this complexity is
in the multibox where user input is dealt with.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Aug 2010 18:55:03 +0100

> transparent redirects without browsers ever being aware that they were

CNAME and DNAME already do that.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SHANNON ROCKALL: NORTHWEST 4 OR 5. MODERATE. SHOWERS. GOOD.

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 11 Aug 2010 18:19:09 +0000

Andrew, Alex, et. al.,

Sure, happy to add this to the problem statement doc, with the
following questions:

1. Does any solution currently proposed handle this case? At a glance
I don't think so.

2. Does anyone reading this want to speak up and say Alex's
formulation corresponds to a use case they've seen and they would use
this capability if they had it?  I'm well aware that's a weaker
constraint than Andrew has been trying to encourage (as I read it,
he's been trying to get us to "you couldn't do what you need to do
without it" rather than "you'd use it if you had it"), but I'm willing
to lower the bar for purposes of discussion.

thx,
Suzanne

---

From: Alex Bligh <[email-masked]>
Date: Wed, 11 Aug 2010 19:21:39 +0100

--On 11 August 2010 17:23:31 +0000 John Levine <[email-masked]> wrote:

> fourth groups of xNAME records?

So, lets assume D1's zone file contains:
  C1.D1. IN NS ns.example.com.
as would be the normal registry case. I would presume these records
also live in D1's zonefile.
  C2.D1. IN xNAME C1.D1.
  C3.D1. IN xNAME C1.D1.
  C4.D1. IN xNAME C1.D1.
in each case served by the nameservers for D1.

Similarly, C1.D1's zone file contains:
  B1.C1.D1. IN NS.example2.com.
as is the normal registry case, and I would presume that these records
also live in C1.D1's zone file:
  B2.C1.D1. IN xNAME B1.C1.D1.
  B3.C1.D1. IN xNAME B1.C1.D1.
  B4.C1.D1. IN xNAME B1.C1.D1.
in each case served by the nameservers for C1.D1. (here ns.example.com)

Further, B1.C1.D1's zone file contains
  A1.B1.C1.D1. IN NS.example3.com.
as is the normal registry case, and I would presume that these records
also live in B1.C1.D1's zone file:
  A2.B1.C1.D1. IN xNAME A1.B1.C1.D1.
  A3.B1.C1.D1. IN xNAME A1.B1.C1.D1.
  A4.B1.C1.D1. IN xNAME A1.B1.C1.D1.
in each case served by the nameservers for B1.C1.D1. (here ns2.example.com)

> If it's the operator of D1, how does

The xNAME records are transferred to the delegating registry in the same
way NS records are now.

> all of the mail, web, etc. applications are properly aliasing all of

The registry could, for instance, only accepts an xNAME record if it
matches the appropriate policy equivalence test for an existing NS
record. D1 will only accept C2.D1. as an xNAME if C2 is equivalent
to C1; how it does that equivalence is a policy matter not a technical
matter (it might be 'chinese characters with equivalent meaning').

Because C2.D1. is never delegated *at all*, it any children of
C2.D1. will always be equivalent at a DNS level to the same
child of C1.D1. because the lookup process would be performing
that lookup within the C1.D1. tree. The C2.D1. tree does not
itself exist; C2.D1. is just an alias to C1.D1.

> the DNS tree are lost in the noise.

Well, that may be the case, and note the prefix to my post to Andrew,
that I wasn't suggesting this requirement makes the whole thing useful,
I was suggesting it may be a reason why people wouldn't argue for provision.

As you say, making names "equivalent automatically in DNS" does not
necessarily fix the issue. Two case spring to mind. In either a
"dumb DNS provisioning hack", or my thing above, an http request
for http://www.A2.B3.C4.D2/ would correctly be made to the server with
IP address given by the A record for www.A1.B1.C1.D1. However, the
GET line will be:
   GET http://www.A2.B3.C4.D2/index.html
or whatever. This means, *irrespective* of the DNS method used, that
the server operator will have to know to configure that server to
respond to every Ai,Bj,Ck,Dl, even though they may only know the
policy for equivalence at the Ai level (and indeed it may change
"under their feet"). Arguably, this could fixed by browsers
canonicalising the URL in the same way as DNS, but if you are
doing that, why put the hack in at the DNS layer at all?
Secondly, if you make the above case an https: request, the server
has now lost any way to disambiguate between a request to
www.A1.B1.C1.D1. and any other www.Ai.Bj.Ck.Dl request, which means
it has no way of knowing which certificate to serve. That either
requires a TLS/cert/browser hack, or worse. Hopefully the hack does
not require having O(n^2) certificates.

And this is fundamentally my problem with the whole BNAME idea.
I see how it might be useful as a fun DNS tool, but not how
it would actually work in practice as I can't see how the upper
layers would work.

-- 
Alex Bligh

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 11 Aug 2010 21:41:33 +0200

> publishing all of the xNAME records they're supposed to?

The various managers of the various zones handle the records.

We have to remember one thing here, and that is that there is absolutely no ability to get any agreement on "what is equal". That implies everyone will have their own view of what is equal.

A scheme like the one above make it possible for each registry for each one of the zones to make up their mind what xNAME RR they want to publish. And finally, it is the application manager that makes up their mind on what they want to support.

Just like today when people might choose to (or not to) handle both www.example.com and example.com as aliases in their HTTP server.

I.e. we must separate the question of "what is equal, and who makes that decision" from "given someone decide A and B should result in the same data when being resolved, how to make that in an as practical way as possible".

In the scheme above, if the final end user that want the email addresses [email-masked] and [email-masked] "should work", that user will request that from some application hosting provider (maybe he will run the server themselves). The email hosting provider will configure both strings, and then ensure both domains will resolve.

I am not worried.

Yes, the number of permutations might be large. But for example here in Sweden we already have this "problem" where some people have chosen themselves to support bot (for example) faltstrom.se and fältström.se. But I do not want to support fältstrom.se (i.e. mixed a/ä and o/ö).

So even if we had:

faltstrom.se. IN NS ...
fältström.se. IN xNAME faltstrom.se.
fältstrom.se. IN xNAME faltstrom.se.
faltström.se. IN xNAME faltstrom.se.

...I would never configure my application to support all four...and that is fine, as *I* make the decision. As the domain holder.

Other people might make other decisions.

So I actually think this scheme makes sense for that reason as well. That the decision is where the decision should be. If a "parent" zone does not have "enough" xNAME in there, you talk with your parent.

   Patrik

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 16:09:43 -0400

> We have to remember one thing here, and that is that there is absolutely no ability to get any agreement on "what is equal". That implies everyone will have their own view of what is equal.

Quite right.  That's why I don't see the point in inventing new DNS hacks 
that enshrine one defnition or another in code.

R's,
John

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 11 Aug 2010 22:13:45 +0200

On 11 aug 2010, at 22.09, John R. Levine wrote:

> Quite right.  That's why I don't see the point in inventing new DNS hacks that enshrine one defnition or another in code.

Ok, then I misunderstood your posting.

If I am admin for the zone B.C., then I want to make a decision to have for example:

A1.B.C. IN NS ...
A2.B.C. IN xNAME A1.B.C.
A3.B.C. IN xNAME A1.B.C.

This decision can be based on a number of things:

1. My own preferences

2. Some policy admin for B.C. has, which implies I have promised to have it

3. The domain holder of A1.B.C. has requested it

Maybe other reasons as well.

What I think would be a good thing is some xNAME "thing" that makes it possible for me to implement this. In the small piece of Internet that I am responsible for. The B.C. zone.

   Patrik

---

From: "John R. Levine" <[email-masked]>
Date: 11 Aug 2010 17:09:29 -0400

> 3. The domain holder of A1.B.C. has requested it

Maybe I'm spoiled, but the DNS records in my zones are all generated by 
perl scripts out of a database, so the extra programming to clone a zone 
is no big deal.

I keep hearing people (not you particularly) saying "well, this hack does 
MY job serving DNS, and the other 90% is someone else's problem so I don't 
care."

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Aug 2010 18:23:34 -0300

Let's consider two very similar notions, which have entirely different
semantics under the hood, and differing sets of required changes to the DNS
ecosystem.

First, the xNAME approach:

In the zone B.C, we establish the equivalence directly, and need new kinds
of records (xNAME).

A1.B.C NS ...
A2.B.C xNAME A1.B.C

Note also, that all other (xNAME) labels are "second class" citizens; the
labels won't be usable until resolvers or clients understand xNAME; the
other labels are entirely dependent upon the first label, making the system
somewhat brittle.
In a sequence of delegations, any single delegation which loses its X1
entry, breaks the whole chain for all W[1-N].X[1-N].Y[1-N].Z permutations.

Second, an alternative approach, where the equivalence is established
indirectly, in the child zone(s) below the zone cut(s):

A1.B.C NS ...
A2.B.C NS ...
A3.B.C NS ...

And on the authority server(s) pointed to by the NS records:
A1 == A2 == A3 (under B.C) => zone contents for the equivalent zones

The same number of entries is required in the B.C zone.
There is the requirement that the target of the delegation "understand" that
queries, regardless of which A[1234] they show up under.
And likewise that server would need to understand all the permutations
Ai.Bj.Ck.Dl.

However, and this is important... Generally speaking, the server will only
be authoritative for stuff at or below Ai.

This means that the tree of labels can be folded via hard-links at each
level of the tree, on the child tree (or hash table) used for deciding how
to answer queries.

So, on the leaf authority server, that server can have D1 == D2 == D3 == D4
(TLD), and under that, (C1 == C2 == C3 == C4).D1, etc., preserving the O(n)
behavior.

Each label Dl points to the same node, which has children Ck all pointing to
the same child node, which has children of its own Bj pointing to the same
node, and finally Ai great-grand-children.

This is less brittle, in that a single error above the authority server for
the equivalent zones, will only break one possible path among the very many
paths -- they are all NS records.

The equivalence is done by the zone admin of the authority server, rather
than the zone admin of the parent zone, and thus it removes the parent zone
admin from having that administrative burden.

And, most important, the DNS protocol does not need to change to support
this, only the implementations of authority servers to provide this
equivalence hard-coding capability. The ability itself does not require any
interoperability, as it is local, and thus creates a potentially more
reliable resulting set of systems through the delegation and authority chain
- since multiple vendors' code can be used independently once the feature is
available.

Brian

2010/8/11 Patrik Fältström <[email-masked]>

> >> We have to remember one thing here, and that is that there is absolutely
> no ability to get any agreement on "what is equal". That implies everyone
> will have their own view of what is equal.
> >
> What I think would be a good thing is some xNAME "thing" that makes it
> possible for me to implement this. In the small piece of Internet that I am
> responsible for. The B.C. zone.
>
>   Patrik
>
>

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Aug 2010 15:15:24 -0700

On 8/11/10 1:09 PM, John R. Levine wrote:
>> We have to remember one thing here, and that is that there is 
>> absolutely no ability to get any agreement on "what is equal". That 
>> implies everyone will have their own view of what is equal.
> Quite right.  That's why I don't see the point in inventing new DNS 
> hacks that enshrine one defnition or another in code.
John,

Why get bogged down with semantics?  IDN creates difficult to resolve 
issues in DNS.  For example, when dealing with ideograms, verbally 
communicating a domain can be problematic.  For cases where users might 
not know which variant to use, cloning different domains seems to share 
similar issues with bnames.  For TLS certificates to show the correct 
target, http 302 redirects might be a solution.  This approach could 
also be used in conjunction with a tactic needed to preclude use of 
aliased names as targets within the resource record.  It seems this 
represents a configuration issue that will need to be handled, but there 
does not appear to be a better solution when nothing is changed with 
respect to the DNS protocol.

How do you envision these issues being resolved?

-Doug

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 11 Aug 2010 19:13:17 -0300

On Wed, Aug 11, 2010 at 06:23:34PM -0300, Brian Dickson wrote:
...
> - since multiple vendors' code can be used independently once the feature is

For non DNSSEC zones this is straight forward to implement. For Signed
zones this is much harder to accommodate, but probably the only and
most sane workable solution.

> Brian

Fred

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Aug 2010 18:31:09 -0400

Not from the parent authority domain, they don't.

Within an authority area, this problem can be solved with provisioning
and CNames etc. Its the parent authority name issue that is tricky.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 11 Aug 2010 23:37:18 +0100

Suzanne,

> to lower the bar for purposes of discussion.

I'm not sure what I am suggesting is a new criterion; I think it's
just a reformulation (and perhaps a useful one, that's for others)
of an existing one. I'll attempt to explain why:

Any system conforming to the criterion I specified has the property
that in x.Ai.Bj.Ck.Dl, the zone containing x is only stored once,
in x.Ai.Bj.Ck.Dl, because equivalence is performed rightward of
x, and any formulation only storing the zone once must necessarily
have this property (i.e. it's an if-and-only-if). If the zone
is stored more than once (i.e. this criteria does not
apply), that implies the data could differ, which implies there
is no way of an operator further up the tree ensuring that
labels downstream remain equivalent. For instance, if C can ensure
through the D zone file that C1.D1 is equivalent to C2.D1, then
if and only if C can ensure that Ax.By.C1.D1 == Ax.By.C2.D1
for all x and y, this is equivalent to there being only one
copy of everything below C1 (or at least of every copy being
forced to be identical). So I don't think my criterion is much
more than a restatement of the proposed criterion which states
that a property of xNAME should be that that the xNAME owner
can ensure that not only the immediate sublevel but anything below
it shares the same equivalence. I can't see how you could satisfy
that /without/ solving the O(a^n) problem.

-- 
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Aug 2010 23:55:13 +0100

> Not from the parent authority domain, they don't.

Sorry, I was being too terse. The context was that the app would be
confused because it was unaware of the redirection, and I thought you were
saying that this is a new thing. However I could create google.dotat.at
CNAME www.l.google.com which doesn't work for just the same reason.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
MALIN HEBRIDES: NORTHWEST 5 OR 6, DECREASING 4 LATER IN HEBRIDES. MODERATE,
OCCASIONALLY ROUGH. SHOWERS. MODERATE OR GOOD.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Aug 2010 23:56:58 +0000

> Date: 11 Aug 2010 17:09:29 -0400

you're not spoiled.  but you're not running a large delegation-mostly with
high churn, where the registrants are constantly updating their NS RRsets
as they add and drop slave servers.  and you're probably not running slave
service for tens of thousand domains, either.  so, your needs are smallish.

> MY job serving DNS, and the other 90% is someone else's problem so I
> don't care."

in my own work on this topic (SHADOW), i noted that a great share of the
burden of sameness falls on third parties, and that to scale, an approach
would have to automate/synchronize the cooperation of these other parties.
in other words, not everything that the protocol can somehow already do if
every domain owner can write the local software they need, is enough.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 12 Aug 2010 05:36:22 +0200

> And likewise that server would need to understand all the permutations

I think this in reality only works as long as you believe you can keep the NS records synchronised, and possibly all referring to the same set of authority servers. Including the configuration of the servers themselves in the form of configuration of the secondary servers, zone transfer etc. Think specifically of the point in time when things are not paid for any longer, or transferred from holder Foo to Bar. And maybe A2.B.C. is changing holder... I.e. "bundling" of domain names in the registry will be an absolute requirement, instead of as with xNAME A1.B.C might go away, be re-registered by someone else, and then that party will automatically get also the A[234].B.C. names as the xNAME stayed in the parent zone as before during the transfer of the A1.B.C. domain from holder Foo to holder Bar.

So, I still think we with xNAME get easier administration as only one parent/child relationship is to be managed, instead of many. Yes, two new problems: support for xNAME and management of the xNAME itself (so it does not refer to a "dead" name). The second of these I claim is relatively easy though as that is in the B.C. zone in the example above. There are no cross zone management issues as you would have in the child zones with zone transfer management.

We of course also have to think about the following (instead of only the delegation):

A1.B.C. IN A    ...
A1.B.C. IN AAAA ...
A1.B.C. IN MX   ...
_foo._bar.A1.B.C. IN SRV ...
www.A1.B.C. IN A ...
www.A1.B.C. IN AAAA ...

A2.B.C. IN xNAME A1.B.C.
A3.B.C. IN xNAME A1.B.C.
A4.B.C. IN xNAME A1.B.C.

That way, the management of "similarities" is managed by the xNAME records, while all data is tied to the A1-related records. Yes, someone said A1 then become a first class citizen, while others are secondary, but in some cases that can be viewed as a positive thing.

   Patrik

---

From: Alex Bligh <[email-masked]>
Date: Thu, 12 Aug 2010 07:55:22 +0100

> _foo._bar.A1.B.C. IN SRV ...

That would be desirable, but an (inferior) alternative would be to say
xNAME only works for the delegations, and (e.g.) www.A2.B.C. was
handled by a second entry in the above zone file. Obviously handling
cases other than delegation is far better, but I mention this for
completeness.

-- 
Alex Bligh

---

From: Danny Mayer <[email-masked]>
Date: Mon, 16 Aug 2010 09:27:02 -0400

On 8/11/2010 11:34 AM, Jiankang YAO wrote:
> For me, yes, with the addition that it is not to me perfectly clear
> if
the risk is zero that competition rules in various legislations might
force the two zones N1.P and N2.P be delegated to entities according to
some RFP process that MIGHT result in the two domains be run by two
different registries.
> 
> Specifically if N1.P exists, and N2.P is to be allocated. A
> competitor
to the registry for N1.P might very well ask to become the registry for
N2.P, if N2.P was in reality delegated.
> 
> If instead N1.P is delegated, and N2.P was some pointer to N1.P,
> then
that competition argument would not exist.

If the problem is legislative, it really doesn't belong as a DNS issue.
If you have this situation you can easily have N1.P copied to the owner
of the N2.P registration and have it provision N2.P.

danny

---

From: "Jiankang YAO" <[email-masked]>
Date: Mon, 16 Aug 2010 21:59:47 +0800

----- Original Message ----- 
From: "Danny Mayer" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>
Cc: "Patrik Fältström" <[email-masked]>; "Andrew Sullivan" <[email-masked]>; <[email-masked]>
Sent: Monday, August 16, 2010 9:27 PM
Subject: [dnsext] Re: An argument why bname-style delegation is needed

> some RFP process that MIGHT result in the two domains be run by two

the problems is that  if the two zones N1.P and N2.P are delegated to the same entities,
we need do something for them.

btw, if bank.p1 and bank.p2 are owned by the different users, there has a big phishing problems.
I think that if various legislations body recognize it, it will change the policy.

as far as I know, icann will not force  the two zones N1.P and N2.P be delegated to entities.