On 04/11/2019 22:07, Steve Shipway wrote:
The problems with having two IP addresses are that then I need two IPs
going through all the various firewalls (more trouble for setup and
migration)
You need access to the resolver IP from your clients (end-users, servers
etc), and access to the authoritative IP from your recursors.
plus, which do you use for the zone NS records?
The authoritative server only.
You have to have something like ns0, ns1 pointing to the recursor
(for clients to use) and ns0a ns1a in the NS records pointing to the
resolver...
Clients always configure their resolver using IP addresses, not domain
names - otherwise you have the chicken-and-egg situation (how do you
resolve the name to an IP, when you can't yet reach your recursor?)
The NS records are used by the recursor, to find the authoritative server.
You end up with a different IP for the clients to use from the one
the NS records use, and queries could be coming in to either.
Clients always talk to the resolver. Resolvers talk to the
authoritative nameservers. There's no ambiguity.
This also doesn't address the problem of the recursor not being able
to automatically know which zones to pass on to the resolver - if you
add a zone to the resolver, you need to reconfigure the recursor to
find it, else it might end up using the external nameserver by accident.
You want split or hidden DNS - that is, names which can only be resolved
by your internal clients, but not resolved by the outside world?
In that case, yes, your recursor needs to be told for those domains
where the authoritative servers are, since it can't follow the public NS
records. With pdns recursor you can store the list of domains to
forward in a file.
Then dnsdist, seems to be necessary to forward notify packets on to
the resolver as the recursor just drops them.
Were you thinking dnsdist in front of recursor, or dnsdist in front of
authoritative?
I wouldn't use either. dnsdist would still need to know which domains
are hidden/internal (hence need to go to the internal auth servers) with
everything else going to the public DNS.
I can see why an ISP, handling many queries and needing huge scale
There are a whole bunch of reasons, and there's a link to an article by
djb by this. Partly it's because of different resource requirements:
recursors need lots of RAM, authoratitive servers need some sort of
database.
But I'll briefly explain another important issue.
Let's say your customer registers a domain foo.com, and you install it
on your nameservers. On the public Internet, foo.com is delegated to
them; and your customers also use these nameservers as a cache.
Some time later, your customer moves to a different ISP. Without
telling you - since they're not your customer any more - they move
foo.com to another ISP's nameservers. That is, the NS records now point
to different nameservers.
However, you still have foo.com on your nameservers. If those
nameservers are also being used by your own customers as recursors, then
they will see the *old and stale* data for that zone. The owner of
foo.com may change the zone, e.g. to move a webserver to a different IP,
but your own customers see the old data.
This ends up with a bug which is really hard to debug. Your customers
contact the owners of foo.com and say "I'm having trouble getting to
your website". They check, and everything is fine. Your customer
contacts you, and says they're having problems accessing the Internet.
You check, and everything looks fine. Eventually your customer, who
realises that every other ISP can resolve foo.com properly except you,
leaves.
, would want to do this; but it is a horrible amount of complexity for
small organisations that just want the benefit of the API and are
otherwise fine with bind running on a small linux VM. It would have
been better to have had the option to run in split mode (for large
ISPs) or combined mode (for small organisations) rather than just
supporting large setups only.
That would add unnecessary complexity to the powerdns code, reduce
performance, and make maintenance harder.
If you want to continue to use bind, you are of course free to do so.
Bind is the kitchen sink of nameservers, and doesn't have a great track
record when it comes to security, but it does have a lot of functionality.
Regards,
Brian.
_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users
