Subject: [dnsext] Re: Bundling of Domain Names and DNAME

From: Erik van der Poel <[email-masked]>
Date: Thu, 3 Dec 2009 09:58:44 -0800

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Vaggelis, thank you for raising this issue on the namedroppers list.

Namedroppers, I would like to clarify one item below.

On Thu, Dec 3, 2009 at 7:56 AM, Vaggelis Segredakis <[email-masked]> wrote:
> Recently, as a member of the discussion of the IDNABIS WG I tried to help
> resolving these issues by explaining them to that group. However that group
> is not free to completely re-design the IDNA protocol to something else but
> rather with small steps to reform it to something with fewer issues.
> Unfortunately, on this process, one of the changes that are implemented lead
> to even more names that have to be bundled together for each registrant.
> This makes it even more significant to break this chain of cost for the end
> user.

The IDNAbis WG drafts have not been published as RFCs yet. Currently,
the drafts make Final Sigma (Unicode U+03C2) PVALID, but this issue is
currently being discussed in the WG.

Erik

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Thu, 3 Dec 2009 17:56:14 +0200

Dear Members of the DNSEXT WG,

My name is Vaggelis Segredakis and I am the Administrator of the Registry of
the .gr ccTLD.

Since 2005 the .gr registry has provided our registrants with the option to
register domain names in Greek characters, according to the IDNA2003
translation of IDN characters to Latin characters. Due to the design of this
protocol, it has been necessary for the registry to bundle domain names that
in Greek represent the same word but in the IDNA2003 the representation is
different PUNYCODE domain names. To reduce the cost of the use of these
domain names, the registry bundles them (with the use of DNAME) in the .gr
zone file. We strongly believe that the IDNA protocol should help to ease
the use of the domain names and not to present new obstacles to the end
users who should not be blamed if the domain name was typed in small or
capital letters. I do not wish to burden you with details but if you wish a
more elaborate analysis of the issues presented in the IDNA protocols for
domain names in Greek characters please refer to my presentations:

-http://www.icann.org/en/meetings/lisbon/presentation-idns-greece-27mar07.pd
f

-https://www.centr.org/main/5354-CTR/version/default/part/AttachmentData/dat
a/IGF2009%20-%20Segredakis%20IDNA2008%20a%20Protocol%20with%20shortcomings.p
df

Bundling these domain names with DNAME seemed like a good choice but there
is an issue that this way of bundling does not solve:

If you have the domain name xn-1234.gr and you bundle it with xn-5678.gr
everything is fine - if you try to visit www.xn--5678.gr; you will be
redirected to www.xn--1234.gr. The same applies if you use ns1.xn-1234.gr;
it equals to ns1.xn-5678.gr. However, if you try to email [email-masked]
it will never arrive at [email-masked] because this bundling starts from
the next level and thus xn-1234.gr<>xn-5678.gr. The source of the problem I
am going to ask you to resolve is there.

 I ask you as a WG to either consider changing DNAME to include the first
layer and this way allow emails to be sent to [email-masked] and to be
delivered to [email-masked] or to present in DNS a new command that works
like DNAME with the upper layer included, let's call it xNAME for now. By
presenting this xNAME you will allow the registries to bundle domain names
in a consistent way that has full functionality for the end user who will be
able to receive emails, view web pages, FTP e.t.c. using domain names in his
language without having to adapt a new protocol. This should be an
undisputable right for all the users who do not use the Latin alphabet, the
same as it is for Latin alphabet users.

I will be happy to answer any questions you might have on my request. I
would be even happier if this revision of the DNS was to be presented along
with IDNA2008 adoption from the IETF so that the registries that really need
this bundling are ready to use these new protocols simultaneously for the
benefit of the end users.

Kind Regards,

Vaggelis Segredakis

Administrator of the .GR Top Level Domain

Institute of Computer Science

Foundation for Research and Technology - Hellas

Tel. +30-281-0391450

Fax +30-281-0391451

Email [email-masked]

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Fri, 4 Dec 2009 15:28:41 +0200

Dear Erik,

Actually it does not matter whether the final sigma is PVALID or not,
although I believe that it will be since both the .gr Registry and .cy
Registry have asked for it.

We have the same issue with the accent mark "tonos". Almost each word in
Greek has this accent mark in small letters but if you put it in capital
letters the mark is omitted, creating two different xn-- Punycode
translations for each word used as a domain name.

We Bundle domain names already because of this "tonos" and we face this
bundling issue since 2005 but we had put our hopes on the IDNA revision for
a better solution. Since this is not possible, we need the XNAME bundling
regardless of the final sigma in IDNA2008 situation.

Kind Regards,

Vaggelis Segredakis

-----Original Message-----
From: Erik van der Poel [mailto:[email-masked]] 
Sent: Thursday, December 03, 2009 7:59 PM
To: Vaggelis Segredakis
Cc: [email-masked]; Andrew Sullivan; Olafur Gudmundsson; Vint
Cerf; Sotiris Panaretou; [email-masked]
Subject: Re: Bundling of Domain Names and DNAME

Erik

---

From: Vint Cerf <[email-masked]>
Date: Fri, 4 Dec 2009 08:36:50 -0500

Vaggelis,

extensions of DNS in the XNAME direction would require creation of a  
new WG for this purpose.
I menion this only to make sure no one is expecting the IDNABIS  
working group to undertake the idea.

Vint

On Dec 4, 2009, at 8:28 AM, Vaggelis Segredakis wrote:

> On Thu, Dec 3, 2009 at 7:56 AM, Vaggelis Segredakis <[email-masked] 
> >
> wrote:
>> is not free to completely re-design the IDNA protocol to something  
>> else
> but
>> Unfortunately, on this process, one of the changes that are  
>> implemented
> lead
>> This makes it even more significant to break this chain of cost for  
>> the
> end
>> user.
>

---

From: Chris Thompson <[email-masked]>
Date: 04 Dec 2009 15:16:08 +0000

On Dec 3 2009, Vaggelis Segredakis wrote, inter alia:

>like DNAME with the upper layer included, let's call it xNAME for now.

It's totally unrealistic to change the spec of DNAME (in a major
particular) after 10 years of deployment, and I'm not going to add
an "IMHO" to that.

There's nothing innately impossible about having a new "xNAME" type.
Like CNAME, but unlike DNAME, it could not coexist with any non-DNSSEC
records of the same name (and so it could not occur at a zone apex,
for example). Like DNAME, it would render illegal (or at least invisible)
all RRs with child names in the same zone file. CNAME synthesis would
presumably be required.

But deployment of such a new type would hardly occur overnight.

