How should tinydns handle CNAMEs?
-
Hello all,
I am currently trying to set up authoritative DNS for a school's domain using a pfsense machine. At the moment authoritative DNS is being handled by an existing openBSD server, but the existing server is old and showing signs of hardware failure which is why I am replacing it with a new server running pfsense.
I have installed tinydns and added a few subdomains, and for the most part it seems to be working properly. However, it seems to be handling queries for CNAME records differently from the old server, and the problem is that I'm not sure which server is exhibiting the "correct" behavior.
The domain has tons of CNAME records, some of which point to other CNAME records in a chain. For example, a.example.com is a CNAME record pointing to b.example.com, which is a CNAME record pointing to c.example.com, which is a CNAME record pointing to d.example.com, which is finally an A record pointing to an IP address. (I know this is bad practice, but it's an issue I will worry about at a later time).
When I query the existing server using the "dig" command for one of these CNAME domains, the existing server will continue resolving until it reaches an A record, as shown below:
;; QUESTION SECTION: ;a.example.com. IN A ;; ANSWER SECTION: a.example.com. 1200 IN CNAME b.example.com. b.example.com. 1200 IN CNAME c.example.com. c.example.com. 1200 IN CNAME d.example.com. d.example.com. 1200 IN A XX.XX.XX.XX
However, when I send the same query to the pfsense server, it only responds with the next CNAME:
;; QUESTION SECTION: ;a.example.com. IN A ;; ANSWER SECTION: a.example.com. 3600 IN CNAME b.example.com.
The way pfsense is doing it, the client would have to repeatedly send queries until it finally finds the A record, whereas the existing server would automatically perform all of the necessary CNAME lookups. Which server is doing it the "correct" way? Is there a way to make pfsense do all the necessary CNAME lookups automatically like the existing server does?
Thanks in advance!
EDIT:
I noticed that authoritative nameservers for major websites (like Yahoo and Wired) behave just like pfsense; i.e. they only provide the next CNAME record in the chain and do not automatically resolve to the IP address. I presume this means I can leave the pfsense box as is? -
"whereas the existing server would automatically perform all of the necessary CNAME lookups. "
So your doing a recursive query? Is recursion available?
You don't show the header information your query that would show it being recursive and denied or allowed, etc.. How is this other server setup? What I do agree with is bad practice chaining cnames..
So you mention major websites and authoritative NS - yeah those are not going to allow recursion very often. Example if we ask yahoo ns for www.yahoo.com you notice we get info back, not no actual A record and not even the full cname chain.
But if I ask my pfsense box that will do the recursion for me it gives back the recursive information.
C:>dig @ns1.yahoo.com www.yahoo.com
; <<>> DiG 9.10-P2 <<>> @ns1.yahoo.com www.yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65443
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3
;; WARNING: recursion requested but not available;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1272
;; QUESTION SECTION:
;www.yahoo.com. IN A;; ANSWER SECTION:
www.yahoo.com. 300 IN CNAME fd-fp3.wg1.b.yahoo.com.;; AUTHORITY SECTION:
wg1.b.yahoo.com. 172800 IN NS yf4.a1.b.yahoo.net.
wg1.b.yahoo.com. 172800 IN NS yf3.a1.b.yahoo.net.
wg1.b.yahoo.com. 172800 IN NS yf2.yahoo.com.
wg1.b.yahoo.com. 172800 IN NS yf1.yahoo.com.;; ADDITIONAL SECTION:
yf1.yahoo.com. 86400 IN A 68.142.254.15
yf2.yahoo.com. 86400 IN A 68.180.130.15;; Query time: 18 msec
;; SERVER: 68.180.131.16#53(68.180.131.16)
;; WHEN: Fri Dec 26 09:02:50 Central Standard Time 2014
;; MSG SIZE rcvd: 187C:>dig @pfsense.local.lan www.yahoo.com
; <<>> DiG 9.10-P2 <<>> @pfsense.local.lan www.yahoo.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30379
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.yahoo.com. IN A;; ANSWER SECTION:
www.yahoo.com. 244 IN CNAME fd-fp3.wg1.b.yahoo.com.
fd-fp3.wg1.b.yahoo.com. 24 IN A 98.138.252.30
fd-fp3.wg1.b.yahoo.com. 24 IN A 98.139.183.24
fd-fp3.wg1.b.yahoo.com. 24 IN A 98.138.253.109
fd-fp3.wg1.b.yahoo.com. 24 IN A 98.139.180.149;; Query time: 5 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Fri Dec 26 09:03:04 Central Standard Time 2014
;; MSG SIZE rcvd: 142C:>
Notice how yahoo denied my recursion request, while when I query my local pfense I asked for recursion rd, and got back that it allows for recursion ra. So depending on how your setup, what the ns allows you to do, etc. You may or may not get back a full listing of cnames in a chain.. I would redo the dns so that your not doing a lot of cname changes - as you already know its bad practice.
-
So your doing a recursive query? Is recursion available?
You don't show the header information your query that would show it being recursive and denied or allowed, etc.. How is this other server setup? What I do agree with is bad practice chaining cnames..
Interestingly both the existing server AND the pfsense machine return
WARNING: recursion requested but not available.
So you mention major websites and authoritative NS - yeah those are not going to allow recursion very often. Example if we ask yahoo ns for www.yahoo.com you notice we get info back, not no actual A record and not even the full cname chain.
So basically you're saying that what pfsense is doing is normal, so it's best to leave it as is?
-
I don't think tinydns does any recursion at all by design. It is designed to be authoritative. It's generally accepted that separating your recursive, caching servers from your authoritative zones is the way to do it.
-
Great, in that case I will leave it as is.
Perhaps I should start another thread for this, but I have another quick question: The domain I am working with has a secondary authoritative nameserver located off site, which I don't have access to. In general, how do secondary nameservers sync up with the primary nameserver? Will I need to do anything in pfsense to allow the secondary server to sync, or will it happen automatically?
-
they use zone transfers to sync up.. Yes you would have to setup tinydns to allow the zone transfers, and open up access on pfsense from this remote pc. Zone transfers are normally done over tcp 53.
-
Awesome, I have allowed the IP address of the secondary server to do zone transfers and added a firewall rule allowing inbound 53 TCP. Thanks guys!