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

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

On 27/08/10 17:58, Alex Bligh wrote:
> I think shadow is worth investigating further. I'm not yet convinced
> that the best answer isn't "do nothing", though.

	ISTR a claim by Mark Andrews, subsequently acknowledged by
	Paul Vixie, that SHADOW was applicable only to leaf zones.
	I didn't (and still don't) understand why, possibly due
	to Bear-of-little-brain syndrome, from which I sometimes
	suffer.

	I wonder whether this is still the case.

	ATB
	Niall O'Reilly

---

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

On 23/08/10 22:38, Alex Bligh wrote:
> Thirdly, if the application layer needs to
> be preconfigured, that makes automatic XNAME stuff less useful.

	XNAME seems only to address the scaling aspect.

> I don't
> see the point in doing a lot of work at the DNS layer without
> considering the problems it generates at the application layer.
> Is asking whether work is actually useful or counterproductive to
> the application layer really out of scope?

	Whatever the synchronization solution (provisioning,
	XNAME, SHADOW, anything else), applications will still
	need attention if the supposed needs of any of the
	interested communities with respect to "sameness" of
	domain names are to be met.  Collapsing O(a^n) instances
	of an application to O(n) is an obvious optimization,
	even if we probably have enough IPv6 address space to
	accommodate the larger number.

	If this attention is forthcoming, I expect that the
	obvious next question will be, "Why is the DNS still
	an obstacle?"

	I'm drawn to a couple of conclusions.
    1.	Action is needed either on two (several?) fronts
	(DNS and applications), or not at all.
    2.	We're facing an architectural challenge which can't be
	addressed by merely adding features to existing components.

	ATB
	Niall O'Reilly

---

From: Paul Vixie <[email-masked]>
Date: Fri, 03 Sep 2010 20:47:30 +0000

> Date: Fri, 03 Sep 2010 12:19:07 +0100
> From: Niall O'Reilly <[email-masked]>
> 
> 	I didn't (and still don't) understand why, ...
> 

