Subject: [dnsext] why provisions fail in alias domain names?

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 16 Aug 2010 10:13:31 +0800

there is a tld called example1 and example2.
we hope that example1 and example2 to be same (including their childrens).

for the second level's domain names,
if we configure a.example1 and a.example2 to be same, that may be feasible.
the registry has enough powers and resources to scan and monitor these domain names: a.example1 and a.example2,  the registry can force the registrants to 
make these two domain names to be same if they detect that these names can not get provisions in the same way.

for the 3rd or 4th or more levle's domain names,

if there are domain names: a.a.a.a.a.example1 and a.a.a.a.a.example2, how do the registry of example1 and example2 know and monitor these domain names a.a.a.a.a.example1 and a.a.a.a.a.example2.

the registry may not know how many domain names in the zones of a.a.a.a.a.example1 and a.a.a.a.a.example2.

different levels domain names are managed by different organizations.
there are millions of organizations who manage the different level's domain names of the .example1 and .example2.

who can say that I can make these millions of different organizations to be provisioned in the same way?

Jiankang Yao

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 15 Aug 2010 22:45:32 -0400

I don't think anyone is proposing monitoring the domains to create
shadow domains at the registry level.

Making this work at the provisioning level means that the name holder
has to be responsible for maintaining consistency. But as I have
demonstrated, there is no way that the registry can effect this
mapping on its own without knowledge on the part of the name holder
and have the applications work.

Magic pointers are going to break HTTP and SMTP. They are also going
to break SSL. And there is absolutely no way to fix that.

Application servers all have to support multiple domains these days.
The application has to know which domain the email is being sent to or
the HTTP request is being directed at.

If we are going to have an application client side fix-up then it is
only going to be supported by the limited number of applications that
are fixup enabled. We certainly do not want recursive resolvers to be
automatically following the pointers on behalf of the DNS client as
that is going to cause the application to break.

There are precisely two ways that work here. Either we have advisory
pointers that are only used by applications that know about them, or
there are sites who provision out multiple shadow trees through some
form of automated means.

2010/8/15 YAO Jiankang <[email-masked]>:
> the registry has enough powers and resources to scan and monitor these
> domain names: a.example1 and a.example2,  the registry can force the
> registrants to
> if there are domain names: a.a.a.a.a.example1 and a.a.a.a.a.example2, how do
> the registry of example1 and example2 know and monitor these domain names
> a.a.a.a.a.example1 and a.a.a.a.a.example2.
>
> the registry may not know how many domain names in the zones of
> a.a.a.a.a.example1 and a.a.a.a.a.example2.
>

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

---

From: Brian Dickson <[email-masked]>
Date: Sun, 15 Aug 2010 23:53:19 -0300

2010/8/15 YAO Jiankang <[email-masked]>

> not get provisions in the same way.

While it might not be possible to know the intentions of every registry, I
would expect the common goal for registries is as follows:
- If example1 and example2 are TLDs and IDN equivalents, they are operated
intentionally "as one"
- if a.example1 is registered, a.example2 is at a minimum reserved
exclusively for the registrant of a.example1
- the registry will want to provide ways for a.example1 to have both
a.example1 and a.example2 be "the same", as easily as possible
- the registry might choose to mirror example1 as example2 "blindly"
(although I expect ICANN would frown on this implementation method)
- the registry might offer "blind" mirroring of individual registrant
delegations, so a.example2 is a "blind mirror" of a.example1 (e.g. xNAME)

I believe the registries have no intent or interest in "policing" the
sameness of a.example1 and a.example2, except so far as to ensure that both
are genuinely operated by the registrant, i.e. not hijacked.

However, making it feasible/possible/easy for registrants to have multiple
parallel identical "trees", or even label-by-label IDN-equivalence within
trees, is in everyone's interest, in the sphere of IDNs.

It doesn't solve all the problems, but it does address one of the problems.

> if there are domain names: a.a.a.a.a.example1 and a.a.a.a.a.example2, how
> do the registry of example1 and example2 know and monitor these domain names
If you want them to have them provisioned the same way, and they also want
this, then providing tools and training is the advisable way.

Opt-in works wonders, especially if the path for opting in is relatively
painless, and there are many sharing the journey.
Community forums and user groups always achieve more locally, than the best
laid plans of the IETF.

Brian

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 16 Aug 2010 07:36:11 +0200

> to break SSL. And there is absolutely no way to fix that.

It doesn't have to. It all depends on whether the application do "see" the pointer or not.

Ted Hardie suggested something that I almost missed in this discussion, so I went offline asking him about it. I completely agree with his finding.

If the application do see the "magic alias", then the application also do know what the canonical version of the domain name is. And the application can in the further processing use that canonical name for the processing. For example the HOST header in the HTTP protocol.

Say we have:

