DNS hostnames with a duplicate CNAME and A record - which should be removed?

Jimmy Hess mysidia at gmail.com
Fri Oct 19 10:58:36 UTC 2012


On 10/17/12, Landon Stewart <lstewart at superb.net> wrote:
> it's difficult to decide what to do when it's already an issue.  For
> example in RFC 1034 section 3.6.2 the use of CNAME's with NS and MX records
> is not permitted but other research shows this is widely used even though
> its technically invalid.  IMHO it should have never happened in the first

A cached CNAME is used by a DNS resolver without querying for any
other kind of RR.
So,  if there is a CNAME for a label, there cannot be any kind of RR
other than a CNAME,  they produce results  for resolvers that depend
upon which RRs are cached by the resolver.

When a zone is delegated,  there must be  SOA and NS records  in the
child zone presented by the authoritative nameserver.
You will need to perform DNS lookup operations,  and examine the
Additional Section  of the  response, in order to determine what the
appropriate RRs  should be  to replace the CNAME.

> # dig @ns1.superb.net +nocmd mail.customerzone.com A +noques +answer
> ;; ANSWER SECTION:
> mail.customerzone.com. 14342 IN CNAME mail.superb.net.
> mail.customerzone.com. 86342 IN A xx.xx.246.9

In general, the CNAME will replace the name in this case, and the A
record will be silently ignored;    however, If  mail.superb.net.   in
the authoritative  superb.net.  zone  is  not an  A record containing
xx.xx.246.9    for any reason,  then the DNS resolver can have
unpredictable results, that depend on the state of the cache at the
time of the query.

Unless  "mail.superb.net."  is a label in the superb.net. zone   that
contains one A record with an identical RDATA section,  and

You can guarantee that the A record in this zone, is always  updated
in this zone,   whenever   "mail.superb.net."  happens to be changed
or updated,   and nobody ever ever changes  mail.superb.net  while
neglecting to update the A record  of  mail.customerzone.com.


Either the CNAME or the  A record should be nuked in this case;
you have a choice regarding which one  to nuke, and it's important
that you verify  you have the result pointing to the right IP.

> # dig @ns1.superb.net +nocmd superbcolo.biz NS +noques +answer
> ;; ANSWER SECTION:
> superbcolo.biz. 86400 IN NS ns1.superb.net.
> superbcolo.biz. 86400 IN NS ns2.superb.net.
> superbcolo.biz. 86400 IN NS ns3.superb.net.
> superbcolo.biz. 86400 IN CNAME superbenterprise.net.

CNAME'ing an entire zone is definitely not recommended;  this impacts
more than just an A type lookup for  "superbcolo.biz.".   You need a
DNAME instead of CNAME  to  redirect subdomains of an entire DNS zone,
 and there may be limited support in DNS software.

Technically, this would be valid, as long as  superbenterprise.net  is valid,
has  SOA and NS RRs,   AND    no subdomains
or labels  under superbcolo.biz.    such as   "www.superbcolo.biz."  exist.

If you have created SOAs  and NS RRs  for  "superbcolo.biz."     They
are all to be looked up under superbenterprise.net.



> # dig @ns1.superb.net +nocmd superbcolo.biz mx +noques +answer
> ;; ANSWER SECTION:
> superbcolo.biz. 86400 IN MX 10 superbcolo.biz.
> superbcolo.biz. 86400 IN CNAME superbenterprise.net.

The general recommendation here, would be to  DNS lookup superbcolo.biz,
create the missing A and NS records,   and remove the CNAME.

>  dig @ns1.superb.net +nocmd customerzone2.com SOA +noques +answer
> ;; ANSWER SECTION:
> customerzone2.com. 86400 IN CNAME superbenterprise.net.
> customerzone2.com. 86400 IN SOA ns1.superb.net. hostmaster.superb.net.
> 1350501302 0 0 0 0
>
> Should the CNAME just get nuked in all of these cases?


--
-JH




More information about the NANOG mailing list