Would it, I wonder, be feasible to relax the restriction (explicitly
present in RFC 2672) that a CNAME and DNAME cannot exist at the
same owner name? (I haven't thought this through in detail yet.)

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 04 Dec 2009 17:23:08 +0000

> Date: 04 Dec 2009 15:16:08 +0000
> From: Chris Thompson <[email-masked]>
> 

yes, it could, because all of .GR's authority servers could be upgraded
in one day, and it's the CNAME synthesis that occurs inside authority
servers that made DNAME deployable and would presumably do the same for
XNAME.

> same owner name? (I haven't thought this through in detail yet.)

this would be a dramatic, disruptive, chaotic and unwelcome change (IMHO).

---

From: Chris Thompson <[email-masked]>
Date: 04 Dec 2009 18:06:40 +0000

>servers that made DNAME deployable and would presumably do the same for

Point taken. But this would not be compatible with signing the zone, as
validators would have to understand XNAME before they would believe (well,
regenerate for themselves in fact) the synthesized CNAMEs.

That is, unless you started seriously hacking the GR servers, and had
them return a signed (apex) CNAME or a signed DNAME as the query demanded ...

>this would be a dramatic, disruptive, chaotic and unwelcome change (IMHO).

I've already gone off the idea myself :-)

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Dec 2009 16:10:31 -0500

At 15:16 +0000 12/4/09, Chris Thompson wrote:

On one hand I hear "12 years on and no one knows how to do DNAME and 
many deployments don't have DNAME code."  On the other hand I hear 
"we can't change the definition because of the installed base."

Document-wise DNAME is just at "proposed standard."  No one has 
expressed happiness with the existing definition and there is an open 
document to update the definition.

>particular) after 10 years of deployment, and I'm not going to add

You can send proposed edits of the DNAME definition to the editors of:
      http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-18

(I already did.)

Part of the change I sent in is captured here (the other changes are 
to descriptive text prior to this):

In Section 3.2

    3.  Start matching down, label by label, in the zone.  The matching
        process can terminate several ways:

        A.  If the whole of QNAME is matched, we have found the node.

            If the data at the node is a CNAME, and QTYPE does not match
            CNAME, copy the CNAME RR into the answer section of the
            response, change QNAME to the canonical name in the CNAME RR,
            and go back to step 1.

+          If the data at the node includes* a DNAME and the QTYPE does not
+          match any RRset(s) at the node, then copy the DNAME RR into
+          the answer section.  If substitution of its <target> for its
+          <owner> in QNAME would overflow the legal size for a <domain-
+          name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
+          perform the substitution and continue.  The server MUST
+          synthesize a CNAME record as described above and include it
+          in the answer section.  Go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the answer
            section and go to step 6.

* = in the text I sent the editors, the word was "is".  "Includes" is better.

"ANY" and "DNAME" QTYPEs don't chase the DNAME (as in "chasing the 
CNAME"), if the QNAME is an APEX, the SOA, NS won't chase.  But if it 
is the MX record you want and there's no MX at the DNAME owner, then 
you get it from the target.

The change was motivated by what was done in RFC 4592, section 3.3.3 
to the CNAME definition, 19 years after the original.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

---

From: JFC Morfin <[email-masked]>
Date: Fri, 04 Dec 2009 21:23:03 +0100

At 16:15 04/12/2009, John C Klensin wrote:
>(2) The disadvantage of such "new RR"-based mechanisms is that 
>they  would take a long time to deploy, at least if the universal 
>deployment of EDNS0 and DNSSEC are indicative.

This may go faster than you think, if there is a Google, Microsoft, 
Interplus competition supported by a flexible transition mechanism. 
However, the real target are a full IANA functions take over. Since 
RFC 4646. The langtags registries are designed to be a problem that 
only Google can solve. I was strongly opposed by Unicode everytime I 
tried to introduce an DNS like support in the langtag debate. The 
real matter we have to consider is the Google's DDDS that will 
support their DNS and most probably other IANA tables. This is what I 
call the MDRS, i.e. the Intersem metastructure, I introduced at the 
UNESCO/ITU meeting we attended a few years ago in Geneva. Its purpose 
is exactly the same as Google: to organize the world's information 
and make it universally accessible and useful. Except that we 
consider that its taxonomies and interpretation schemata are 
distributed personnal and not decentralised commercial domain.

There is NO architectural change in the Internet and DNS since we 
connected DoD to the international public network in 1984. Google and 
Interplus do not yet change anything and Microsoft wants to protect 
its assets. But this does not prevent extensions on Google and 
Interplus, and probably a few others in China, India and Europe, and 
an active strategy by Microsoft. Google has a huge user basis, 
Microsoft has a huge customer basis, Interplus has the whole Internet 
existing architecture that it opens to FLOSS and people, China, 
India, Europe, etc. have more than 300 million current userships. 
Work in Russia, Israel, Arabic countries starts being significant.

IMHO IDNA2008 has shown that everyone's interest is to build on 7bits 
DNS as a common solid core, until the DNS service providers are 
reduced to a little number of operative communities, whose adminance 
(technical and administrative governance) can talk together to 
discuss a DNS.2 evolution which has been made credible. So, for a 
while competition may stay on value added services (Microsoft?, ISP), 
people control (Google?), responsiveness and independence from every 
existing structure (Interplus?), governmental support and DNSSEC 
(ICANN?). Obviously Google's intrication of Google's DNS and ChromeOS 
is to carefully consider, etc. All this could actually lead to more a 
DNS responsible service stability. It is an unexpected "King muder 
strategy" that may actually help transition a lot.

jfc

---

From: jefsey <[email-masked]>
Date: Fri, 04 Dec 2009 22:30:57 +0100

>regardless of the final sigma in IDNA2008 situation.

Dear Vaggelis,

I suggest that you write a description of the issue (or quote one) so 
we can add it to http://idna2010.org issues to solve. There is most 
probably no real problem in addressing this kind of issue (similar to 
French access ent majuscules) but we have an entropy issue: we have 
to address all this kind of needs in a similar way (cf. RFC 1958) to 
keep it compact. This is the purpose of IDNA2010: to start from now 
perhaps defunct IDNA2008 we worked together, and document a Better 
Usage Document, listing the different possible cases and solutions 
that everyone can use for operational reference.

jfc

>_______________________________________________
>Idna-update mailing list
>[email-masked]
>http://www.alvestrand.no/mailman/listinfo/idna-update

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 7 Dec 2009 09:06:13 -0500

Wouldn't this be a problem for DNSSEC aware clients that see a response with
a DNAME?  These clients would ignore the synthesized CNAME and get confused
with the resulting DNAME.

So in a zone with 
TLD.  DNAME  TLD2.
      RRSIG  (DNAME)

and a DNSSEC enabled query for:
TLD.  IN  MX

would be (similar to Sec 5.3.4.3 in dname-bis draft):
Question:
TLD.  IN   MX

ANS:
TLD.  DNAME  TLD2.
      RRSIG  (DNAME)
TLD.  CNAME  TLD2.

(Auth/Add sections dropped)

The validator would ignore the unsigned CNAME and be left with the DNAME
that matches the QNAME.  What would happen to a client that gets a DNAME
that has the owner name that equals the QNAME?  (as in:  what does the
current validator code do?)

Perhaps a new RR would clean things up:  CDNAME (XNAME/ENAME/Whatever) which
would basically be a combined CNAME and DNAME.  That might have the same
problems with DNSSEC.  Or else relax the server rules about CNAME/DNAME
placement. i.e. a CNAME and DNAME is allowed at the same owner name (and
signed), and change the server algorithm so that:

If the labels(QNAME) = labels(CNAME), then return the CNAME.
If the labels(QNAME) > labels(CNAME), then use the DNAME (and
synthesize/include the CNAME but drop the RRSIG over it).
 
Does this make sense?  Technically, only the authoritative server code would
change, but it would only need to be those authoritative servers which want
this feature: a combined CNAME and DNAME RR.  Ideally, whatever solution we
have should work with current validators.

Scott

> to the CNAME definition, 19 years after the original.

===================================
Scott Rose
NIST
[email-masked]
ph: +1 301-975-8439
Google Voice: +1-571-249-3671

http://www.dnsops.gov/
===================================

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 7 Dec 2009 15:24:25 +0100

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Dec 2009 10:23:33 -0500

>current validator code do?)

