[Pdns-users] powerdns 4.1 recursive queries architecture change

Brian Candler b.candler at pobox.com
Tue Jan 23 08:58:54 UTC 2018

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 is best practice to separate your 
nameservers (even when using bind, you should have two separate 
instances).  In my experience, the number one problem with mixing 
recursor and auth at ISP scale is when people move their domains away.

Suppose a customer has their domain "example.com" on your DNS service.  
Some time later they move the domain away to a different ISP, changing 
the delegating in the registry without telling you. This leaves you with 
an old, stale authoritative zone on your DNS.

If the caches and authoritative are the same boxes, then *your* 
customers will still be seeing data from the stale zone, whilst the rest 
of the Internet sees the correct data for example.com.  This can lead to 
problems which are really hard to debug; e.g. your customers can't send 
mail to example.com, but example.com is unaware of any issue (because 
mail works fine to everyone else).  So it hits *your* support desk.

However, if your auth and recursors are separate, there is no problem.  
Your recursors follow the delegation to the new authoritative servers at 
the other ISP; and nobody ever queries the stale example.com zone on 
your authoritative server, because there is no delegation to it.

The number two reason is usage patterns.  DNS resolvers use lots of RAM 
and churn it hard; DNS authoritative servers have a very small memory 
footprint.  If your DNS resolver crashes for some reason, you don't want 
your authoritative DNS to fail.  If they are separate, they are much 
easier to manage and scale.

If you have combined DNS, and you grow, eventually you'll need to take 
the hit of separating them.

Changing clients is usually the simplest thing.  For those on DHCP it's 
trivial.  Anything which is statically configured you can do one machine 
at a time, and run a packet capture on the old IP address until you see 
no more clients using it.

If you are serving only a small number of authoritative domains, and you 
control them all, then you might find redelegating them to be easier.  
Note that recursor clients are configured to point to an IP address 
(e.g. while authoritative DNS is delegated to a name (e.g. 
ns.example.com).  So you can change the A record for ns.example.com to 
point to without affecting the recursor clients.  If the 
nameserver record is inside the domain being delegated, you'll need to 
update the glue record as well.

You could also consider moving your customers' authoritative DNS into 
some central service that you manage, and just leave caches on the 
customer sites.
> The problem is that on 90% of installations (generally bind installations), the sites are using the same addresses for auth and recursor function.
I think you made that percentage figure up, but it depends anyway on 
what type of site you are talking about.

PowerDNS is primarily designed for large-scale ISP operation.  It works 
very well in small setups too, but as of 4.1 it requires that you follow 
the number one rule of ISP-scale DNS, which is to keep authoritative and 
recursive servers separate.

As it says at 
"This will impact many installations, and we realize this may be 
painful, but it is necessary."

> So for me the problem is do I still can use powerdns as replacement for bind without reconfiguring the whole DNS setup on curstomer’s sites.

Then of course, feel free to stick with BIND if it meets your needs better.

If you *really* want to use PowerDNS authoritative and recursor on a 
single IP and port, then the migration guide shows how to use dnsdist in 
front, and distribute queries to either recursor or authoritative server 
based on client source IP address:


But I would not recommend that level of complexity at customer sites.



More information about the Pdns-users mailing list