CNAME and other data -vs- could not find NS and/or SOA records

Kevin Darcy kcd at daimlerchrysler.com
Fri Jun 4 23:51:26 UTC 2004


John Manly wrote:

>>Why not just put a foo.com CNAME record (and any records you want to =
>>    
>>
>put=20
>  
>
>>*under* foo.com) into the .com zone? From a protocol standpoint, =
>>    
>>
>that's=20
>  
>
>>exactly the way to handle it. It's just that the TLD operators don't=20
>>currently allow us ordinary folks to put such records in the zones. =
>>    
>>
>It's=20
>  
>
>>basically an administrative/political issue, then, *not* a technical=20
>>one. The protocol allows you to do what you want, but the TLD =
>>    
>>
>operators=20
>  
>
>>forbid it. Life is tough. Perhaps you should petition to start your =
>>    
>>
>own TLD.
>
>This is an interesting point in this discussion: is there a technical =
>reason
>why TLDs don't allow this, or is it just laziness in that they are set =
>up
>to do only SOA and NS records and that's worked fine for ages so why =
>bother?
>
Um, actually you'd only find 1 SOA record per TLD zone. I think you mean 
delegation NS records and glue A records...

I wouldn't necessarily call it "laziness". Their backend update 
mechanisms are oriented towards managing delegation-related information. 
They simply aren't equipped today to handle anything else.

The main "political" problem with allowing CNAMEs in TLDs is that it's a 
slippery slope. Once you allow CNAMEs which are directly under the TLD 
(e.g. foo.com), then folks are going to want second-level CNAMEs too 
(www.foo.com), third-level CNAMEs (www.northamerica.foo.com) and so 
forth. A typical delegation set in a TLD only puts 2 to 4 records into 
the zone (2 NS records and up to 2 glue A records), but if the average 
undelegated subdomain contains a higher number of CNAME records than 
that, the TLD zones grow significantly, and they're already way too big...

There are also the potential problems/inefficiencies of CNAME chaining 
or looping.

>And if one TLD were willing to support this kind of thing (which I =
>imagine could
>make them rather popular), could that TLD just do so all on its own, or =
>would it
>somehow have to coordinate with all the others, or with all the name =
>registrars,
>or with some other group?
>
No, they could do it on their own. Other than lack of support for CNAMEs 
in RRP (see below), it's mostly just an administrative matter. In fact, 
I think I vaguely remember that at least one small TLD registry actually 
allows CNAMEs, but it was a country-code TLD in which very few people 
were interested in registering...

>While we're on the subject, can someone supply a brief overview of the =
>relationship
>between TLDs and Registrars?  Who are the TLDs, anyway?  
>
TLD = Top Level Domain. Not really a "who", but a "what".

>I assume not =
>very Registrar
>is a TLD (there can only be one zone file for the .COM domain, for =
>example, right?),
>so who are the TLDs, and how do the Registrars typically feed data to =
>them?
>
There are registrARS and registrIES and TLD operators. Registrars are 
just business entities which sell domain-name services. The updates 
generated by registrar customers go into a registry, which is a 
mechanism for feeding the nameservers run by the TLD operators. See RFC 
2832  (http://ftp.rfc-editor.org/in-notes/rfc2832.txt) for the gory 
details of the Registry Registrar Protocol (RRP), which implements how 
updates to the registries of many TLDs are propagated.

>What I'm getting at here, of course, is if someone wanted to petition =
>for a TLD to
>change their policy to permit CNAMEs instead of NS and SOA records =
>(which, it seems
>to me, someone else on this list suggested not long ago, but it wasn't =
>apparent to
>me then exactly what they were talking about) who exactly would need to =
>be convinced,
>and how widespread would the change have to be?
>
Surely you mean "permit CNAMEs *in*addition*to* permitting delegations", 
don't you? It wouldn't be feasible for *every* non-apex name in a domain 
to be required to be a CNAME to a name in some other domain...

                                                                         
                                       - Kevin




More information about the bind-users mailing list