Why would the validator 'ignore' the CNAME?  (I mean, I don't get 
your point.) Unless you mean that it is just not signed.

For a response that involves a DNAME, here are the possibilities.

1. QNAME is the owner of the DNAME, type is ANY or DNAME.

In this case, the response would include the DNAME as an answer and 
not as a rewrite rule, hence the synthesized CNAME would not be part 
of the answer.

2. QNAME is the owner of the DNAME, type is present at the owner.

In this case the DNAME would not be part of the answer at all, the 
CNAME goes un-synthesized.

3. QNAME is the owner of the DNAME, type is not present at the owner.

In this case the DNAME appears as the rewrite rule plus the 
synthesized CNAME.  If the nameserver is also authoritative for the 
target, then the answer looks like a CNAME response plus the DNAME. 
With DNSSEC involved, there would be a signature for the DNAME and a 
signature for the target-provided answer (note it might be that only 
one of the two zones is signed) plus a NSEC or NSEC3 showing that 
there is no RRset at the owner that matches the query.

4. QNAME is a descendent of the DNAME

In this case we are back to the DNAME as we mis-understand it today.

>problems with DNSSEC.

I just am not seeing the problems with DNSSEC.

Maybe because I think of DNSSEC as merely supplying the proof that 
what is in "The Algorithm" (which is what first appeared in RFC 
1034/4.3.2 and then modified by 4592 and the DNAME RFC, and now in 
this draft) so - if the algorithm works and is understood by both, 
all we need to get out of DNSSEC is proof of each step.  That might 
mean more negative answer proofs than we'd expect, but that just 
might be what is needed.

