Understanding rndc referral statistics

[M. Meadows]

Thinking about this ... perhaps this is more to do with the behavior of BIND 9.3 versus BIND 9.7. Did the referral mechanism change? Here are my thoughts on the subject:

Nameserver A is the authority for zone1.com and it is the authority for sub.zone1.com. Sub.zone1.com is delegated from zone1.com. If a query comes to nameserver A from a resolver asking for info about host.sub.zone1.com and the namserver looks in zone1.com and sees the delegation of sub.zone1.com an inefficient method of handling the query would be to pass back a referral to sub.zone1.com (which just points back at itself). But that would work and would result in a referral. In a more efficient application ... the nameserver would recognize that the delegated authority for sub.zone1.com is ... itself. It would complete the query of host.sub.zone1.com and return an answer instead of a referral. Am I on the right track with this or just wasting my time with wild and inaccurate speculation?


From: sun-guru at live.com
To: bind-users at lists.isc.org
Subject: Understanding rndc referral statistics
Date: Fri, 29 Mar 2013 09:29:13 -0400




Question about rndc referral data. Running BIND 9.3 on an older nameserver and BIND 9.7 on a somewhat newer one. These 2 nameservers sit under a load balancer and get an equal number of queries. While examing rndc output on the 2 nameservers I noticed that the older one does about 100 referrals for every 1 that the newer nameserver does. Can anyone provide insight to explain why this may be happening. Does the newer rndc software calculate referrals differently? The older nameserver runs on Redhat 5.5. The newer one runs CentOS 5.8.

Thanks,
Marty

 		 	   		  

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130329/cd9d2eec/attachment.html>