Allowing resolution of off-server CNAMEs

[Chris Buxton]

On Jul 8, 2011, at 9:11 AM, Joseph S D Yao wrote:
> I'd rather that recursion controls only control recursion.
> And not forwarding - have separate forwarding controls, says I.

Forwarding is a response to a recursive query. For an iterative query, even if you have recursion enabled, the server won't forward the query. Therefore, it is logical that it be controlled with the same settings as recursion.

What problem are you trying to solve? A dangling CNAME such as you describe is a normal behavior that caching resolvers are easily able to follow.

> I started with this:
> 
> view all {
> 	match-clients { any; };
> 	allow-query { any; };
> 	allow-query-cache { any; };	// Only on those RHEL servers
> 					// which allowed it (*sigh*)
> 	allow-recursion { none; };
> 
> 	zone "tld.example" {
> 		type master;
> 
> 		file "data/zone.tld.example";
> 	};
> };
> 
> zone.tld.example:
> $TTL	3h
> @	SOA	...
> @	NS	ns1.tld.example.
> @	NS	ns2.tld.example.
> sub	NS	ns1.sub.tld.example.
> sub	NS	ns2.sub.tld.example.
> ns1	A	...
> ns2	A	...
> ns1.sub	A	...
> ns2.sub	A	...
> target	CNAME	target.sub
> 
> 
> In this case, trying to look up target.tld.example directly from
> ns1.tld.example just gets you the CNAMEs but no A record.

This is normal and expected. The recursing resolver will then work on the CNAME's target; your server will provide a referral to the subdomain, which means just one more query should net it the final answer. This works, unless you have some special reason why it won't in your case.

Consider the resolution path of www.apple.com. This involves several of these dangling CNAME records in series, where the target is not in the same domain and therefore the authoritative name server for each CNAME does not give a referral. And yet it works just fine.

$ dig www.apple.com +norec @nserver.apple.com

; <<>> DiG 9.8.0-P2 <<>> www.apple.com +norec @nserver.apple.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57811
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.apple.com.			IN	A

;; ANSWER SECTION:
www.apple.com.		1800	IN	CNAME	www.isg-apple.com.akadns.net.

;; Query time: 21 msec
;; SERVER: 17.254.0.50#53(17.254.0.50)
;; WHEN: Fri Jul  8 10:23:36 2011
;; MSG SIZE  rcvd: 73

$ dig www.isg-apple.com.akadns.net +norec @usw2.akadns.net

; <<>> DiG 9.8.0-P2 <<>> www.isg-apple.com.akadns.net +norec @usw2.akadns.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52429
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.isg-apple.com.akadns.net.	IN	A

;; ANSWER SECTION:
www.isg-apple.com.akadns.net. 60 IN	CNAME	www.apple.com.edgekey.net.

;; Query time: 77 msec
;; SERVER: 64.211.42.194#53(64.211.42.194)
;; WHEN: Fri Jul  8 10:24:31 2011
;; MSG SIZE  rcvd: 82

$ dig www.apple.com.edgekey.net +norec @usw6.akam.net

; <<>> DiG 9.8.0-P2 <<>> www.apple.com.edgekey.net +norec @usw6.akam.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1407
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.apple.com.edgekey.net.	IN	A

;; ANSWER SECTION:
www.apple.com.edgekey.net. 21600 IN	CNAME	e3191.c.akamaiedge.net.

;; Query time: 16 msec
;; SERVER: 96.17.144.195#53(96.17.144.195)
;; WHEN: Fri Jul  8 10:25:07 2011
;; MSG SIZE  rcvd: 76

$ dig e3191.c.akamaiedge.net +norec @n8c.akamaiedge.net

; <<>> DiG 9.8.0-P2 <<>> e3191.c.akamaiedge.net +norec @n8c.akamaiedge.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57748
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;e3191.c.akamaiedge.net.		IN	A

;; ANSWER SECTION:
e3191.c.akamaiedge.net.	20	IN	A	184.85.109.15

;; Query time: 23 msec
;; SERVER: 69.22.163.131#53(69.22.163.131)
;; WHEN: Fri Jul  8 10:25:43 2011
;; MSG SIZE  rcvd: 56

Regards,
Chris Buxton
BlueCat Networks