On 25/01/2018 16:50, Alain RICHARD wrote:
Also about your example of a customer move the domain to an other, I
don’t think this is solve by the separation of recursor and auth
server as you will have to remove the forwarding zones from the
recursor and/or the dnsdist processes in order to corre
Hi Brian,
I completly agree with you that it make sense for medium to large ISP needs to
separate resolver from auth servers for several reasons.
My point was that the powerdns architecture and its good API make it a very
interesting for small ISP or small to medium size enterprises : you may h
On 23/01/2018 08:09, Alain RICHARD wrote:
I well know the scenario 3, but it means to either reconfigure the clients to
point to the new DNS recursor, or reconfigure the domains and masters/slave
servers in order to point to the new DNS auth.
That's correct.
There are several reasons why it i
I well know the scenario 3, but it means to either reconfigure the clients to
point to the new DNS recursor, or reconfigure the domains and masters/slave
servers in order to point to the new DNS auth.
My point here is not technical, I well know theses possibilities. The problem
is that on 90% o
On 19/01/2018 17:36, Alain RICHARD wrote:
Scenario 1 : the recursor is on port 53 and forward queries from
known zones to the authoritative pdns on port 5300
Scenario 2 : the dnsdist is on port 53, forward queries from known
zones to the authoritative pdns on port 5300, and forward recursive
Hi,
I am using up to now pdns-4.0.x and pdns-recursor-4.0.x as a simple replace for
bind installations at customers sites.
The setup I am using is to keep master/slave replication as I need to replicate
zones from other master servers (linux or windows) and the DHCP server is doing
dynamic DNS
