Re: DNS CNAME question
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
Reply to: