[Pdns-users] How to set up pdns to allow NOTIFY, supermaster, and recursion to work?

[Brian Candler]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20191104/df5ea9eb/attachment.htm>