Is it allowed to have an NS record be a CNAME? E.g.:

subdomain.example.com.       IN NS  ns1.example.com.
ns1.example.com.             CNAME  foo.example.com.
foo.example.com.             IN A

This doesn't seem to work in bind though this (of course) does:

subdomain.example.com.       IN NS  foo.example.com.
foo.example.com.             IN A

Any pointers to RFCs prohibiting this setup would be appreciated.

1 Answer 1


RFC 1035 defines the NS resource record (RR) merely as a domain-name without specifying the RR type of the target (though it does make it clear that it can't be an IP).

RFC 1912 has more specifics, in section 2.4:

Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers. In fact, current BIND implementations will ignore such records, possibly leading to a lame delegation. There is a certain amount of security checking done in BIND to prevent spoofing DNS NS records. Also, older BIND servers reportedly will get caught in an infinite query loop trying to figure out the address for the aliased nameserver, causing a continuous stream of DNS requests to be sent.

As was later pointed out in the comments, RFC 2181 Section 10.3 has a clear prohibition against this:

MX and NS records

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

  • 5
    And RFC1034 says, "Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information....Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error."
    – larsks
    Jan 14, 2011 at 19:57
  • 14
    I found that RFC 2181 10.3 clearly says that it is invalid but your answer was good enough. Jan 14, 2011 at 21:01
  • 2
    For added clarity: MUST NOT verbiage doesn't matter here because RFC 1912 is Informational and does not define a standard. Mark is correct that RFC 2181 is the correct reference. (RFC 1034 was written before the language standards solidified, hence the vagueness)
    – Andrew B
    May 16, 2016 at 21:52
  • 1
    I've just submitted an update to the answer to clearly quote RFC 2181, I hope that's OK. As of today, in Nov 2021, I had attempted to point a domain NS record to a CNAME but discovered weird DNS failures on some servers (while others worked fine), and found this to be the cause. Changing the CNAME's to A records fixed the problem instantly. So while some servers may allow it, I'd definitely avoid it.
    – Simon East
    Nov 5, 2021 at 4:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.