A1.example. IN A 1.2.3.4
A2.example. IN xNAME A1.example.
A3.example. IN xNAME A1.example.
A4.example. IN xNAME A1.example.

Then we can say that application _MUST_ get to see the xNAME record, and then use A1.example in the various protocols.

   Patrik

---

From: Alex Bligh <[email-masked]>
Date: Mon, 16 Aug 2010 07:19:17 +0100

--On 16 August 2010 10:13:31 +0800 YAO Jiankang <[email-masked]> wrote:

> do the registry of example1 and example2 know and monitor these domain
> names a.a.a.a.a.example1 and a.a.a.a.a.example2.

If the end objective is to make the DNS trees equivalent, anything other
than an xNAME type thing will fail.

If the end objective is to make all names work equivalently, even this
will fail (virtual hosts being a trivial example).

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Mon, 16 Aug 2010 07:53:24 +0100

> will fail (virtual hosts being a trivial example).

In fact Yao Jiankang actually hits the nail on the head.

With a solution that mirrors a whole part of the tree, the registrant
CANNOT put a deviating record in (unless we generate some sort of
mirroring by exception) which means for many applications at least
one equivalent name can't work. Thing about my bank example to Paul.

With a solution that relies on manual provisioning, the registrant
can take advantage of this, and put in two different records so
as to support these applications. Of course they can also do
other stuff ICANN didn't intend.

I draw two conclusions from this:

1. The goals of having DNS work identically across two equivalent names
   and having applications work identically are irreconcilable and
   to a certain extent incompatible. As this is reasonably subtle,
   I wonder whether ICANN realised this, and which objective they had.

2. Enforcing equivalence "all the way down the tree" is an example of
   overrelying on technology to implement a policy solution. This could
   be better handled by the registry provisioning copy zones, then
   putting whatever policy rules are desirable into Ts & Cs.

I suspect XNAME deployment will only encourage unpleasant hacks (e.g.
hacking the resolver to detect and XNAME in the chain and if so try a
modified version of the leftmost label to try to get SSL etc. to work on
both).

I am becoming convinced XNAME is not the answer (at least to ICANN's
problem and registry deployment - it may be useful for mirroring small
bits of tree, but probably not worth the resultant protocol entropy).
That leaves us with advisory pointers, and the theoretical possibility
of "mirror with exceptions".

-- 
Alex Bligh

---

From: Florian Weimer <[email-masked]>
Date: Mon, 16 Aug 2010 07:44:42 +0000

* Alex Bligh:

> one equivalent name can't work.

Yes, this is yet another reason why it's difficult to produce correct
zone content with xNAME.  How many more do we need before these
proposals can be discarded as non-workable?

> of "mirror with exceptions".

IDNA has to work for email, which means that the A might not have
access toe DNS, so DNS-based signalling will not work universally.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

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

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Alex Bligh" <[email-masked]>; "YAO Jiankang" <[email-masked]>; <[email-masked]>
Cc: "YAO Jiankang" <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Monday, August 16, 2010 2:53 PM
Subject: Re: [dnsext] why provisions fail in alias domain names?

snips...
> modified version of the leftmost label to try to get SSL etc. to work on
cname or dname is also a kind of XNAME.

do you mean that cname or dname encourage unpleasant hacks?

> bits of tree, but probably not worth the resultant protocol entropy).

icann needs the mirror of all tree down.

if you need to deviate it, you can do it in the provision way.

for the www.vip.bank.com.colour and www.vip.bank.com.color ,

do you wish to get the same resolution or deviate it to get the different dns resolution and confuse the users to get the possible phishing?

---

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

---

From: Alex Bligh <[email-masked]>
Date: Mon, 16 Aug 2010 10:25:28 +0100

> do you mean that cname or dname encourage unpleasant hacks?

If they were used to mirror whole branches of tree from the
registry downwards, yes.

> icann needs the mirror of all tree down.

My question is whether ICANN wants the functionality or the
data to be mirrored. If the latter, I suspect that is only
because they wrongly think it implies the former.

> for the www.vip.bank.com.colour and www.vip.bank.com.color ,

You cannot do that if someone has done
	$ORIGIN.
	colour.		IN	XNAME	color.

That is my point.

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Mon, 16 Aug 2010 10:28:04 +0100

--On 16 August 2010 17:21:15 +0800 YAO Jiankang <[email-masked]> wrote:

> do you wish to get the same resolution or deviate it to get the different
> dns resolution and confuse the users to get the possible phishing?

I don't want to get the same resolution, I want the registrant to get
a working service.

Whatever risk of phishing there is can be eliminated by a registry
policy saying only the registrant of 'foo.color' can register
'foo.colour', or, a fortiori, ensuring that the NS and glue records
for foo.colour always match those of foo.color. IE just copy the zonefile.

