Re: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation)

["Health" <healthyao@gmail.com>]

----- Original Message ----- 
From: "Chris Thompson" <cet1@cam.ac.uk>
To: <namedroppers@ops.ietf.org>
Sent: Tuesday, October 20, 2009 2:36 AM
Subject: [dnsext] Re: DNAME-bis issues (was: [DNSOP] new draft about idn tld variant implementation)


> [I sent this response to Andrew's posting to namedroppers on Friday,
> but it seems to have been lost completely in this weekend's troubles
> with the mailing list. Ah well, it gives me a chance to correct and
> expand it a bit this time ...]
> 
> On Oct 16 2009, Andrew Sullivan wrote:
> 
>>As near as I can tell, the problem is that the current draft makes an
>>explicit claim that DNAME is not allowed on the parent side of zone
>>cuts, and there is reason to believe that existing implentations have
>>no trouble with child-side DNAMEs, so this would be a protocol change.
> 
> No-one (I hope) is claiming that a DNAME can exist on the parent side
> of a cut, in the sense of coexisting with delegation (i.e. non-apex)
> NS records.
> 
> This came up while discussing draft-yao-dnsop-idntld-implementation-00.txt.
> There are two proposals being compared:
> 
>  ; In the root zone
>  xn--314159. NS ...some nameserver...
>              NS ...other nameservers...
>  xn--217182. NS ...some nameserver...
>              NS ...other namesevers...
> 
> versus
> 
>  ; In the root zone
>  xn--314159. NS ...some nameserver...
>              NS ...other namesevers...
>  xn--217182. DNAME xn--314159.


do you mean that the following records can work or not in the root server?

>  xn--314159. NS ...some nameserver...
>              NS ...other namesevers...
>  xn--217182. DNAME xn--314159.

I has a little confused by the following comments.

Could you help me to clarify it?

Thanks a lot.



> 
> Alfred said essentially (I hope I am not misrepresenting him) "You can't
> use the second variant, because DNAMEs have to be at the zone apex. You
> have to delegate and then put the DNAME at the apex of the child zone."
> 
> My claim is that is not the intention of the draft, or (as the lawyers say)
> in the alternative that it is, it's grossly incompatible with RFC 2672.
> with deployed code, and with existing DNAME records.
> 
> But if I am right in thinking that was not the intention of the draft,
> then the fact that it could be misinterpreted that way is fairly serious.
> I can certainly see that section 2.3 taken in isolation could be confusing.
> I would suggest replacing "DNAME Apex" by "DNAME Owner Name" in the section
> title, and the second paragraph by
> 
>   If a DNAME record is present at the zone apex, there is still is a need
>   to have the customary SOA and NS resource records there as well. This
>   means that a DNAME cannot be used to mirror a zone completely, as it
>   does not mirror the zone apex.
> 
> Should I declare an interest? We use DNAMEs in parts of our reverse lookup
> tree, and some of them are very definitely not at a zone apex.
> 
> -- 
> Chris Thompson               University of Cambridge Computing Service,
> Email: cet1@ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
> Phone: +44 1223 334715       United Kingdom.
>