Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

From: Alex Bligh <[email-masked]>
Date: Wed, 01 Sep 2010 08:07:56 +0100

--On 1 September 2010 14:53:50 +0800 Jiankang YAO <[email-masked]> wrote:

> "want the same DNS result "  fall in the scope of this wg.
>
>  does "applications to perform the same" fall in this wg?

Of course, if implemented through DNS. We currently have lots of DNS RRs
that do not always return the same DNS result across zones, or allow for
exceptions, or indirection. CNAME is a good example; is that outside the
scope of this w/g?

One example might be XNAME with exceptions. Another might be the null
hypothesis (i.e. best for us to do nothing and leave it to the
applicatin layer). In either case, these are valid conclusions for the w/g
to reach.

-- 
Alex Bligh

---

From: "Jiankang YAO" <[email-masked]>
Date: Wed, 1 Sep 2010 15:49:43 +0800

----- Original Message ----- 
From: "Alex Bligh" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; "Paul Hoffman" <[email-masked]>
Cc: <[email-masked]>; "Alex Bligh" <[email-masked]>
Sent: Wednesday, September 01, 2010 3:07 PM
Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

> exceptions, or indirection. CNAME is a good example; is that outside the

if you refer to CNAME,
dns doing the same is different from the applicaiton doing the same.
for example :
a.example cname a.test; 
a.test A 192.168.1.1;

you put the link in the browsers:
http://a.example 
http://a.test  

although a.example and a.test get the same dns result via CNAME,
the webservers (apache servers) can still  make these two domain names to totoally different websites.
such as http://a.example  which points to the travel-agency web; 
http://a.test  which points to the IT company web.

Jiankang Yao

---

From: Alex Bligh <[email-masked]>
Date: Wed, 01 Sep 2010 08:57:37 +0100

> dns doing the same is different from the applicaiton doing the same.

I mean if you clone an entire zone using CNAMEs, you can put in
exceptions.

-- 
Alex Bligh

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Sep 2010 11:05:41 -0400

No hat.

On Wed, Sep 01, 2010 at 11:33:40AM +0800, Cindy Wang wrote:
> 
> 8. Since identical resolution is needed definitely by the IDN users NOW and, more or less needed by others in the future.
> 
> And, identical resolution should happen at both the nodes and their sub-trees, which couldn't be achieved by provision anyway. Am i right?

This is one of the claims that I tried to clarify in my message
yesterday.  Perhaps I'll try once more.

The above position assumes a particular policy: that a given mapping
of "identical resolution" for two labels is transitive down a tree.
More formally, for any A and for any B, if A=B then A.A=B.A=A.B=B.B,
and also A.A.A=B.A.A=B.B.A (and so on).  I'm setting aside the issue,
already noted elsewhere in this discussion, that the "equality"
relationship there is so far poorly defined (because it's certainly
not necessarily true for all queriers at any given point in time,
given the way caches work).  So I'll keep the scare-quotes around
"identical resolution".

This is a particular policy for a zone operator -- one that may be
implicit in the agreement to delegate one name space on the
understanding that certain rules govern delegations that are allowed
beneath it.  The claim under consideration is that we need in-protocol
support for that policy, and that some or all of the proposals we've
heard are sufficient for that support.

Now, let me present the argument why, even if you think the policy is
a reasonable one, nether BNAME nor SHADOW nor the two together
(whatever that would be) are perhaps not sufficient.  We will leave
caches out of the situation for now.  Note that this outline doesn't
mean I do or do not accept this argument.  I'm just trying to make the
alternatives clear.

If one does this "identical resolution" entirely with provisioning,
then it is necessary to monitor two zones to ensure they are in sync,
and then to monitor all the combined delegations beneath them all the
way down the tree for such syncing too.  The only practical ways to do
such monitoring is to wait for reports of bad behaviour, to scan
randomly, or to require zone transfers to a central point all the way
down the various trees, which one then audits.  Only the latter has a
hope of catching everything.  This is clearly an expensive and
difficult task.

