DNS hostnames with a duplicate CNAME and A record - which should be removed?
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)* * * # 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 # 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. # 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. 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? -- Landon Stewart <LStewart@Superb.Net> Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
On Wed, Oct 17, 2012 at 12:25:49PM -0700, Landon Stewart wrote:
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 -- Andrew Sullivan Dyn Labs asullivan@dyn.com
On Wed, Oct 17, 2012 at 3:25 PM, Landon Stewart <lstewart@superb.net> wrote:
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.
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Landon Stewart <lstewart@superb.net> wrote:
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?
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. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
On 17 Oct 2012, at 15:25, Landon Stewart wrote:
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.
# 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.
Should the CNAME just get nuked in all of these cases?
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.
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. On 18 October 2012 08:49, jeff weisberg <jaw+nanog01@tcp4me.com> wrote:
On 17 Oct 2012, at 15:25, Landon Stewart wrote:
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.
# 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.
Should the CNAME just get nuked in all of these cases?
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.
-- Landon Stewart <LStewart@Superb.Net> Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
On 10/17/12, Landon Stewart <lstewart@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
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
participants (7)
-
Andrew Sullivan -
jeff weisberg -
Jimmy Hess -
Landon Stewart -
Masataka Ohta -
Tony Finch -
William Herrin