Confusion is GREATER with an XNAME as people will inevitably receive
invalid certificates (e.g. if they run Windows XP, run IIS, etc. etc.)

Saying the manual provisioning hack encourages phishing and confusion
is just handwaving unless you explain why.

-- 
Alex Bligh

---

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 16 Aug 2010 17:36:52 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "YAO Jiankang" <[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Monday, August 16, 2010 5:25 PM
Subject: Re: [dnsext] why provisions fail in alias domain names?

> because they wrongly think it implies the former.

icann only manages the top level domain, not the second or the third.
they want the second and the third to be resolved in the same way,
so function is not ok for them.

> You cannot do that if someone has done

that is why xname solve the concern of icann.

they do not like to deviate it for these 2 domain names.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 16 Aug 2010 10:46:23 +0100

> so function is not ok for them.
...
> they do not like to deviate it for these 2 domain names.

If that is ICANN's concern, which I have my doubts about for
the reasons above, then it is a concern which should not be
addressed by a DNS protocol change of the XNAME type,
because it would require a great deal of effort to produce
an undesirable outcome. If registries want to come to
agreements with ICANN to do broken stuff, that's fine by
me, but we should not be facilitating that with protocol
changes at the expense of everyone else.

Note that personally I would be incredibly surprised if
ICANN was consciously migrated something this broken
(i.e. they may not have realised it /harms/ using
equivalence at the application layer).

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Mon, 16 Aug 2010 10:51:41 +0100

--On 16 August 2010 10:46:23 +0100 Alex Bligh <[email-masked]> wrote:

> ICANN was consciously *mandating* something this broken

(typo fixed)

-- 
Alex Bligh

---

From: Tony Finch <[email-masked]>
Date: Mon, 16 Aug 2010 12:07:53 +0100

On Mon, 16 Aug 2010, Patrik Fältström wrote:
>
> If the application do see the "magic alias", then the application also
> do know what the canonical version of the domain name is. And the
> application can in the further processing use that canonical name for
> the processing.

That is insecure. The TLS certificate MUST match the domain name that
the user typed in otherwise the user is open to spoofing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
WIGHT PORTLAND PLYMOUTH: NORTHWEST BACKING WEST OR SOUTHWEST 4 OR 5,
OCCASIONALLY 6 EXCEPT IN PORTLAND, DECREASING 3 AT TIMES IN PLYMOUTH. SLIGHT
OR MODERATE. RAIN LATER. MODERATE OR GOOD.

---

From: Tony Finch <[email-masked]>
Date: Mon, 16 Aug 2010 12:25:05 +0100

On Mon, 16 Aug 2010, Alex Bligh wrote:
>
>  The goals of having DNS work identically across two equivalent names
>   to a certain extent incompatible.

In some cases you don't want applications to work identially for
equivalent names. For HTTP, it is better to redirect non-cacnonical URLs
to their canonical equivalents, to avoid wasting cache space, to avoid
cookie mismatches, to keep links and bookmarks consistent, etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER: NORTHWEST, BACKING WEST OR SOUTHWEST, 5 TO 7,
OCCASIONALLY GALE 8 AT FIRST EXCEPT HUMBER. MODERATE OR ROUGH. OCCASIONAL
RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.

---

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

----- Original Message ----- 
From: "Tony Finch" <[email-masked]>
To: "Alex Bligh" <[email-masked]>
Cc: "YAO Jiankang" <[email-masked]>; <[email-masked]>
Sent: Monday, August 16, 2010 7:25 PM
Subject: Re: [dnsext] why provisions fail in alias domain names?

> cookie mismatches, to keep links and bookmarks consistent, etc.

that may be true.
but from the registry's view or icann's view,
registry sells the names within a package. so they hope them to get the same identical dns resolution.

if we think that we can resolve these names in different ways, we may do nothing.
but some registries or icann or users need some domain names to be resolved in the same way.
we need do something for them.

another reason is that we will reduce the confusion if we resolve the names in equivalent to the same identical resolution.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Aug 2010 14:31:29 -0400

By 'magic pointer', I mean fixing everything up in the DNS so the
packets get routed to the right IP address regardless of whether the
application knows how to follow these pointers.

If we are not going to have magic fixup in the core of the DNS
protocol then the problem is really very easy. You put pointers in the
DNS for apps that can follow them and place the whole responsibility
for managing this problem where it belongs - at the endpoint.

If people try to put magic fixup in the DNS core that is going to
cause existing applications to break then its game over. This working
group will never converge and nor will the result be accepted by the
wider IETF.

This is a problem that actually does calls out for an end-to-end
solution. I am not a fan of end-to-end absolutism. I think you put the
complexity where it makes most sense. But in this case there is no
solution unless the endpoints are modified to make use of it.
Therefore there is no justification for a middlebox type approach,
much as I like those in many cases.

As you point out, application side fixup does work. I would suggest
though that your example works best if the XNames are understood to be
the second class citizens they are. Applications should translate
xnames before placing the names in address books or in URLs. Otherwise
the links are going to break when they are used by a non-capable
application.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Aug 2010 15:08:46 -0400

No hat.

> the links are going to break when they are used by a non-capable

A few comments about this:

1.  What does an application that happens to be offline or not really
a network client (think "URL highlighting in a word processor", for
instance) do about this?

2.  If you're going to normalize to the canonical name, don't you need
some way of knowing that you've normalized?  In the context of the IDN
use case (the only one we've really been exploring), a significant
part of the point is to display in a way that is natural to the user,
even if that isn't the "real" domain name.  So now we need a way to go
"back".

3.  If we need a way to go "back", don't we need a way to tell that
there _is_ a "back"?  That is, is it necessary to invent the "AKA"
RRTYPE (or something like that) so that in the canonical zone you can
indicate what other names are good and valid pointers to the zone (and
which are "unauthorized")?

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Aug 2010 20:49:45 -0400

> a network client (think "URL highlighting in a word processor", for

Same thing it does with every other URL that it is unable to check -
accept it as specified.

If people are going to put documents online they generally have to
perform a link check if the links are to be expected to work.

> even if that isn't the "real" domain name.  So now we need a way to go

Well HTML has that issue sorted already. The hyperlink destination is
specified by the href attribute of the <a> tag. Any text shown to the
user need not correspond to the actual link.

We may well have an ongoing requirement for such programs to actually
store both forms if they are going to be really be able to work as
expected in every case.

> which are "unauthorized")?

That might be desirable or it might be necessary.

Clearly the more that this is automated, the more that type of link
becomes a necessity.

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Aug 2010 14:24:27 +0100

> for managing this problem where it belongs - at the endpoint.

If you do that it'll never be deployable.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL: SOUTHWEST BECOMING CYCLONIC, 5 TO 7. MODERATE OR ROUGH. SHOWERS.
GOOD.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Aug 2010 11:58:32 -0400

Quite probably.

But you can't deploy in the DNS core without breaking existing
applications. And that is both undeployable and unacceptable.

I don't see why people who use I18N apps and want I18N domains would
not switch to applications that are aware. I think that you are going
to get a respectable amount of deployment over a realistic time-frame.

Magic pointers are not going to solve this problem for people without
upgraded apps, instead they will cause existing apps to be unable to
connect to the I18N sites for reasons that are not explainable.

---

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

> applications. And that is both undeployable and unacceptable.

The BNAME proposal (like DNAME) synthesizes CNAMEs for backwards
compatibility with existing code. Configuration for each new name is
still required in each application server. What you propose requires new
code for every application client, which is MUCH more difficult than a
server-side configuration tweak.

> to get a respectable amount of deployment over a realistic time-frame.

That's a reasonable counter-argument :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH UTSIRE: NORTHEASTERLY 5 TO 7, PERHAPS GALE 8 LATER. SLIGHT OR MODERATE,
OCCASIONALLY ROUGH IN SOUTH. OCCASIONAL RAIN. GOOD, OCCASIONALLY POOR.

---

From: "Yao Jiankang" <[email-masked]>
Date: Wed, 18 Aug 2010 20:53:08 +0800

----- Original Message ----- 
From: "Tony Finch" <[email-masked]>
To: "Phillip Hallam-Baker" <[email-masked]>
Cc: "Patrik Fältström" <[email-masked]>; "YAO Jiankang" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 18, 2010 6:30 PM
Subject: Re: [dnsext] why provisions fail in alias domain names?

> server-side configuration tweak.

what do you mean for " What you propose requires new
code for every application client"?

does your application client refer to the applicaions such as IE browser or firefox browser?
do you mean that the IE browser or firefox browser has to change its running code to support bname?

my understanding is that only server configuration is needed to support bname.

the application client such as the IE browser or firefox browser does not need updating.

for example, if google.com and and google.example are configure to the same IP address.

the IE browser or firefox browser just follow the same IP address to connect the website.
the google website administrator may do some configuration for their http servers.
the application server configuration is transparent to the application client.

BTW, all the major browsers have all already supported IDN.
whether the browser support IDN or not is not bname issue, but IDN issue.

Jiankang Yao

---

From: Tony Finch <[email-masked]>
Date: Wed, 18 Aug 2010 16:47:30 +0100

> code for every application client"?

I meant the non-BNAME "see other" proposal that Phill has been talking
about.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: NORTHEASTERLY 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER IN
NORTH. ROUGH, BECOMING VERY ROUGH. OCCASIONAL RAIN. MODERATE OR POOR.