To do this with BNAME, SHADOW, or both, you have to monitor but one
tree of zones.  But, you must nevertheless do this the same way, and
ensure that for every case there is in fact the required BNAME or
SHADOW entry.  Moreover, since those RRTYPES aren't specified yet, you
will need to audit the software that everyone is running in order to
be sure that the software they run actually provides the necessary
support for the implementation of this "identical resolution".
Monitoring the software deployed in someone else's infrastructure is
actually harder than getting zone transfers, so it might be that
effectively monitoring this approach is harder than just comparing a
large number of zone files.

And of course, in both cases this monitoring is only retrospective: it
catches a state of affairs that obtained at the time one performed the
zone transfer.  Exception handling will be hard no matter what, and
the user experience is broken as long as someone has done something
wrong.  Generating a zone file with a different $ORIGIN at the top is
a well-understood problem and easy with a database.  Administering new
RRTYPES like SHADOW and BNAME may not be, and so those innovations may
actually cause a worse user experience.

This suggests (and I think it was John Klensin who observed this at
the mic in Maastricht) that the _real_ desire is to be able to map a
given set of Unicode code points (with a possible set size of 1) to a
different set of Unicode code points at the time of lookup.  Since DNS
labels don't have Unicode code points in them (and the Unicode code
points can't even conveniently be extracted from an A-label without
turning it back into a U-label first), there really isn't a way to do
this in the DNS.  And if all that is correct, then trying to solve
this problem with DNS tricks is attacking the problem at the wrong
level.  Instead, one should be working on a mechanism to communicate
zone policy to applications up at the level prior to where they do
their IDNA transformations, so that mapping can be performed at the
point where IDNA2008 envisions it will be performed.  And if that's
right, then we don't need new RRTYPEs, because they won't solve the
problem and they'll cause perturbation to the DNS protocol without
achieving the hoped-for benefit.

Again, I wish to emphasise that I do not express an evaluation of this
argument one way or the other.  But that's what I think the argument
is.  And this is one example of why I think it is critical that we get
the requirements and current state survey (as others have also
suggested) done as a first step.

Best,

A

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

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 1 Sep 2010 08:39:03 -0700

> achieving the hoped-for benefit.

A stupid question then:  Might this suggest the need for a "canonicalization" DNS RRTYPE?  

IDNA needs to find out canonicalization information somehow for nameprep in this model, which is specific to a target domain, and thus it seems to me that this really IS information that should be stored in DNS.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Sep 2010 11:49:54 -0400

On Wed, Sep 01, 2010 at 08:39:03AM -0700, Nicholas Weaver wrote:

> IDNA needs to find out canonicalization information somehow for nameprep in this model,

No, it doesn't.  IDNA2008 doesn't use nameprep.

But if what you meant was, "Prior to converting a U-label, an IDNA2008
client needs to do some local mapping, and it needs to find out what
to do somehow," that might be right.  I can't imagine how one could
store such general policy statements in the DNS, however.

What such policy statements amount to are hints to applications about
what is "reasonable" in the context, to use the word from RFC 5894:

   In principle, an application ought to take user input of a domain
   name and convert it to the set of Unicode code points that represent
   the domain name the user intends.  As a practical matter, of course,
   determining user intent is a tricky business, so an application needs
   to choose a reasonable mapping from user input.  That may differ
   based on the particular circumstances of a user, depending on locale,
   language, type of input method, etc.  It is up to the application to
   make a reasonable choice.

One _might_ argue that what one needs is some kind of policy-server RR
or SRV/NAPTR/whathaveyou convention that would allow clients to look
up policies that apply to the name.  I'd worry very much about the
potential for tree-climbing here, however.

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Sep 2010 09:21:02 -0700

>IDNA needs to find out canonicalization information somehow for nameprep in this model, which is specific to a target domain, and thus it seems to me that this really IS information that should be s…

As Andrew said: this is no longer needed. I don't think it ever was, given the deterministic way IDNA2003 rules worked, but it had been discussed in the IDN WG before IDNA2003 was finished, and the idea was rejected.

--Paul Hoffman, Director
--VPN Consortium

---

From: Douglas Otis <[email-masked]>
Date: Wed, 01 Sep 2010 14:18:44 -0700

> And, identical resolution should happen at both the nodes and their sub-trees, which couldn't be achieved by provision anyway. Am i right?
Perhaps a better way of stating the problem would be to say:

