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. 192.0.2.1) 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 192.0.2.2 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
https://blog.powerdns.com/2017/11/30/powerdns-authoritative-server-4-1/
"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:
https://doc.powerdns.com/authoritative/guides/recursion.html
But I would not recommend that level of complexity at customer sites.
Regards,
Brian.
_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users
