So which Moron concluded DNAME was dead?

[Rubber Duck]

Excerpt from latest draft September 25, 2007, September 25, 2007

This document is an update to the original specification of DNAME in
RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
maintaining address-to-name mappings in a context of network
renumbering. With a careful set-up, a renumbering event in the
network causes no change to the authoritative server that has the
address-to-name mappings. Examples in practice are classless reverse
address space delegations and punycode alternates for domain spaces.

Other usage of DNAME lies in redirection of name spaces. For
example, a zone administrator may want subtrees of the DNS to contain
the same information. DNAME is also used for redirection of ENUM
domains to another maintaining party.

This update to DNAME does not change the wire format or the handling
of DNAME Resource Records by existing software. A new UD (Understand
DNAME) bit in the EDNS flags field can be used to signal that CNAME
synthesis is not needed. Discussion is added on problems that may be
encountered when using DNAME.

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-05.txt

http://groups.google.com/group/comp.protocols.dns.std/browse_thread/thread/46cf89a5459d26dc/499d0ed9794745b8

[jacksonm]

The DNAME specification work can go on at IETF, but it would appear at the current time that ICANN is hell bent against implementing it in the ICANN root nameservers. IETF has absolutely zero to do with ICANN. We could have ICANN, MYCANN, and WHYCANN and IETF specification/standardization work would be equally useful to all of them.

As I have been saying, ICANN does not have exclusive worldwide rights to be the only organization running a set of root nameservers.

.

[markits]

Good find Dave,
It surely suggests that dname is not dead yet, which is a good and positive news. Let's all wait and see.

[Rubber Duck]

They are definitely not ready to implement it and will not be able to until they get the necessary clearances from SSAC. ICANN themselves could not tell you whether DNAMES is a runner or not, that is not how PDP works within ICANN. The Staff can tell you there are no current plans, which basically means the Board has not approved any PDP specifically relating to DNAME. You cannot even really say whether things are in the pipe or not, because that is just not how things work. What I can tell you is IETF would not be working on this if there was no interest, and by that I mean finance. Where that is coming from who knows, but this might give some clues:

http://groups.google.com/group/comp.protocols.dns.std/browse_thread/thread/46cf89a5459d26dc/499d0ed9794745b8

The DNAME specification work can go on at IETF, but it would appear at the current time that ICANN is hell bent against implementing it in the ICANN root nameservers. IETF has absolutely zero to do with ICANN. We could have ICANN, MYCANN, and WHYCANN and IETF specification/standardization work would be equally useful to all of them.

As I have been saying, ICANN does not have exclusive worldwide rights to be the only organization running a set of root nameservers.

.

[jacksonm]

Any person can write and submit a draft to IETF, and it will be published. They accept all drafts which meet their document formatting standards.

From the draft, you have one guy from NIST and one from NL working on this. Don't know what conclusions to draw from that, as they are larger organizations, however just because there exists an IETF draft doesn't necessarily mean that there is any thing else than a bored geek behind it.

.

[Rubber Duck]

Any person can write and submit a draft to IETF, and it will be published. They accept all drafts which meet their document formatting standards.

From the draft, you have one guy from NIST and one from NL working on this. Don't know what conclusions to draw from that, as they are larger organizations, however just because there exists an IETF draft doesn't necessarily mean that there is any thing else than a bored geek behind it.

.


The Google Groups thread has references to Affilias and Neustar, and we all know that Verisign instigated the whole thing, so it all seems pretty much rooted within the GNSO.

The bottom line is that nobody sees the current gTLD implementation time table requiring DNAME any time soon, because they are confident that initially at least things can be handled within the DNS itself. It would seem that if the number of strings requiring Aliasing gets very large then that is going to present major problems, but they can get up and running using this method and it may even have advantages for large volume extensions.

[jacksonm]

Have you seen any news from the past day or two regarding aliasing coming out of LA?

It all seems fairly secretive to me. I'm dying to hear something official.

.

[Rubber Duck]

Have you seen any news from the past day or two regarding aliasing coming out of LA?

It all seems fairly secretive to me. I'm dying to hear something official.

.

What everyone seems to forget is that this is exactly what the DNS does. It Aliases IP addresses with Domain Names. That is what it was designed to do and that it is what happens each time a browser query is made.

The ICANN servers return the IP Address of the Registry Nameservers for the extension, which then returns their own IP record for the Second Level String.

To Alias it would seem that all that really needs to happen is to have duplicate IP addresses for different First Level strings. If dot Com can be pointed at the Verisign Nameservers so can .WTF!

Little of this has much bearing on the discussions at ICANN. Most of those in attendance wouldn't have a clue about any of this stuff.

[markits]

.wtf!:p :p

[jacksonm]

The ICANN servers return the IP Address of the Registry Nameservers for the extension, which then returns their own IP record for the Second Level String.


Not exactly. A query for www.foo.com would first send a query for .com nameserver's IPs to the root, if they're not already cached. Secondly, a NS (nameserver) query for foo.com is sent to the .com nameservers, if they're not already cached. Thirdly, a CNAME query is sent to the foo.com nameservers, if the www.foo.com name isn't already cached.



To Alias it would seem that all that really needs to happen is to have duplicate IP addresses for different First Level strings. If dot Com can be pointed at the Verisign Nameservers so can .WTF!


This is only half of a solution; it only provides forward mapping. Reverse mapping is still required.

1. Let's assume that .xn--c is aliased to .com

2. Let's assume the host xn--a.xn--b.xn--c has the IP address of 1.2.3.4

3. Perform a reverse DNS lookup on 1.2.3.4
- expected answer is xn--a.xn--b.xn--c
- actual returned answer is xn--a.xn--b.com (this breaks SSL and all sorts of other things)


To implement an effective solution, both forward and reverse records must be handled properly. The solution would be when you register nameservers for xn--b.com, you literally register them as xn--b.xn--c if xn--c is what you want to be returned from reverse lookups. Also an extra step would need to be added to the DNS resolver protocol for reverse lookups - consult the extension that the domain owner has registered for the domain's nameservers.

This is just one solution, but something along these lines needs to be implemented. And that will take time.

.

[Rubber Duck]

Thanks for the technical clarification.

It seems clear from all that I have read that the ICANN boys know exactly how this is done even if they don't openly discuss it so that the rest of us are fully up to speed.


Not exactly. A query for www.foo.com would first send a query for .com nameserver's IPs to the root, if they're not already cached. Secondly, a NS (nameserver) query for foo.com is sent to the .com nameservers, if they're not already cached. Thirdly, a CNAME query is sent to the foo.com nameservers, if the www.foo.com name isn't already cached.




This is only half of a solution; it only provides forward mapping. Reverse mapping is still required.

1. Let's assume that .xn--c is aliased to .com

2. Let's assume the host xn--a.xn--b.xn--c has the IP address of 1.2.3.4

3. Perform a reverse DNS lookup on 1.2.3.4
- expected answer is xn--a.xn--b.xn--c
- actual returned answer is xn--a.xn--b.com (this breaks SSL and all sorts of other things)


To implement an effective solution, both forward and reverse records must be handled properly. The solution would be when you register nameservers for xn--b.com, you literally register them as xn--b.xn--c if xn--c is what you want to be returned from reverse lookups. Also an extra step would need to be added to the DNS resolver protocol for reverse lookups - consult the extension that the domain owner has registered for the domain's nameservers.

This is just one solution, but something along these lines needs to be implemented. And that will take time.

.