The IDN issue illustrates resolving the same resource from two different 
domains needs better facilitation.

While aliasing a name can be done unilaterally, referenced resources 
often need to know their canonical name.  When there are simultaneous 
names cooperatively provisioned by different parent domains and 
synchronized in parallel to resolve the same set of resources, often 
these referenced resources expect to have a primary name.  It seems 
possible to develop a resource that reports the primary or amber name 
based upon a shadow zone's meta information.  A bname approach would 
need to dynamically or perhaps statically generate these resources to 
relate initial names to the aliased name before determining a "primary" 
name becomes practical.  Perhaps both schemes could utilize the same 
resource to indicate a "primary" name.

In addition, some protocols prohibit use of aliased names as being the 
target of an MX, SRV, or PTR record, for example.  This precludes use of 
aliased names in these targets (names below a bname).  Perhaps SRV 
resource records could indicate "primary" names that can be used in the 
service's configuration.  There would be less of a chance for conflicts 
to occur by defining a new type of PTR record for this purpose.

The bname approach replaces the work of simultaneous synchronization for 
a large domain (moving from amber to shadows) into additional 
transactions handled by the DNS protocol.  While this approach provides 
a means to unilaterally specify new synthetic domains,  the roots and 
registrar domains must then cooperatively arbitrate bnames publication 
at  these levels.  Clearly, any aliasing is possible when done below the 
controlling parent.  bnames will make such efforts easier when done 
within the controlling parent domain without necessitating cooperation 
between parent domains.  As such, it seems both shadow and bname can 
help facilitate different aspects resolving the same resources from 
different names.  In any case, it would be wrong to describe these names 
as being identical.  Stop using that term.

-Doug

---

From: Paul Vixie <[email-masked]>
Date: Thu, 02 Sep 2010 04:12:23 +0000

i really like this characterization, fwiw.

re:

> Date: Wed, 01 Sep 2010 14:18:44 -0700
> From: Douglas Otis <[email-masked]>
> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
> To: Cindy Wang <[email-masked]>
> CC: Jiankang YAO <[email-masked]>, Andrew Sullivan <[email-masked]>, 
>  "[email-masked]" <[email-masked]>
> Subject: [dnsext] Re: A next step?
> Sender: [email-masked]
> 
> While aliasing a name can be done unilaterally, referenced resources often
> need to know their canonical name.  When there are simultaneous names
> cooperatively provisioned by different parent domains and synchronized in
> parallel to resolve the same set of resources, often these referenced
> resources expect to have a primary name.  It seems possible to develop a
> resource that reports the primary or amber name based upon a shadow zone's
> meta information.  A bname approach would need to dynamically or perhaps
> statically generate these resources to relate initial names to the aliased
> name before determining a "primary" name becomes practical.  Perhaps both
> schemes could utilize the same resource to indicate a "primary" name.
> 
> aliased names in these targets (names below a bname).  Perhaps SRV resource
> records could indicate "primary" names that can be used in the service's
> configuration.  There would be less of a chance for conflicts to occur by
> defining a new type of PTR record for this purpose.
> 
> The bname approach replaces the work of simultaneous synchronization for a
> large domain (moving from amber to shadows) into additional transactions
> handled by the DNS protocol.  While this approach provides a means to
> unilaterally specify new synthetic domains,  the roots and registrar
> domains must then cooperatively arbitrate bnames publication at  these
> levels.  Clearly, any aliasing is possible when done below the controlling
> parent.  bnames will make such efforts easier when done within the
> controlling parent domain without necessitating cooperation between parent
> domains.  As such, it seems both shadow and bname can help facilitate
> different aspects resolving the same resources from different names.  In
> any case, it would be wrong to describe these names as being identical.
> Stop using that term.
> 
> -Doug
> 
> 
>

---

From: Niall O'Reilly <[email-masked]>
Date: Fri, 03 Sep 2010 12:03:56 +0100

This seemed as good a place to jump in after a few weeks'
	break as any.

