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