>  Or else relax the server rules about CNAME/DNAME

Ultimately, I think the issue of allowing CNAME and DNAME together is 
"then what about the SOA?"  DNAME wants to be at a zone apex, CNAME 
now can't be.

---

From: Michael Graff <[email-masked]>
Date: Mon, 07 Dec 2009 07:46:01 -0800

> current validator code do?)

The CNAME is created for clients which do not understand DNAME because 
they are too old to do so.  A DNSSEC resolver should understand DNAME 
and therefore ignore the CNAME anyway; I don't think this is specified 
anywhere though that DNAME should be understood by DNSSEC resolvers, 
only implied because it's assumed DNSSEC == modern == all in-use RFCs 
implemented.

--Michael

---

From: "Rose, Scott W." <[email-masked]>
Date: Mon, 7 Dec 2009 10:57:14 -0500

I probably wasn't clear.  The real question is what does the validator do when it gets a DNAME with an owner name equal to the QNAME (and the QTYPE is not DNAME)?   Right now in dname-bis (and original spec) it's <no match> - substitution is not done (Section 2.2, Table 1).   Ed's proposed text would make the DNAME act as a CNAME in that case, which is fine, but would a validating resolver know to do that?

Scott

On 12/7/09 10:46 AM, "Michael Graff" <[email-masked]> wrote:

--Michael

http://www.dnsops.gov/

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Dec 2009 12:16:25 -0500

Answering w/o regard for what's in the specs now (if it is different 
we can attack that next):

Let's look at this response fragment:

flags: AA ...

question:

xn--12345. IN MX

answer:

[0] xn--12345.  900 IN   DNAME    tld.
[1] xn--12345.  900 IN   RRSIG    DNAME
[2] xn--12345.  (?) IN   CNAME    tld.
[3] xn--12345. 1200 IN   NSEC     12345. SOA NS DNAME NSEC RRSIG
[4] xn--12345. 1200 IN   RRSIG    NSEC
[5] tld.       3600 IN   MX       10 server1
[6] tld.       3600 IN   MX       20 server2
[7] tld.       3600 IN   RRSIG    MX

Record 0 is the redirection instruction, validated by record 1 and 
results in the synthesized record 2.

Record 3 demonstrates that there is no MX record at the owner name, 
hence the new rules say "perform the redirection and look there", 
record 4 validates the rule.

Records 5 and 6 are the MX records sought.  Record 7 validates them, 
using the signature of the target's zone.

The validator should look at record 1 and use that to validate that 
there is potentially a redirection to be done and record 4 to see 
that the redirection is warranted.  The redirection rule's validity 
is from record 1, the applicability is from record 4.  Once 
established that the rule is valid and applicable (germane) then 
record 7 establishes the validity of the target's data.

If the nameserver does not also host tld., then only records 0-4 
appear and the first two sentences of the previous paragraph still 
apply.

If there is no MX set at the target (and the server has both zones):

[0] xn--12345.  900 IN   DNAME    tld.
[1] xn--12345.  900 IN   RRSIG    DNAME
[2] xn--12345.  (?) IN   CNAME    tld.
[3] xn--12345. 1200 IN   NSEC     12345. SOA NS DNAME NSEC RRSIG
[4] xn--12345. 1200 IN   RRSIG    NSEC
[8] H(tld.)    1200 IN   NSEC3    H(*.tld.) SOA NS RRSIG
[9] H(tld.)    1200 IN   RRSIG    NSEC3

(I skipped numbers 5, 6, 7 to reduce confusion with the first example.)

Record 8 is an NSEC3 saying that there's no MX at the target's name - 
with H(tld.) being the hash of the name for NSEC3 purposes.  (I 
didn't look but there should be a NSEC3PARAM in the response 
somewhere too, right?)

If the target does not exist, then record 8 is replaced by something 
that would trigger an NXDOMAIN error code.

At 10:57 -0500 12/7/09, Rose, Scott W. wrote:
I probably wasn't clear.  The real question is what does the 
validator do when it gets a DNAME with an owner name equal to the 
QNAME (and the QTYPE is not DNAME)?   Right now in dname-bis (and 
original spec) it's <no match> - substitution is not done (Section 
2.2, Table 1).   Ed's proposed text would make the DNAME act as a 
CNAME in that case, which is fine, but would a validating resolver 
know to do that?