On 30/08/10 09:44, Stephane Bortzmeyer wrote:
> On Mon, Aug 30, 2010 at 10:30:04AM +0800,
>   Jiankang YAO<[email-masked]>  wrote
>   a message of 70 lines which said:
>
>>   the dns root has the IDN TLDs and there will have thousands of IDN
>>   TLDs in the future. The number of IDN TLDs will be larger than the
>>   ASCII IDN TLDs in the future.
>
> I don't see the point. I'm a big fan of IDN, I agree that we will have
> one day more IDN TLDs than ASCII TLD but so what? What's the
> connection with the whole discussion about "synchronous domains" and
> the possible solutions (xNAME, SHADOW, etc)?

	IDN is a distraction.
	Projecting particular registry requirements, which happen
	to involve both IDN and synchronization, onto the entire
	potential IDN space doesn't help Yao's argument.

	A propos distractions, looking for clarity as to "ICANN's
	requirements" is something I see as a distraction too.
	ICANN has, AFAICS, neatly delegated (baggage intended!)
	the problem to the TLD registries involved in rolling out
	IDN TLDs.  Each such registry will have its own distinct
	problem space, undoubtedly overlapping to some extent with
	that of other such registries.

> Unless you claim that *every* IDN TLD require synchronization of
> content (something that not everyone will agree with) *and* that this
> synchronization requires a non-provisioning method to be done,
> something that you often repeat but which is not true.

	Absolutely, in so far as this is a rebuttal of IDN as
	a justification for synchronization.  If you mean that
	provisioning is all that is needed for every kind of
	domain synchronization problem, then I disagree.

> Please provide hard facts, not just hand-waving about IDN. We can
> deploy IDN (actually, it is already done) without xNAME.

	Alex Bligh explained the trouble with scaling a
	provisioning-only approach more clearly than anyone
	who tried to do so before. See
	http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg02150.html

	Alex also pointed out 