as proposed, this is still the case. we could work on it if SHADOW
is adopted by the WG. (no use polishing it further if it's doomed.)

the reason it's leaf-only is that shadowed NS RRsets would create
new delegation points toward existing nameservers, but nothing in
the document specifies how the automation of SHADOW would be
accomplished by those servers.  (SHADOW only specifies apex NS RRset
handling at present.)

the reason this problem is hard is that the delegated servers (below
the SHADOW zone) would have a multiplicative problem to solve and
they would have to do both initial and periodic polling to find all
of the SHADOW RRsets above their authority zones.  multiplicative,
because of they are authoritative for x.y.com, then y.com and com
might each possess SHADOW RRsets equivilencing y.com to z.com and
com to commerce, thus the authority for x.y.com would have to perform
amber -> shadow regeneration for both x.z.com, x.z.commerce, and
x.y.commerce -- and if y.com some day adds w.com as another shadow,
then the x.y.com servers would have to poll for this (since they
will not receive notifies unless we change the SHADOW proposal to
specify this), and periodically add/drop generated shadow zones based
on ancestor SHADOW RRset changes.

so, a shadowed zone's delegated (non-apex) authority servers would have
even more work to do than a shadowed zone's apex authority servers,
but the shadowed zone's registrant would have far less control over
them (including ability to select them based on this feature level.)

this isn't fatal but it's extremely unlikely to prevail.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 3 Sep 2010 14:47:20 -0700

>this isn't fatal but it's extremely unlikely to prevail.

Could you say more about that last sentence? Why unlikely?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Sep 2010 01:07:17 +0000

> Date: Fri, 3 Sep 2010 14:47:20 -0700
> From: Paul Hoffman <[email-masked]>
> 

while i consider the problem an interesting one, it has no incremental
rollout possibility (the way SHADOW as currently proposed has).  if the
constraint for non-leaf zone shadowing is that all the authorities for all
of a shadowed zone's subzones (direct and indirect) must also implement
SHADOW, then deployment is basically impossible for any delegation-mostly
zone.

what this means is that SHADOW would be useful for VIX.COM / VIXIE.ORG /
VIXIE.SF.CA.US / x--fr4m15tat.COM, but not for COM / COMMERCE or for
.CN / .x--mumble.  we would see SHADOW RRsets inside COM and CN, but not in
the root zone.  in that sense, because i don't consider it practical for
all authority servers of every .CN descendent zone (direct plus indirect)
to *ever* all and fully implement SHADOW, then SHADOW is not a candidate
solution for ICANN's regulatory-level constraints.

---

From: Alex Bligh <[email-masked]>
Date: Sat, 04 Sep 2010 10:27:47 +0100

--On 4 September 2010 01:07:17 +0000 Paul Vixie <[email-masked]> wrote:

> then SHADOW is not a candidate

I don't think we know what these are - specifically I don't know whether
the requirement for sameness is actually recursive (to use the language
in the 'solution statement' thread).

-- 
Alex Bligh

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 04 Sep 2010 07:59:04 -0400

On 03/09/2010 4:47 PM, Paul Vixie wrote:
>> From: Niall O'Reilly<[email-masked]>
>>

How about the following:
Shadowed zones only contrain copy of the APEX of the
source zone and a DNAME. minus the SHADOW RRset.
(and possibly a back pointer as suggested by Doug Otis, but the
DNAME is also such a pointer)
In this case the DNAME translation mechanism should make all
delegations in the source zone work as well in the shadows.

The back pointer is an intriguing idea as it can at least in theory,
allow an application server that is configured for one of the
zones in this "name collection" to auto configure itself for all
  the names in the collection.

> this isn't fatal but it's extremely unlikely to prevail.

Olafur

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Sep 2010 14:59:23 +0000

> Date: Sat, 04 Sep 2010 10:27:47 +0100
> From: Alex Bligh <[email-masked]>
> 
> > ... then SHADOW is not a candidate

icann only handles TLD's, most of which are delegation-only or
delegation-mostly.  a solution which only handles leaf zones would
not be interesting to ICANN, no matter what regulatory constraints
are in extracted from the policy mosh pit.

SHADOW's main usefulness would be at the enterprise level, and possibly
inside a TLD where a single registrant is responsible for all subzones
under each shadowed delegation point.  (same-registrant is what gives
rise to the ability to select all of one's nameservers for a feature
level like SHADOW.)

---

From: Paul Vixie <[email-masked]>
Date: Sat, 04 Sep 2010 15:09:12 +0000

> Date: Sat, 04 Sep 2010 07:59:04 -0400
> From: Olafur Gudmundsson <[email-masked]>
> 

lookups for the MX or AAAA at the apex of the subzone would not work,
since the DNAME would only alias the subdomains of the subzone apex.

i am intrigued by the possibility that a shadow zone's delegation
points could be replaced by BNAME's, though.  this may be more
practical than my current assumption (single-registrant under
each delegation point under a shadowed zone.)

still, if we had BNAME then we might not use SHADOW at all, at
least for delegation-mostly delegation points (such as TLD's).
 
>  the names in the collection.

yes, i very much like the backpointer idea, but does it require automation?

(the reason SHADOW specifies automation is to coordinate shadow zone
generation/regeneration across a multivendor authority server set...
whereas the backpointers could just be hand-maintained.)

---

From: Alex Bligh <[email-masked]>
Date: Sat, 04 Sep 2010 16:47:13 +0100

--On 4 September 2010 14:59:23 +0000 Paul Vixie <[email-masked]> wrote:

>>> all authority servers of every .CN descendent zone (direct plus
>>> indirect) to *ever* all and fully implement SHADOW, then SHADOW is not
>>> a candidate solution for ICANN's regulatory-level constraints.
>>

I've added a bit more contact from your quote.

I recognize that a leaf-only solution is not useful per-se.

Ignoring DNSSEC for a minute, could SHADOW not be used to provide
non-recursive insecure sameness? So, e.g. a1. == a2., So if
in a1. we see
	example.a1.	IN	NS	ns.example.com.
then in a2. we necessarily also see
	example.a2.	IN	NS	ns.example.com.

Now, ns.example.com may reply differently for a query
with QNAME 'foo.example.a1.' from 'foo.example.a2.', but
right of the zone cut, the zones are still the same.

This ensures all delegations always match in both zones but
doesn't necessarily ensure subdomains of those are the same.
I would argue that is a useful property (see https example).
It also might be sufficient for ICANN (we don't know as we
have no definitive criteria from ICANN), though Jiankang Yao
thinks not (if I understand correctly).

-- 
Alex Bligh

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 04 Sep 2010 12:34:51 -0400

> thinks not (if I understand correctly).

Not in any of the {SC/TC, Arabic Script, Greek} contexts.

---

From: Alex Bligh <[email-masked]>
Date: Sat, 04 Sep 2010 19:06:13 +0100

> Not in any of the {SC/TC, Arabic Script, Greek} contexts.

Is this because we are assuming the requirement in those contexts
is that in addition to
  x.c1
giving the same nameserver results as
  x.c2
we are also assuming that
  y.x.c1
produces the same result from a DNS lookup as
  y.x.c2
?

(I am assuming here delegation from the registry occurs immediately
to the left of c1/c2)

If so, that's begging the question, I think.

Or did you mean that the requirement is that in addition to
  b1.c1
giving the same nameserver results as
  b1.c2
  b2.c1
  b2.c2
we are also assuming that
  y.b1.c1
produces the same result from a DNS lookup as
  y.b1.c2
  y.b2.c1
  y.b2.c2
?

Because if so, that could be handled by SHADOW plus a provisioning
hack in zone at the registry (to make b1=b2 etc.). IE SHADOW is only
being used to make the registry zones equivalent. We do not (I think)
know whether ICANN's requirement is that all the delegated zones
need to be the same too (which is my point), or merely delegated
to the same nameservers.

-- 
Alex Bligh

---

From: Cary Karp <[email-masked]>
Date: Sun, 05 Sep 2010 11:22:34 +0200

> produces the same result from a DNS lookup as

There is no uniform practice among TLD registries. Some delegate
second-level domains to autonomous operators. Others control the
second-level and only delegate on the third level. Both of the
situations described above therefore require consideration here. There
is, however, no basis for assuming the TLD operators to have homogeneous
perspectives on "sameness" or the need for a protocol mechanism for its
support. Nor is there any basis for assuming that lower-level delegees
will invariably share any interest their parents may have in propagating
sameness.

The controlled second-level namespaces are typically encountered in
ccTLDs that structure them more or less to reflect the initial set of
generic TLD labels. The operators of these ccTLDs -- all ccTLDs in fact
-- are under no intrinsic obligation to base their policies on ICANN's
recommendations. Voluntary agreements to do so exist, nonetheless, but
are based on the recognition of shared responsibility for the stable
operation of the DNS and rarely expressed as binding contractual
requirements of the type that do apply to the gTLDs.

The "Fast Track" IDN ccTLDs present a new set of policy, political, and
contractual challenges that are far from being understood, much less
settled. The eligibility requirements for Fast Track delegation are
comfortably met by some prospective operators, while others are barred
for reasons that can justifiable be seen as arbitrary. The manifestation
of such difficulties that has landed in this forum is the case where a
prospective operator wants more than one IDN correlate to a 3166 label,
but the Fast Track rules doesn't permit it. This can end up pitting
ICANN against a sovereign government. The possibility of relief being
provided in neutral technical terms by a protocol mechanism that can
provide an additional gate for unclear cases has obvious allure.

In one sense we are providing a venue for the firing line. Registries
with clear notions of how their specific requirements can be met are
articulating them here. But at the same time, we are expecting ICANN to
produce a generally applicable statement of "the problem", guessing in
the meanwhile what their intention might be, but failing to realize that
they are grappling with a complex set of issues that may not be amenable
to distillation into algorithmic terms. People on all sides appear to be
postulating that it is, but the difficulty that we are having in
rendering it tractable may suggest there are no grounds for that assumption.

/Cary

---

From: Cary Karp <[email-masked]>
Date: Sun, 05 Sep 2010 11:44:34 +0200

This is a PS to my previous note:

> The manifestation of such difficulties that has landed in this forum
> is the case where a prospective operator wants more than one IDN
> correlate to a 3166 label, but the Fast Track rules doesn't permit
> it.

I didn't intend to imply that ICANN's concerns with sameness are the
only reasons why we are having the present discussion. There are sound
reasons why a TLD operator, or any other zone administrator, may wish to
have a mechanism of the type under consideration.

Nonetheless, everybody here seems to be placing the onus of providing
The Problem Statement on ICANN.

/Cary

---

From: Alex Bligh <[email-masked]>
Date: Sun, 05 Sep 2010 11:17:09 +0100

Cary,

--On 5 September 2010 11:22:34 +0200 Cary Karp <[email-masked]> wrote:

> situations described above therefore require consideration here.

Sure. The bit in brackets starting "I am assuming" was meant to
indicated I had expressed things as if delegation was at the
second level. This was for clarity's sake, but you can replace cn
with cn.dm. if you want to consider a TLD delegating at the third
level.

My question is whether the alleged ICANN requirement (see below)
is for the registry's zones to be the same (and hence those which
are delegated to third parties to be delegated to the same nameservers
but whether queries to those nameservers return the same DNS is
different), OR whether there is a requirement for supposed sameness
down the tree.

> There

Sure (FWIW I cofounded the .uk registry and served on the board for 11
years including the Nominet/ICANN negotiation period)

> provide an additional gate for unclear cases has obvious allure.

Right, but it has been postulated here that the "provisioning hack" is
not suitable because a contractual guarantee of sameness (of some sort)
to ICANN is insufficient - they want a technical guarantee of sameness
(of some sort). Or, in your wording, a protocol mechanism to
enforce that contract. I am asking "sameness of what sort is required -
just the registry zones, or the whole tree?".

Elsewhere I asked whether the protocol method had to be in the root
zone - i.e. the root zone contains
	tld2.	IN	XNAME	tld1.

Or whether having it the registry's zone apex for tld2. would be
sufficient (i.e. the other side of the zone cut) so
root zone:
	tld2.	IN	NS	ns.example.com.
and in the registry:
	tld2.	IN	XNAME	tld1.
	
If there is a magical protocol mechanism acceptable to ICANN that
obviates the issue with multiple IDN correlates to a 3166 label, it
would be most helpful to know what the criteria for such a protocol
mechanism are - specifically whether they require recursive sameness
and what side of the zone cut the sameness has to be specified.

My own suspicion is that ICANN have not actually specified anything; 
they've
just said "oh well if you come up with some protocol modification to ensure
sameness of some sort TBD, we might allow more than one entry in the root".
If that is the case, we have some input on what sort of sameness is helpful
vs unhelpful at the application level. I suspect sameness in the registry's
zone(s) would be sufficient as presumably what ICANN don't want to do is
delegate more than one independent TLD per 3166 code, but that is merely my
speculation.

However Jiankang Yao, if I understand him right, has said that ICANN
require sameness to be recursive (I don't think he has said what side of
the zone cut ICANN require it to be), and no doubt he is closer to
TLD/ICANN discussions than me.

I am trying to find an authoritative source to answer one way or the other,
as it is difficult to design protocol modifications in the absence of
design criteria.

-- 
Alex Bligh

---

From: Cary Karp <[email-masked]>
Date: Sun, 05 Sep 2010 14:56:55 +0200

> ... it has been postulated here that the "provisioning hack" is
> ... Jiankang Yao, if I understand him right, has said that ICANN

Obviously the only entity that can authoritatively state ICANN's
position on this is ICANN itself. However, the mere concept of
"contract" between ICANN and an IDN ccTLD operator designated by a
sovereign government is heavily laden. That sovereignty would be even
more sorely taxed if ICANN were to expect forced recursion of the TLD
policies agreed upon in whatever formal instrument was ultimately
adopted. Here again, attitudes toward such action are to likely vary
from government to government, and the political delicacy of the problem
would be eased if the point of reference was an RFC rather than
something that ICANN might be pressed to negotiate differently from one
IDN ccTLD agreement to another.

>  they've just said "oh well if you come up with some protocol 
> modification to ensure sameness of some sort TBD, we might allow
> more than one entry in the root" ... but that is merely my
> speculation.

My own speculative assessment is that the only way to ensure "sameness"
between entire trees (using pretty much any definition) is by the TLD
operator not delegating administrative authority for lower-level zones
to any other entity. And since that would have no effect on the need for
harmonizing the configuration of all the daemons in the corresponding
application space, the unary steward of the namespace would need to have
similar control over the server side of the application space as well.

/Cary

---

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Sep 2010 18:09:12 +0000

> Date: Sun, 05 Sep 2010 11:44:34 +0200
> From: Cary Karp <[email-masked]>
> 
> I didn't intend to imply that ICANN's concerns with sameness are the only
> reasons why we are having the present discussion. There are sound reasons
> why a TLD operator, or any other zone administrator, may wish to have a
> mechanism of the type under consideration.

then those folks should help clarify a problem statement.  to my mind, SHADOW
is good enough for a TLD to use in supporting their 2LD's.  am i wrong in some
cases, or all cases?  some feedback from TLD operators would inform the forum.

> The Problem Statement on ICANN.

that's what the chairs told us at the outset, so, there we be.

---

From: Cary Karp <[email-masked]>
Date: Sun, 05 Sep 2010 20:56:36 +0200

> that's what the chairs told us at the outset, so, there we be.

A TLD operator trying to sway ICANN toward delegating multiple IDN
correlates to its 3166 label is likely to have a greater interest in
ICANN's problem statement than are TLD operators solely focused on their
own administrative concerns.

It may not be any more reasonable to expect a single problem statement
to crystallize out of the TLD contributions to this discussion than it
is for any hypothetical such result to be congruent with what ICANN may
yet articulate.

/Cary

---

From: "Patrik Faltstrom (pfaltstr)" <[email-masked]>
Date: Sun, 5 Sep 2010 22:09:11 +0200

> cases, or all cases?  some feedback from TLD operators would inform the forum.

You will not get a firm answer, as some people think it is good if two zones that are related CAN be managed by two different entities, while some think that is a non-starter.

   Patrik

---

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Sep 2010 20:40:15 +0000

> Date: Sun, 05 Sep 2010 20:56:36 +0200
> It may not be any more reasonable to expect a single problem statement to
> crystallize out of the TLD contributions to this discussion than it is
> for any hypothetical such result to be congruent with what ICANN may yet
> articulate.

understood.  however, ICANN's policy development process is even less
coherent than IETF's, especially where new DNS technology is a possible
consideration.  i think that if there is ever going to be a "problem
statement" fitting ICANN's requirements, then the TLD operators had best
use this forum (namedroppers@) to help explore those requirements.

otherwise we're going to hear from people like me who know what's possible
but who don't know what's useful or necessary.

---

From: [email-masked]
Date: Sun, 5 Sep 2010 20:54:35 +0000

> use this forum (namedroppers@) to help explore those requirements.

	but they have their own forums to discuss this kind of stuff.
	can't really see why they had "best" use this forum.

> but who don't know what's useful or necessary.
	
	certainly thats true on this forum.

--bill

---

From: Paul Vixie <[email-masked]>
Date: Sun, 05 Sep 2010 21:01:31 +0000

> Date: Sun, 5 Sep 2010 20:54:35 +0000
> From: [email-masked]
> 
> > ... ICANN's policy development process is even less coherent than
> > IETF's, especially where new DNS technology is a possible
> > statement" fitting ICANN's requirements, then the TLD operators had
> > best use this forum (namedroppers@) to help explore those requirements.
> 

i think it's because new DNS technology is a consideration, and because
even without that, ICANN's policy development process is even less coherent
than IETF's.

---

From: Brian Dickson <[email-masked]>
Date: Sun, 5 Sep 2010 23:12:01 -0300

I have a question about DNAME that I think has bearing on Olafur's
suggestion, and other proposals as well.

In RFC 2672, there is a limit *in zone files* of no descendants to DNAMEs.

However, what happens across a zone cut boundary, in the target of a DNAME?

When a delegation is found in processing a query, which has already
encountered a DNAME, what happens next?

Does the query start at the new nameserver using the original query, or the
DNAME-rewritten (and possibly CNAME-rewritten) query?

Or does it depend, i.e. it tries without the rewrite first, and then if that
doesn't get an answer, with the rewrite next?

Here's what I'm thinking...

It would be nice to have the ability to do something like "DNAME with
exceptions", to handle special cases like servers doing HTTPS, with unique
names.

So, in the case of a large number of "same" zones (who are all delegated to
a single registrant), that registrant can manage a large, complex zone, and
"sweeten" the vanilla zone with the per-"same"-instance exceptions?

I.e., consider example.com and example.net.
And foo1 through foo23, all belonging to the same registrant, who wants them
to be "the same".
The registrant wants a big zone file with multiple levels of labels, all
working "as expected".
So x.y.foo1.example.com resolves the same as x.y.foo22.example.net.

Add into that, the desire for www.secure.foo1.example.com through
www.secure.foo23.example.com, which all need to resolve "differently".

In an ideal world, the suggested method of "shadow+apex-dname", with the
additional tidbit:
In the "amber" zone, have the node "secure" be a zone cut.
The nameservers listed would handle all of the variants in the proper
manner, but only if they receive the query for the non-dname qname.

Is this how DNAME works today?

Is it feasible to suggest, if it isn't?

Brian

---

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

> accomplished by those servers.  (SHADOW only specifies apex NS RRset

Another problem which I don't remember being covered in your draft is delegation DS records. They can't be generated automatically by the master when it creates the shadow zone.

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

---

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

> From: Tony Finch <[email-masked]>
> Date: Mon, 6 Sep 2010 23:52:51 +0100
> 
> Another problem which I don't remember being covered in your draft is
> delegation DS records. They can't be generated automatically by the
> master when it creates the shadow zone.

it's not explicitly covered, so it's implicitly covered by "copy everything."

that is, all shadows would share key material with their amber zones.

if SHADOW turns out to get adopted by this WG, this might be something we
decide to work on in order to achieve a different outcome.

---

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

On 7 Sep 2010, at 09:30, Paul Vixie <[email-masked]> wrote:

> it's not explicitly covered, so it's implicitly covered by "copy everything." that is, all shadows would share key material with their amber zones.

But that won't work because the owner name of the DNSKEY RRs in the zones delegated from the shadow zone is different from the corresponding zones delegated from the amber zone, so the DS records will have to contain a different hash even if the keys are the same.

Tony.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 08 Sep 2010 01:59:00 +0000

> Date: Tue, 7 Sep 2010 13:02:25 +0100
> 
> > it's not explicitly covered, so it's implicitly covered by "copy
> > everything." that is, all shadows would share key material with their
> > amber zones.
> 
> But that won't work because the owner name of the DNSKEY RRs in the zones
> delegated from the shadow zone is different from the corresponding zones
> delegated from the amber zone, so the DS records will have to contain a
> different hash even if the keys are the same.

ouch.  so noted.  apex dnskey rr's would be copied verbatim, whereas any
DS RRs would have to differ in some way we'd have to work on if the SHADOW
proposal is adopted.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 08:55:58 -0400

> that's what the chairs told us at the outset, so, there we be.

I don't recall saying anything of the sort.  Can you provide a pointer
to where I said that?

What I have said, more than once, is that ICANN's adoption of a
provisioning rule to "synchronize" some TLDs is an example of someone
tackling this class of problems with provisioning only.  That suggests
to me that provisioning only, with no changes to the DNS, is one way
to achieve such a goal.  People have offered counter-arguments, and
while I don't find all of them persuasive they still seem to me to be
strong enough to merit the WG's attention.

The other thing I've said is that it seems to me that the DNS protocol
weenies are not the only (or maybe even primary) people who ought to
be stating what the problem is.  People in charge of zone policies and
application developers struck me as two likely groups who would have
something to say.  I think the discussion of the disutility of large
numbers of DNS names that are "the same" but that are unknown to
applications like web and mail servers is a good example of why that
input is important.  Among the people I'd hoped to hear from in this
class is ICANN, because around the time of the Anaheim meeting it sure
looked like they thought they had "a problem" that they wanted solved
by "the technical community".  But if they don't have anything to say,
that's ok with me too.

We have some participants working on a problem statement.  The
proposed charter Olafur and I sent yesterday would adopt that document
as a WG document.

A

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

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 08 Sep 2010 14:55:51 +0200

Hi Brian,

> However, what happens across a zone cut boundary, in the target of a DNAME?

Zone cuts are allowed at the target of the DNAME.  The only limit on the
target of a DNAME that I can think of is that the resolver is urged to
be cautious in spending resources chasing down an endless chain of
aliases, and therefore the target should have short alias chains.

> encountered a DNAME, what happens next?

The usual.

> Does the query start at the new nameserver using the original query, or
> the DNAME-rewritten (and possibly CNAME-rewritten) query?

The rewritten query.

> Or does it depend, i.e. it tries without the rewrite first, and then if
> that doesn't get an answer, with the rewrite next?

It does not depend, sorry.

> Is this how DNAME works today?

No, this is not how DNAME works.

> Is it feasible to suggest, if it isn't?

No, I think it is not feasible either (for backwards compatibility) to
change what you propose in DNAME.  The steps to solve backwards
compatibility would also be capable of adding a new RR-Type.

For the record, the C+DNAME issue may be different, since a preliminary
test shows implementations can work without explicit backwards
compatibility signaling.  I would still feel unsafe for backwards
compatibility with such a change.

DNAME could be used like this: if the root were to contain cn. NS
nameserver.cn. and cn0. DNAME cn. , then cn0. itself is not redirected,
but example.cn0 becomes example.cn and a.b.c.cn0 becomes a.b.c.cn.  And
delegations in the .cn zone are not a problem.  (and since dig cn ANY
shows only 'infrastructure' records there, perhaps the contents of the
cn0 name itself are not of interest to some of the problem owners).
Also syncronisation (aka 'ICANN-policy') is fully automated.  However,
the x.cn0 names cannot be used for some tasks in the DNS (there are
'second class citizens', as with all solutions based on CNAMEs), which
mainly makes configuration harder.  Lower down in the DNS the
'example.com' zone apexes usually hold user information, hence drafts
such as 'BNAME' and 'SHADOW'.  The server-software must host the
additional names as well, and this is unsolved by DNAME.

Best regards,
   Wouter (your friendly WG editor of the dname-bis draft).