Scott

On 12/7/09 10:46 AM, "Michael Graff" <<>[email-masked]> wrote:

--Michael

<>[email-masked]

<http://www.dnsops.gov/>http://www.dnsops.gov/
===================================

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 08 Dec 2009 11:55:57 +0000

Apologies to all if I'm just repeating the obvious.

On Mon, 07 Dec 2009 10:23:33 -0500, Edward Lewis wrote:
> Answering w/o regard for what's in the specs now (if it is different we 
> can attack that next):

	Ed,

	you seem to be suggesting a way to avoid writing up xNAME
	by simply extending the specification of DNAME.  This seems a
	neat procedural short cut.  I wonder what hazards of
	interoperability may arise with existing resolvers which already
	(mis-) understand DNAME.  Are you convinced that this is "not
	a problem"?  Can you convince others? [Assuming that they are
	prepared to be convinced ... 8-)]

	The idea of giving DNAME "weak" re-directing semantics for the
	owner node, over-ridden by "stronger" resource records, seems
	to be significant only at a zone apex, where it would be needed
	to preserve (possible) existing use of DNAME to cover the
	descendants of the apex node.

	I'm convinced that placement of DNAME at a zone cut (in
	conjunction with NS records) makes no sense, as this would
	involve (as DNAME is currently understood) hijacking on the part
	of the parent of all the descendants of the apex of the
	delegated zone.  With the proposed extended DNAME semantics,
	such hijacking would simply become more thorough.

 > this would be a dramatic, disruptive, chaotic and unwelcome change

	Paul,

	You may be right, but just saying doesn't make it so.

	Would you care to fill in the background to your opinion with an
	example or two?  AFAICS, there is no intrinsic semantic conflict
	between CNAME and DNAME, as they "cover" different parts of the
	naming hierarchy: one, the owner node; the other, its
	descendants.  OTOH, there is conflict between CNAME and other
	data which belong to the same node.  It seems to me that this is
	the only reason that it is forbidden to have "CNAME and other
	data".

	Everyone,

	For a node which is neither a zone apex nor a zone cut, either
	the extension which Ed suggests or relaxation of the rule which
	excludes co-incident CNAME and DNAME records would allow
	"bundling" of the kind which Vaggelis sees as the means to
	support the kind of variant label clusters which his country's
	registry (and likely many others) must accommodate.  Otherwise,
	a ned RRtype is needed to do the job.  This bundling is needed
	in parallel to, but not at, a zone cut, as in the following
	example.

$ORIGIN gr.  ; I hope no-one is offended by this choice
;
; zone cut
deleg	IN NS ns1.deleg.gr.
	IN NS ns-a.example.com.
;
; parallel bundled pseudo-delegation
xn--12345  IN DNAME deleg  ; take care of descendants
xn--12345  IN CNAME deleg  ; take care of owner node

	With the extended DNAME specification, the CNAME record shown is
	to be omitted.

	Depending on policy at a specific registry, the "bundle" may
	comprise several pseudo-delegations.  The option of using
	parallel zone cuts leads inevitably to problems either of
	quality assurance or of straitforward conflict.

	Best regards,

	Niall O'Reilly

---

From: "Rose, Scott W." <[email-masked]>
Date: Tue, 8 Dec 2009 09:33:27 -0500

>         such hijacking would simply become more thorough.

I don't think this is what is being advocated, but instead give DNAME some
CNAME-like features. The restriction of having a DNAME at the same owner
name as a NS RR (except at the zone apex) will still be part of dname-bis.

The question is:  What would break because of this (if anything)?

Scott

http://www.dnsops.gov/

---

From: Paul Vixie <[email-masked]>
Date: Tue, 08 Dec 2009 14:57:24 +0000

> From: "Rose, Scott W." <[email-masked]>
> Date: Tue, 8 Dec 2009 09:33:27 -0500
> 

it would break <http://ftp.isc.org/isc/pubs/tn/isc-tn-2002-1.txt> but
there's a simple patch which is to DNAME the 0-9,a-f labels instead.  so,
this is not a showstopper.  (and ip6.int is pretty well dead anyway.)