(http://www.ops.ietf.org/lists/namedroppers/namedroppers.2010/msg02148.html)
	that the scale of a provisioning-only
	solution grows with distance from the root.  Unfortunately,
	the level of clue on the part of zone administrators mostly
	diminishes with this distance.

	I think these are the points which would better support
	Yao's argument.

> Domain synchronization is not an IDN issue.

	That would make a fine signature text for future mailings
	on this and related threads!

> (I would like to have
> bortzmeyer.fr and bortzmeyer.org synchronized, even if they are ASCII
> names.)

	I prefer Vixie's example, as it involves names differing
	by label-count.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Sep 2010 09:01:08 +0200

On Wed, Sep 01, 2010 at 11:33:40AM +0800,
 Cindy Wang <[email-masked]> wrote 
 a message of 9 lines which said:

> 8. Since identical resolution is needed definitely by the IDN users
> NOW 

This is often repeated and never proved. I seriously doubt it.

> And, identical resolution should happen at both the nodes and their
> sub-trees, which couldn't be achieved by provision anyway. Am i
> right?

Wrong. This is possible by provisioning, just write it down in the
registration rules (and then enforce these rules, like any other
policy rules). Remember that not everything in the world work
according to IETF standards, there are other sources of rules!

One of the reasons I'm highly skeptical about the often-repeated "IDN
require xNAME" sentence is that a consistent user experience between
two "identical" IDN TLDs (such as .CN in traditional and simplified
characters) may very well *require* a different resolution. 

For instance, if you prefer that one TLD, with traditional character,
use only traditional characters for every label (and a similar rule
for the TLD with simplified characters), then you *need* a different
resolution (which rules out xNAME).

---

From: Florian Weimer <[email-masked]>
Date: Mon, 06 Sep 2010 13:25:49 +0000

* David Conrad:

> Andrew,
>
> On Aug 30, 2010, at 3:42 PM, Andrew Sullivan wrote:
>> Where exactly is ICANN's problem statement?  As one of the chairs who needs to agree to herd this work through the IETF, I'd like to see it.
>
> An understandable request.  While not "ICANN's problem statement", I
> gather you do not believe
> http://tools.ietf.org/html/draft-yao-dnsext-identical-resolution-00
> is sufficient?

I don't think it is.  It presupposes the need for sameness, without
giving a rationale.  The examples in section 2 are at such a low level
that I don't think their resolutions are actual objectives of the IDN
folks.

Here are several use cases which seem somewhat related to me:

  When a user enters a domain name in a web browser, she shall reach
  the intended web page.

  When a user enters an email address and sends mail to it, the
  message shall reach the intended destination mailbox.  It should not
  bounce or be rerouted to the wrong mailbox.

  When a user clicks on a link in mail message they have received, and
  the browser's URL bar shows a domain name which is familiar to them,
  the browser has in fact retrieved the displayed page from that
  familiar site.

  When a user clicks on a link, the browser shall display a correctly
  spelled domain name (provided that the web site owner has registered
  and uses such a domain name).

  When the user opens a mail message, the sender address shall contain
  the correctly spelled domain name, as provided by the sender.

  When a zone administrator puts the name of a name server in the NS
  RRset of a zone, and the name server serves the zone, it shall be
  possible to use the server in name resolution.

It would be great if ICANN provided an official list of issues we're
required to solve.  This can even be as restrictive as "make IDNAbis
work for the following cases", if redesigning IDNAbis is not on the
table.  But I think the WG needs to know what the actual problems
which are on ICANN's table.  Sameness in the DNS is not an end to
itself, and given the significant deployment costs, we should make
sure it actually matches the objectives.

It would also be good to know if ICANN is interested in similar
enhancements in user experience for ASCII-only domains in existing
TLDs (or the ASCII part of IDNs).

-- 
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: Douglas Otis <[email-masked]>
Date: Mon, 06 Sep 2010 14:32:33 -0700

On 9/6/10 6:25 AM, Florian Weimer wrote:
> >> Where exactly is ICANN's problem statement?  As one of the chairs
> >> who needs to agree to herd this work through the IETF, I'd like
> >> to see it.
> > An understandable request.  While not "ICANN's problem statement",
> > I gather you do not believe
>  giving a rationale.  The examples in section 2 are at such a low
>  level that I don't think their resolutions are actual objectives of
>  the IDN folks.

Would be be better to indicate there is need for features to better 
facilitate resolving resources from multiple domain names, as might be 
needed to support aliases for TLD and SLD zones?

>  When a user enters a domain name in a web browser, she shall reach

HTTP already supports unique responses for multiple domain names (from 
the same server and port).

>  When a user enters an email address and sends mail to it, the message
>  shall reach the intended destination mailbox.  It should not bounce
>  or be rerouted to the wrong mailbox.

Supporting a concept of "primary" name is needed for email, which was 
missed by Yao's draft.  This may not be the same as locating the 
ultimate target for a CNAME.  RFC1034 Section 3.6.2 second paragraph 
combines the term canonical and primary.  Section 5.2.1 item 2 indicates 
the IN-ADDR.ARPA returns a PTR to the "primary" name.  For example, 
SHADOW should automatically populate a forward resource that returns a 
"primary" name for each aliased domain.

>  the browser has in fact retrieved the displayed page from that

Already HTTP redirection does not satisfy this type of expectation.

>  and uses such a domain name).

Would it be okay to display the primary name for the domain instead?  
Otherwise, would multiple certificates be needed?

>  the correctly spelled domain name, as provided by the sender.

Does this imply a redirection to the primary name?

>  possible to use the server in name resolution.

How would this relate to resolving the same resource from multiple 
domain names?

>  sure it actually matches the objectives.

IMHO, work on what is needed to support protocols when the same resource 
is resolved by different domain names, where one of these names SHOULD 
be identifiable as representing the "primary" domain name.

>  TLDs (or the ASCII part of IDNs).

How would this relate to resolving the same resource from multiple 
domain names?

Would SHADOW or BNAME satisfy an aliasing for domains not easily 
achieved by CNAME or DNAME due to:
  1) CNAME not allowing other non-security resources to exist at the 
same node, and
  2) DNAME not aliasing the node that contains this resource?

-Doug

---

From: Tony Finch <[email-masked]>
Date: Mon, 6 Sep 2010 23:43:00 +0100

>> schemes could utilize the same resource to indicate a "primary" name.

I don't think BNAME needs an extra RR which says what the canonical name is, because BNAME itself says what the canonical name is. Think of CNAME-driven canonicalization in SMTP. If BNAME does CNAME synthesis like DNAME, then apps that do DNS-driven canonicalization can work with all three RRs.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 07 Sep 2010 08:22:20 +0900

