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

Mailman List Mirror (Read Only)
1

Hi Y'all Nanogites,

We are changing over to PowerDNS from djbdns (tinydns) and I'm taking this
opportunity to fix as much of our zone data as we can. Under tinydns
things work fine despite these errors because tinydns lets you get away
with stuff like this and still responds even though a zone might
technically be broken because of it.

The problem is that we have some zones that have records with the same
hostname that have both a CNAME as well as an A record, MX record, SOA
record and/or NS record. Is there an easy answer for what should be
removed? I'm inclined to say that the CNAME should be removed in all these
cases but I can't find any definitive information on this and after doing
some tests it doesn't always seem straightforward.

I've been reading various sites and information including RFC 1034 but
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
place (where an A record already exists a CNAME should not have been
allowed to get added for example) but what can be done now that it's
already an issue?

In the case of the A,NS,MX,SOA and CNAME duplicates an example of how our
old/current name server's responses are:
(*note: not all of this is real data, customer zones have been obfuscated)*

2

hostname that have both a CNAME as well as an A record, MX record, SOA
record and/or NS record. Is there an easy answer for what should be
removed?

"You should remove the one that you don't need." A CNAME may not be
at the same owner name as any other RR. If you need an alias, then
you want a CNAME. If you need some other record, you need not to have
a CNAME.

If you think about what a CNAME is, it is obvious that it can't exist
at the same name as any other RR, because it says "this name is
actually that name over there".

Should the CNAME just get nuked in all of these cases?

Probably.

A

3

If you have a CNAME record for a particular name, you should not have
any other record of any type for that same name. Which you should
remove depends on the details of the particular circumstance. If you
really mean "identical to that other name with respect to all records
and record types" then there's nothing inherently wrong with the
CNAME. If you don't, then you shouldn't use a CNAME there.

Regards,
Bill Herrin

4

You can never have a CNAME record at a zone apex, because a zone apex has
to have SOA and NS RRs and a CNAME can never coexist with other RRs. So
those cases are simple.

If the misconfigured CNAME is not at a zone apex then you have to decide
whether the CNAME or the other records are correct - do you get the right
result from the DNS when deleting one or the other? If it works either way
then your decision mainly depends on how frequently the target address
changes and if you need to make co-ordinated changes across many zones -
if so then a CNAME tends to be preferable. But you probably have to have a
workaround for A records at zone apexes in which case that tooling
probably removes CNAMEs' advantage and you might as well use A records
everywhere.

Tony.

5

no.

if you nuke them, you'll break something.

you're going to need to go through them all one by one, figure out
why the CNAME is there, what it is doing, and how to change it.

for example, "superbcolo.biz" has an MX and CNAME. the CNAME
points to "superbenterprise.net", which has an A, and that A
has a web server running.

it may be "wrong", but http://superbcolo.biz works. so in this
case, you'd need to replace the CNAME with the A. otherwise,
you're breaking someone's website. which might be bad.

6

Thanks for all your replies.

I'm going to have go through these records and resolve these issues by
evaluating them one by one since there doesn't seem to be any quick and
dirty rules to any of them.

7

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.

8

Landon Stewart wrote:

I've been reading various sites and information including RFC 1034 but
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
place (where an A record already exists a CNAME should not have been
allowed to get added for example) but what can be done now that it's
already an issue?

The rule of RFC1034 is not applicable to secure DNS.

W.r.t. RFC1034, the following text:

  The one exception to this rule is that queries which match
  the CNAME type are not restarted.

is the key.

For name servers, any RR types which may coexist with CNAME must
also match CNAME. In addition, for queries with such RR types,
cached CNAME without cached exact RR types should be ignored.

In the case of the A,NS,MX,SOA and CNAME duplicates an example of how our
old/current name server's responses are:
(*note: not all of this is real data, customer zones have been obfuscated)*

SOA and NS could have matched CNAME, which enables a zone
containing just a CNAME, though RFC1034 does not specify so.

It is not harmful except that queries with SOA or NS type may
cause loops if some cache have CNAME RRs.

            Masataka Ohta