8

When a resolver looks up a CNAME, the resolver apparently first sends an A record request to the DNS server. Is the DNS server supposed to figure out that the request is actually for a CNAME, or is the resolver supposed to retry the request, but for a CNAME type? I ask because - and here is the twist - we have an "internal" top level domain we use on our internal LAN, let's call it "domain1", and the DNS server I am querying is the authoritative server for "domain1" (and is recursive for everything else.) What my host (Centos 6.8) actually sends out is a request for an A record:

16:15:45.837525 IP (tos 0x0, ttl 64, id 36911, offset 0, flags [none], proto UDP (17), length 62)
myhost.domain1.40684 > dnsserver.domain1.domain: 15355+ A? cfengine.domain1. (34)
Reply - a servfail:
16:15:45.837762 IP (tos 0x0, ttl 64, id 49982, offset 0, flags [DF], proto UDP (17), length 62)
dnsserver.domain1.domain > myhost.domain1.40684: 15355 ServFail 0/0/0 (34)

If I do a dig for a CNAME type, I get the correct CNAME record (although the A rec is not returned as ADDITIONAL data):

cfengine.domain1.   3600    IN  CNAME   helm02.domain2.

Yes, I know it's poor practice to combine authoritative and recursive functions into a single DNS server, but I don't have control over this DNS setup.

First of all, if authoritative and recursive functions are combined into a single server, and you send a recursion desired query to the server for a CNAME the server is authoritative for - is it even supposed to work?

Assuming it's supposed to work, who is responsible for figuring out my request is actually for a CNAME record and not an A record? The DNS server, or my resolver?

wsanders
  • 81
  • 1
  • 3
  • UPDATE: This question is very similar to http://serverfault.com/questions/111430/must-the-authoritative-dns-server-for-a-domain-allow-recursion-to-allow-cname-re. In addition, in our case the authoritative DNS server is PowerDNS (ugh again). So it appears that PowerDNS still sends a servfail when it is sent a CNAME query for a zone it is authoritative for and the RHS of the CNAME record points outside of the zone. The workaround is to not use PowerDNS in a mixed authoritative/recursive setup. – wsanders Feb 16 '17 at 18:05
  • This has nothing to do with PowerDNS specifically. – Andrew B Feb 16 '17 at 22:00

2 Answers2

5

If a server is authoritative for a certain name, has a CNAME record for that name it must respond with that record to queries for all record types.

If a server is doing a recursion, asks for a record type that is not CNAME, but gets a CNAME response, then it should restart the query with the name from the CNAME record, merge the response from the restarted query with the CNAME response and return the combined response to whoever it was doing the recursion for.

Differently put, the authoritative server is responsible for knowing that a name has a CNAME and to respond with that to all queries, and the recursor is responsible for noticing that it got a CNAME back when asking for something else and for acting accordingly. If you specifically ask for a CNAME record, you bypass this extra magic and the recursor will just give you the CNAME response as is without trying to follow the name.

Calle Dybedahl
  • 2,083
  • 12
  • 17
  • I noticed some servers will attach a "glue" of sorts in the answer section that links to the target of the CNAME. I've only seen it used for A/AAAA, but could it also return other records like TLSA, etc? If that was the type in the original request? – pinhead Jul 06 '20 at 20:52
1

The SERVFAIL should go away if you try that query again with +norecurse. dig assumes recursion is desired by default, and SERVFAIL is the correct response to return if recursion was requested and it was not possible to resolve the target of an alias.

Recursive servers which query your authoritive server should not be making the request with the recursion desired (RD=1) flag set. In short, you should only see this problem in the following two scenarios:

  1. You are running this transaction by hand and forgetting to disable recursion.
  2. Someone has written a (poor) implementation of a recursive nameserver and the author has neglected to unset the recursion desired flag when performing authoritative lookups. A recursive nameserver should not be asking authoritative servers to perform recursion on its behalf.
Andrew B
  • 31,858
  • 12
  • 90
  • 128
  • I've set up a BIND recursive-only named on my local host that forwards to the authoritative nameservers for domain1 as follows: zone "domain1." IN { type forward; forwarders { 10.7.53.26; 10.7.53.128; 10.7.53.131; } ; }; But a dig @localhost for cfengine.domain1. to this local nameserver still causes named to send out a request for an A record with rd set to the authoritative nameserver. Is there some zone file option I have not found yet that will tell my local named that the forwarder is authoritative for the zone? – wsanders Feb 17 '17 at 01:23
  • One workaround that works is to set up the recursive-only named as a slave for domain1. It would appear that a forwarder always gets the rd flag set. – wsanders Feb 17 '17 at 01:46
  • Hmm, I'll recheck the forwarder behaviors tomorrow. I was under the impression that forwarders didn't set `RD=1`, but I may have confused that behavior with stub zones. – Andrew B Feb 17 '17 at 02:55