Tony Finch wrote:

> I don't think BNAME needs an extra RR which says what the
> canonical name is, because BNAME itself says what the canonical
> name is. Think of CNAME-driven canonicalization in SMTP.
> If BNAME does CNAME synthesis like DNAME, then apps that do
> DNS-driven canonicalization can work with all three RRs.

The problem, then, is that (definitely not international) LDNs
have no internationally defined sameness such as case
insensitivities of ASCII characters.

That is, canonicalization differs at parent and child zones, which
makes it impossible to let parent zone perform canonicalization
to CNAMEs.

But, that is not the real problem yet.

That is, sameness highly depends on context. For example, in Japanese
official writing rules defined by government, many variants are
allowed for proper nouns but no variants are allowed for other cases.

If there were international canonicalization rules for all the local
characters, we could have been done (like case insensitivities).

If the rules were uniform in a country, ccTLD level canonicalization
is just fine. Note that names are, by any means, not international
but country local.

If the rules were uniform in a label, which ICANN is trying to
assume, large amount of protocol modifications, including but not
limited to DNS, could be used.

But the reality is that there is no uniformity of sameness even
in a label. The problem is highly human and not solvable by
protocols mechanically.

So, let ICANN pursue the impossible goal. Let ICANN use DNAME.
Parent zones can take care of equality of other RRs of DNAME
nodes.

						Masataka Ohta

---

From: Douglas Otis <[email-masked]>
Date: Mon, 06 Sep 2010 18:56:40 -0700

>>> often
> On 9/6/10 3:43 PM, Tony Finch wrote:
> I don't think BNAME needs an extra RR which says what the canonical 
> name is, because BNAME itself says what the canonical name is. Think 
> of CNAME-driven canonicalization in SMTP. If BNAME does CNAME 
> synthesis like DNAME, then apps that do DNS-driven canonicalization 
> can work with all three RRs.
An application may have difficulty determining how an alias is 
achieved.  In addition, it might not be the target of a CNAME offering 
the alias.  When DNAME or BNAME is understood, what reason is there to 
synthesize a 0 TTL CNAME?  How would an application determine whether to 
query for a BNAME, CNAME or DNAME, and how would a Shadow zone be 
handled?   Having a resource explicitly defined to return a "primary" 
domain better ensures applications are afforded fewer alternative methods.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Tue, 07 Sep 2010 12:49:16 +1000

In message <[email-masked]>, Douglas Otis writes:
> achieved.

DNAME/BNAME both return CNAME records.  Unless the application is DNAME /
BNAME aware it will see a CNAME.

> In addition, it might not be the target of a CNAME offering the alias.
> When DNAME or BNAME is understood, what reason is there to 
> synthesize a 0 TTL CNAME?

No.

> How would an application determine whether to 
> query for a BNAME, CNAME or DNAME,

The application doesn't need to qery for these types.  The servers
add these if they are part of the resolution process.  The application
just needs a api that records that cannonicalisation occured during the
lookup and to check for it (e.g. (struct addrinfo).ai_canonname).

A CNAME query is all that is required regardless of whether BNAME,
CNAME or DNAME is in use if the application wants to make a explict
query.

> and how would a Shadow zone be 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 07 Sep 2010 08:28:36 +0000

> From: Tony Finch <[email-masked]>
> Date: Mon, 6 Sep 2010 23:43:00 +0100
> 
> I don't think BNAME needs an extra RR which says what the canonical name
> is, because BNAME itself says what the canonical name is. Think of
> CNAME-driven canonicalization in SMTP. If BNAME does CNAME synthesis like
> DNAME, then apps that do DNS-driven canonicalization can work with all
> three RRs.

that's an initiator-side perspective.  certainly an initiator will know what
name it was originally attempting to use, and it will be aware of aliases.
(even if it's DNAME/BNAME aware and has to calculate them rather than being
informed by a TTL=0 synthetic CNAME.)

the backpointer that's under consideration would somehow inform the responder
of what names it might be indirectly answering for.  in Apache for example,
it's nec'y to tell the http server all "Host:" keywords could lead to a given
set of content.  right now, sysadmins edit all of that by hand.

