Using proxy DNS servers for bind as an alternative to slave servers.

Kevin Darcy kcd at chrysler.com
Mon Jul 2 21:35:35 UTC 2012


On 7/1/2012 2:42 PM, J P wrote:
> Hello all!
>
> I understand RFC compliant DNS servers use AXFR and IXFR for synching 
> bewteen masters and slaves... and that this is the general scenario 
> for that purpose.
>
> However, I need somebody to technically explain to me why cant I use a 
> DNS resolver daemon such as the pdnsd  dns proxy daemon with a cache 
> of for example 5 minutes... so I can configure it to forward requests 
> to my master (where I feed and store my zones), with the cache being 5 
> minutes then iam sure the latency between my master and the proxy will 
> be minimal.
>
> Is this possible why yes or why not.
>
I don't really know much about pdnsd, so I have a simple question for 
you: does pdnsd answer with the AA (authoritative answer) bit set or not?

If it does, and it doesn't have a full copy of the zone at all times, 
then it is violating the DNS spec and all bets are off as to how well 
that will play with iterative resolvers.

If it doesn't, then its answers are likely to be rejected by iterative 
resolvers, who want to see that bit set on the responses.

The bottom line is: don't pretend to have a full, replicated copy of the 
zone if you don't have a full, replicated copy of the zone. Now, 
strictly speaking, you don't have to use AXFR/IXFR to do the replication 
-- some people prefer configuring all their "slaves" as "type master" in 
named.conf and then using some other non-DNS-standards-defined method to 
do the replication (e.g. rsync or scp, combined with a "rndc reload" to 
read the contents back in each time). Many commercial DNS management 
products use other methods to replicate the data (QIP uses its "message" 
subsystem; Infoblox uses "grid replication"). But calling a mere cache 
or "proxy" a "slave" is just asking for trouble...

                                                 - Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120702/c30fa844/attachment.html>


More information about the bind-users mailing list