Subject: [dnsext] application issues for the alias names

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

there two alias names: alias1.example and alias2.example.
there two different names: test.example and different.exmaple.test.

if we configure these names below:

alias1.example xname alias2.example
alias2.exmaple A 192.168.1.1

test.example A 192.168.1.1
different.exmaple.test A 192.168.1.1

after the dns lookup,

the application will get:

alias1.example  A 192.168.1.1
alias2.exmaple A 192.168.1.1

test.example A 192.168.1.1
different.exmaple.test A 192.168.1.1

if one company has two domain names, different.exmaple.test  and test.example ,
they may configure it to get the same dns resoluion via provision.

one company may process the alias names through the xname way.

finally,

they get the address 192.168.1.1.

is there any difference between these names to their final results except MX problems and different dns lookup procedure?

if the final results are same, so the application configuration is same for provisional way and xname way.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 16 Aug 2010 16:47:42 +0100

> for provisional way and xname way.

If I understand your example, you have shown that it is always possible to
configure "the provisioning hack" to produce the same result as XNAME.
You have not shown the converse (i.e. how XNAME can produce 192.168.1.1
for one query and 192.168.1.2 for the other, like 2 A records can).

-- 
Alex Bligh

---

From: "Jiankang YAO" <[email-masked]>
Date: Tue, 17 Aug 2010 10:37:23 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; <[email-masked]>
Cc: "Alex Bligh" <[email-masked]>
Sent: Monday, August 16, 2010 11:47 PM
Subject: Re: [dnsext] application issues for the alias names 

> configure "the provisioning hack" to produce the same result as XNAME.

what i mean is that if there are problems for xname in application, there are also some problems for provisions in applicatons.
the applications issues are for both provisions and xname ways.

> for one query and 192.168.1.2 for the other, like 2 A records can).

xname is trying to mirror the whole tree, not deviate it.

if we want to deviate it, the current provision is ok.

Jiankang Yao

---

From: John Levine <[email-masked]>
Date: 17 Aug 2010 17:51:39 -0000

>what i mean is that if there are problems for xname in application,
>there are also some problems for provisions in applicatons.  the
>applications issues are for both provisions and xname ways.

It is certainly possible for people to misconfigure applications, no
matter what's in the DNS.  Also, again no matter what is in the DNS,
there will be application-specific provisioning rules.  To use a
popular example, if all of the web sites under a domain use HTTP, the
alias A records all resolve to the same address, but if some use
HTTPS, the alias A records need to resolve to different addresses.

Successful i18n will always need some manual or locally scripted
provisioning.  My position has always been that xNAME does not avoid
enough of the manual or scripted work to be worth its cost.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 Aug 2010 09:57:24 +1000

> HTTPS, the alias A records need to resolve to different addresses.

Or you need to use the correct types of cert or you need to add SRV
support or ...
 
> enough of the manual or scripted work to be worth its cost.

Reducing part of the work load is always useful.  xNAME by itself is
useful.  xNAME is not a magic bullet but it is part of the solution.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R. Levine" <[email-masked]>
Date: 18 Aug 2010 20:55:40 -0400

> Reducing part of the work load is always useful.

Agreed, but it's important to keep in mind the overall costs of proposed 
changes when deciding whether we're actually reducing the workload.

> xNAME by itself is useful.

Maybe, but we have yet to see whether its utility is worth the cost of 
changing a zillion pieces of depoyed software to support it.

>  xNAME is not a magic bullet

Definitely

> but it is part of the solution.

Maybe, maybe not.

R's,
John