note that a CNAME based approach would admit no revision adding backpointers;
a responder will never be able to get an authoritative set of aliases pointing
toward its own names, since CNAME is controlled by the aliaser.  however, a
set of PTR's present at www.vix.com telling my Apache about www.vixie.org and
vixie.sf.ca.us could be generally useful... even if nec'ily hand-maintained.

---

From: Tony Finch <[email-masked]>
Date: Tue, 7 Sep 2010 12:06:02 +0100

On 7 Sep 2010, at 02:56, Douglas Otis <[email-masked]> wrote:

>   How would an application determine whether to query for a BNAME, CNAME or DNAME, and how would a Shadow zone be handled?

Applications should never query for alias records directly. They should query for the RR they want and examine the reply to find out if the qname is an alias.

Apps can handle shadow zones dynamically. If they get a request for a domain they don't know about, they can look it up to see if it is an alias for a domain they do know about, and if so redirect to the target domain.

They need a way to prevent third parties from pointing unauthorized aliases at them, which could perhaps be done with an AKA RRset at the Amber zone apex (a bit like forward/reverse DNS consistency checking). AKA RRs need no special in-DNS handling.

Apps do not need this kind of special support for shadow zones: early deployment can work with existing virtual host support.

Tony.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 07 Sep 2010 06:09:51 -0700

On 9/7/10 1:28 AM, Paul Vixie wrote:
>> From: Tony Finch<[email-masked]>
> informed by a TTL=0 synthetic CNAME.).
Resolving the same resource from several names using methods like Shadow 
zones will not provide a primary name for applications to discover by 
tracking DNS protocol aliasing.  A specific resource could offer primary 
domain information not available by tracking the aliasing process.  
Requesting a specific resource holding the primary domain in the shadow 
domain would be the most direct discovery method.  When the information 
is defined as a resource record rather than a modification to some API, 
this should also help in keeping different DNS implementations more 
consistent.

The assertion of a shadow could be confirmed in the primary domain by 
resources at hash labels for the asserting domain, i.e. ####._amber.  
Expecting a single node within a primary domain to confirm the entire 
RRset of shadow PTR records would likely run into performance issues.  
Hash labels could resolve PTR records that reiterate the shadow domains.
> set of content.  right now, sysadmins edit all of that by hand.
Collecting the same set at a defined location such as _shadows within 
the primary domain could be a convention for where the entire set would 
be obtained.
> vixie.sf.ca.us could be generally useful... even if nec'ily hand-maintained.
It seems configurations needed to secure domains should depend upon 
automation as much as possible.  Automation becomes increasingly 
difficult when a solution is neglected at instantiation.  Offering 
reverse pointers at hash labels should help this scheme scale to 
reasonable limits and enhance security without depending upon tracing 
many possible levels of aliasing.  It seems DNS will need to become 
extremely agile in alias handling.  Having primary domain as a resource 
also seems to make the aliasing process more deterministic.

-Doug

---

From: Tony Finch <[email-masked]>
Date: Tue, 7 Sep 2010 17:17:44 +0100

On Tue, 7 Sep 2010, Paul Vixie wrote:
> Tony Finch <[email-masked]> wrote:
> >
> that's an initiator-side perspective.

I was actually thinking from the server point of view.

The rest of this is just agreeing with you at length :-)

> set of content.  right now, sysadmins edit all of that by hand.

Historical digression: There is some stuff in Apache to support dynamic
virtual server configuration - see mod_vhost_alias which I wrote about 12
years ago. At that point I was working on mass IP-based virtual hosting,
and the server was supposed to respond whatever hostname you addressed it
by - this was like traditional Apache IP-based virtual hosting but NOT
like the more careful control over permitted aliases that we are talking
about. To provision a site we just needed to link the user's filespace to
the right place in the filesystem (e.g. /www/212.69.213.230) where
mod_vhoat_alias was configured to find it, and configure the reverse DNS
so that Apache could dynamically configure the server's idea of its
canonical name, enabled with UseCanonicalName DNS.

