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

2012-07-01 Thread J P

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.

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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

2012-07-01 Thread btb

On 07/01/2012 02: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.


a couple of things come to mind.  there are probably other issues as 
well.  to begin with, if this other server is not actually loading the 
zone itself, and is just forwarding all requests to your master, you'd 
need to somehow get this other server to answer those requests 
authoritatively.  i don't know how pdnsd dns proxy daemon works, but 
air, the software i'm familiar with does not answer authoritatively for 
that sort of configuration.


second, even if you could get the software to sort of lie and answer 
authoritatively, you're losing largely all of the benefits of a slave 
nameserver by doing something like this.  if you "cached" data for five 
minutes [which raises another question as to how you would do this - i 
hope not by using a ttl of 5 minutes for all records on the master], 
then any changes you made would not be reflected on this server for up 
to five minutes - whereas if it were a properly configured slave, the 
changes would be reflected immediately.  additionally, were the master 
to become unavailable, this other server would only be able to answer 
queries for five more minutes, at which point it's cache would expire 
and it would have no server to get answers from.  in contrast, an actual 
slave nameserver is typically configured to continue serving the zone 
for much longer than five minutes if the master becomes unreachable 
[generally weeks, at least], regardless of the ttls for the individual 
records that might be served.


in terms of latency, i'm not quite sure what you're getting after, but 
there is, for all intents and purposes, no latency in a traditional 
master/slave environment [if nothing else, certainly magnitudes smaller 
than five minutes].


having additional nameservers which become basically useless if the 
master has a problem doesn't make much sense to me.  my suggestion would 
really be to take a bit of a different philosophical approach, and 
instead of pursuing an abnormal environment unless there is some 
prohibitive aspect, just pursue a normal, tried and tested environment 
unless there is some genuine reason why you can't.  if there is some 
aspect of a traditional master/slave [or some variation thereof] 
environment that you're concerned might pose issues, my recommendation 
would be to just ask about that.


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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


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

2012-07-02 Thread Kevin Darcy

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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users