On 10/25/2007 07:51 AM, Rogelio wrote: > Not sure if this is the best place to ask this question (and if so, > please point me to a better listserv), but is there anything "wrong" RFC > or best practice wise with pointing a CNAME record to a DNS server? > > (I'm using EveryDNS.net, and I'd like to make my CNAME records > ns1->4.myDomain.com <http://4.myDomain.com> correspond to > ns1->ns4.EveryDNS.net.)
While aliasing your name servers might work, it also may not, depending on the various DNS server software implementations and configurations around the planet. With that in mind, aliasing your name servers introduces a high probability of problematic DNS resolution, query failure, and "improper" authority. RFC 1034 [0] 4.2.1. Technical considerations: "One of the goals of the zone structure is that any zone have all the data required to set up communications with the name servers for any subzones. That is, parent zones have all the information needed to access servers for their children zones. The NS RRs that name the servers for subzones are often not enough for this task since they name the servers, but do not give their addresses. In particular, if the name of the name server is itself in the subzone, we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn. To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers." If you alias to some other zone, then you potentially run into a state of gluelessness - expect issues and possibly failures. By using aliases for your NS hosts, you have intentionally moved full resolution of your zone records, as well as those zones dependent on your name servers outside of the ability to have all the data they need in the current authority chain. In addition, a glue record can never be an alias, as this completely defeats the entire purpose of seeding the authority chain. See section 6 of RFC 1034 for details on authority. RFC 1035 [1] 3.3.11. NS RDATA format "NSDNAME A <domain-name> which specifies a host which should be authoritative for the specified class and domain. The NS RR states that the named host should be expected to have a zone starting at owner name of the specified class." NS records should point to a *host* - a host is an A record: 3.2.2. TYPE values "A 1 a host address" If you alias your NS records to some other name server hosts, then your name server will be intentionally stating, "I don't have the expected information you are asking for - go somewhere else and ask..." - expect issues and possibly failures. ============================== OK, enough with RFCs and on to my opinion... >From experience in running large-scale DNS services, the only "real" reason for doing what you wish to do, when you strip out the seemingly logical justifications for doing so, is vanity... You wish to appear to the world, or your vhost customers, or for whatever reason you may have, as personally performing your own DNS services and maintaining a larger infrastructure than you really have. Use the proper NS hosts of the DNS service provider that you are actually using - give them the credit for providing you (in the case of everydns.net, for free (have you donated?)) a robust DNS setup, and have your customers use the proper everydns.net NS hosts, if this is the case. Glue records, authority chaining, forward/reverse records of those in authority, etc. will all be "proper", and you give public props, via whois database entries, to the folks that are actually providing the service and servers you are using. If you absolutely must have vanity NS records pointing to someone else's hosts, they must be A records, and you must provide glue at the TLD name server, if you are using your own vanity NS names for your own domain. Expect serious issues when everydns.net needs to move IP addresses. -- Kind Regards, Michael Shuler [0] http://www.rfc-archive.org/getrfc.php?rfc=1034 [1] http://www.rfc-archive.org/getrfc.php?rfc=1035 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]