Back to the current problem, re-using the idea of using the DNS for
autoconfiguration. I imagine that Apache could support dynamic server
aliases with a directive like ServerAlias DNS. This would make it handle
requests with unkown names in the Host: header looking up the name to see
if it is an alias, and if so verifying that there is a configured server
with the same canonical name, and if so look up the PTR RR set at the
canonical name to verify that the original host name is listed, and if so
handle the request - or otherwise reject it.

> however, a set of PTR's present at www.vix.com telling my Apache about
> www.vixie.org and vixie.sf.ca.us could be generally useful... even if
> nec'ily hand-maintained.

I like the idea of using PTR for this.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 Sep 2010 05:51:53 +0200

On 09/06/2010 09:01 AM, Stephane Bortzmeyer wrote:
>   Cindy Wang<[email-masked]>  wrote
I interpret this statement as saying that (if A is traditional and B is 
simplified) someone wants that:

- A.A.A should resolve
- B.B.B should resolve identically to A.A.A
- A.B.A and B.A.B should NOT resolve

(If that's not what you intended - holler.)

AFAIK, the existence of such a requirement has been specifically denied 
by people associated with the relevant authorities.

                     Harald

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Sep 2010 12:05:30 -0700

On Tue, Sep 7, 2010 at 8:51 PM, Harald Alvestrand <[email-masked]> wrote:
> AFAIK, the existence of such a requirement has been specifically denied by
> people associated with the relevant authorities.
>
>                    Harald

Just to clarify this, you are saying that point 3 has been specifically denied?

Speaking as a non-native user of these scripts, what I think is
desired is even a bit
more open.  Imagine label lengths of 3 characters each.  In some cases, you
would want aba.abb.aaa to match aaa.aaa.aaa and bbb.bbb.bbb.
Does this match your understanding?

Note that in this case the amount of work required to meet user expections
remains pretty high, even with the some way of declaring two labels equivalent
(for whatever value of equivalent we mean).  aaa.  and bbb. are equivalent
still has to be augmented with declarations that .abb.aaa and aba.aaa
and aaa.aaa are
equivalent and then declarations that .aba.aaa.aaa and abb.aaa.aaa and
bbb.aaa.aaa
are equivalent.  The inheritance helps a lot, but it requires new
equivalence declarations
at each level.  And, as has been noted before, which equivalence rules
map specific
characters to other characters are really national/script rules, not
algorithmic at the character
level alone.

Just my two cents,

regards,

Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 Sep 2010 22:25:17 +0200

On 09/08/10 21:05, Ted Hardie wrote:
> On Tue, Sep 7, 2010 at 8:51 PM, Harald Alvestrand<[email-masked]>  wrote:
>    
Yes.
> Does this match your understanding?
It's an use case where I have had specific response that "living without 
this is acceptable".
The first set of cases can easily arise when someone clicks on a partial 
URL and then types in a subdomain; the last case cannot arise so easily, 
I think.
> algorithmic at the character
Yep. aba.bab = bab.aaa is VERY expensive, whether it's done 
administratively or using a label-level mechanism. I think we all 
realize that.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 09 Sep 2010 08:15:25 +0900

> Does this match your understanding?

As for simplified/traditional Chinese characters, one can say only
aaa and bbb can occur. But in general use of sameness
all the eight patterns (aaa, aab, aba, abb, baa, bab, bba, bbb)
must be allowed.

> remains pretty high,

It means exponential explosions of zone files, especially when
DNSSEC signatures are generated statically.

Note that many characters have a lot more than 2 same characters.

> And, as has been noted before, which equivalence rules
> map specific

It's not national/script rules. Even in a script, the rules are
highly context sensitive.

For example, even within a Latin script, "BVLGARI" is an example
of U=V (FYI, "script" of Unicode is very coarse, because it
insists that Japanese script and Chinese script were same).

For another example, in Japanese writing rules, sameness is
different for characters in proper nouns (personal name, location
name etc.) and other words.

						Masataka Ohta

---

From: Ted Hardie <[email-masked]>
Date: Wed, 8 Sep 2010 17:29:49 -0700

> highly context sensitive.

I did not mean to imply that there was only one rule within
a particular national/script context, only to emphasize
that you could not deduce from knowing that one character
mapped to another in one specific pattern that it always
did so.

Sorry for any confusion.

regards,

Ted