i don't know what else would break under this proposal.  if it's not a
change at the nameserver layer and the only thing it does at the
application layer is make DNAME more usable for IDN TLD's, let's do it.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Dec 2009 02:08:20 +1100

> 	prepared to be convinced ... 8-)]

Extending DNAME this way breaks the ability of a zone owner to
redirect themselves.  It forces the redirection to be done in the
parent zone.  This is the trade off that was made when we decided
to do DNAME the way we did it.  The majority of the worlds resolvers
handle DNAME today as it is currently defined.

If we need different semantics, create a new type and use it.  The
currently published DNSSEC algorithms MUST NOT be used to sign the
zone.  We can use the DNSSEC algorithm number to signal that xNAME
is understood.  This should be a relatively easy extension for
anyone that is already DNAME aware.  In the meantime the authoritative
servers for the zone just synthesis responses until xNAME awareness
spreads.
 
Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Tue, 8 Dec 2009 07:18:24 -0800

> this is not a showstopper.  (and ip6.int is pretty well dead anyway.)

You mean the ip6.int zone that was removed from .int on 6/6/06?

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Tue, 8 Dec 2009 15:26:12 +0000

On 2009-12-08, at 14:57, Paul Vixie wrote:

>> (and ip6.int is pretty well dead anyway.)

It's pushing up the daisies, pining for the fijords, etc, and has been for some time. Perhaps ISC-TN-2002-1 should be marked historic :-) At least, it seems like that very specific use of DNAME is no reason to preserve current behaviour.

[octopus:~]% dig @NS.ICANN.ORG IP6.INT NS +norec

; <<>> DiG 9.6.0-APPLE-P2 <<>> @NS.ICANN.ORG IP6.INT NS +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14939
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;IP6.INT.			IN	NS

;; AUTHORITY SECTION:
INT.			86400	IN	SOA	dns1.icann.org. noc.icann.org. 2009120701 3600 1800 604800 86400

;; Query time: 270 msec
;; SERVER: 192.0.34.126#53(192.0.34.126)
;; WHEN: Tue Dec  8 15:22:18 2009
;; MSG SIZE  rcvd: 79

[octopus:~]%

---

From: [email-masked]
Date: Tue, 8 Dec 2009 15:39:55 +0000

> You mean the ip6.int zone that was removed from .int on 6/6/06?

	yeah... that one.

--bill

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Dec 2009 12:03:05 -0500

I've seen earlier posts and am still working my way through them, but 
this one has comments that I can't understand.

At 2:08 +1100 12/9/09, Mark Andrews wrote:

>parent zone.

In trying to understand what is meant by that comment, let's look at 
the three ways DNAME could appear relative to a zone cut.

1.) Above the zone cut:

$ORIGIN tld.

xn--12345.tld.  DNAME  xn-54321.example.net.
xn--12345.tld.  NS     ns1.nameserver.example.net.
xn--12345.tld.  NS     ns2.nameserver.example.net.

Well, that's an "illegal" configuration as we can't have a DNAME and 
NS together in this way.  There's a conflict between being referral 
to other servers and the query rewrite instruction.  So we are down 
to two ways.

2.) Inside a zone, i.e., not at the apex:

$ORIGIN tld.

xn--12345.tld.  DNAME  xn-54321.net.
;;
xn--54321.tld.  NS     ns1.nameserver.example.net.
xn--54321.tld.  NS     ns2.nameserver.example.net.

In this case, any record types other than SOA, CNAME and NS can be 
present at the DNAME owner.

xn--12345.tld.  DNAME  xn-54321.net.
xn--12345.tld.  TXT    "text string from parent"
xn--12345.tld.  MX     10 mailserver.example.net.
xn--12345.tld.  MX     25 backupserver.example.net.

In the existing rules, queries for xn--12345.tld./(DNAME, TXT, MX and 
ANY) will be sourced from the above, and NoError/NoData for all other 
types.  The proposed new rule would later the latter to say "source 
the answer from whatever is at the DNAME target."

So there is redirection at the parent here, at least as far as I 
understand redirection.

3.) At the apex of a zone:

