I have a recursive DNS server that forwards to my primary DNS servers in order to get a resolution.

Take the example

I have the below CNAME:

server1.example1.com.    300     IN      CNAME   server1.example2.com

And the relevant A:

server1.example2.com     IN     A    X.X.X.X

The problem I’m facing is that the recursive server is returning only the CNAME record when I do a dig and does not answer for the A record. I have verified through a TCP dump that the primaries are definitely returning the CNAME & A records to the recursive, but it in turn does not return them to the dig command or any client pointing to that server. I have other recursive name servers and it works fine. But to note it seems to only happen for cross-domain CNAMES

    bash-4.1# dig @recurisveserver server1.example1.com.                                      

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.5 <<>> @recurisveserver server1.example1.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49412
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;server1.example1.com.           IN      A

server1.example1.com.    300     IN      CNAME   server1.example2.com.

;; Query time: 0 msec
;; WHEN: Mon Mar  5 15:52:31 2018
;; MSG SIZE  rcvd: 76

Nslookup gives a blank response

    > server1.example1.com
Server:  recursiveserver
Address:  x.x.x.x

Name:    server1.example1.com
  • Don't obfuscate what you are publishing to the world anyway. People cannot check it out for themselves and tell you what is happening. You also need to tell people what the proxy DNS server software is that is behaving this way, and how you have set it up. There are possible explanations for this, but there's not anywhere near enough proper information in the question to determine that they are the right answers for the situation at hand. – JdeBP Mar 6 at 19:23
  • You'll need to tell people the IP address, too. Look at unix.stackexchange.com/questions/417101 for just one example of a question that includes the all-important unobfuscated correct IP address that turned out to be the key to the answer. – JdeBP Mar 6 at 19:46
  • "Proxy DNS server" does not apply - the OP is using BIND to do authorative and recursive DNS. – davidgo Mar 6 at 19:53

This all looks correct to me. A CNAME points to another domain name - but it's up to the client to do a second lookup to convert the returned CNAME into an A record - thus you would not expect dig or nslookup to return an IP address.

  • Thanks David, So when when i dig using the same command the only thing different is that im digging @working recursive server i get the proper answer back with cname and A record `;; QUESTION SECTION: ;server1.example1.com. IN A ;; ANSWER SECTION: server1.example1.com. 592 IN CNAME server1.example2.com. server1.example2.com. 1200 IN A 10.x.x.x .......... Also nslookup on the client returns the a record and the resolution works perfect. So i believe it should return the A record to the client Thanks for the help – ryans11 Mar 5 at 19:47
  • 1
    The first glaring indicator that this answer is wrong is that it starts off by talking about URLs. DNS does not work in terms of URLs, and a resolving proxy DNS server, like the questioner has, should perform all of the necessary back-end queries to construct a full answer for the front end. Client libraries are not expected to perform multiple front-end queries. – JdeBP Mar 6 at 19:20
  • @JdeBP Thanks for being picky about an answer which is correct other then for saying URL for domain name - I'll change it. Please also read ryans11 answer carefully - he confirms my answer was correct and helped him ! – davidgo Mar 6 at 19:22
  • @JdeBP - RFC1035 - Section 3.3.1 states "CNAME RRs cause no additional section processing, but name servers may choose to restart the query at the canonical name in certain cases. See the description of name server logic in [RFC-1034] for details." – davidgo Mar 6 at 19:24
  • @JdeBP Further, RFC1035 section 7.2 states "The resolver will usually only have very strong hints about which servers to ask, in the form of NS RRs, and may have to revise the query, in response to CNAMEs, or revise the set of name servers the resolver is asking, in response to delegation responses which point the resolver to name servers closer to the desired information. – davidgo Mar 6 at 19:26

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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