$ORIGIN xn--12345.tld.
@               SOA    .... .... .....
                 NS     ns1.xn-54321.tld.
                 NS     ns2.xn-54321.tld.
                 TXT    "this is from xn-12345.tld"
                 DNAME  xn--54321.tld.

and looking at the target:

$ORIGIN xn--54321.tld.
@               SOA    .... .... .....
                 NS     ns1.xn-54321.tld.
                 NS     ns2.xn-54321.tld.
                 TXT    "this is from xn-54321.tld"
                 MX     10 mailserver.example.net.
                 MX     25 backupserver.example.net.

Under the existing rules, a query for (xn--12345.tld/MX) fails to 
return the desired records (which is the original problem, if I 
understand correctly).  The proposed extension would "source" the 
answer from xn--54321.tld.'s MX record.  Essentially, now allowing 
the child to redirect.

I don't get how this "forces the redirection to be done in the parent zone."

>The majority of the worlds resolvers handle DNAME today as it is
>currently defined.

I would hope so, because if they didn't do it today as it is 
currently defined, they don't comply with RFC 2672.

>If we need different semantics, create a new type and use it.

The proposal is based on what has happened to the CNAME definition. 
We didn't create a new type for that.

It still is a valid and open question, what does the proposed extension break?

>The currently published DNSSEC algorithms MUST NOT be used to sign the
>zone.

The message doesn't support this assertion.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Dec 2009 15:25:09 -0500

>	descendants of the apex node.

A while back I described CNAME as "terminal query redirection" in 
that it said "go here and that is that" (with the possibility that 
"here" also had a redirection command) and DNAME as "non-terminal 
query redirection" in the sense that it said "go to the place that is 
the result of your query and this instruction and that is that." 
Non-terminal in the sense you had more work to do to figure out where 
to try next.

I got that analogy from the NAPTR record and it's choice of having 
the recipient follow the REGEXP exclusive-or REPLACEMENT field.  (RFC 
3761, 2.4.1, Flags defines the "U" flag in the ENUM context.)  It's 
analogous in the sense that when the U flag is present and the REGEXP 
is applied to the appropriate string, the application is "done 
DNSing" and moves on to locating the service.  No "U" flag, the 
REPLACEMENT domain name is used for the next step - although as far 
as I know no ENUM proposal has successfully proposed using that 
feature.  (Too scary!  Just like DNAME.)

Starting with the view that DNAME then is essentially CNAME on 
performance-enhancing drugs, then looking at the extension done to 
CNAME seems like it could be done to DNAME.  For CNAME we just said 
"if the QNAME has a CNAME and the QTYPE matches (word chosen to cover 
ANY) one (or more) types at the owner, we stop there, otherwise chase 
the CNAME."  Because CNAME is a name-hogger (nothing else can be 
there, except the DNSSEC stuff), essentially this comes down to 
QTYPE=CNAME or ANY or DNSSEC-type.  DNAME is not a name-hogger so we 
just recognize that the same rule (whatever matches) applies here but 
looks a bit different.

That *philosophically* is the extension, or where the idea came from.

>	such hijacking would simply become more thorough.

Yeah, a DNAME can't be a cut-point (as opposed to a non-delegation 
name or an apex).  For the same reason you can't have a TXT at a 
cut-point, too.

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 08 Dec 2009 20:48:57 +0000

> name as a NS RR (except at the zone apex) will still be part of dname-bis.

	Thanks for the clarification.  I'm sorry that my careless choice
	of words made you feel it was needed; I ought to have begun that
	paragraph, "I realize that ...".

	With apologies,

	Niall O'Reilly

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 08 Dec 2009 21:08:10 +0000

Edward Lewis wrote:
> A while back I described CNAME as "terminal query redirection" in that 
> it said "go here and that is that" (with the possibility that "here" 
> also had a redirection command) and DNAME as "non-terminal query 
> redirection" in the sense that it said "go to the place that is the 
> result of your query and this instruction and that is that." 
> Non-terminal in the sense you had more work to do to figure out where to 
> try next.

	I noticed that back then, but understood it in a subtly
	different, but perhaps equivalent sense.
	I like the terminology, either way!

	/Niall