[dnsdist] dnsdist Action dependant on source IP and queried domain

[Jacob Bunk Nielsen]

Hi

On 25/02/2020 17.37, Jochen Demmer via dnsdist wrote:
> we're trying to make our DNS infrastructure great again. Currently we
> use Bind as recursive servers for our clients (we're a small ISP) and
> nsd for authoritative domains.
> This is what I'm heading to do:
> - run 2+ powerdns servers as authoritative for public domains as well as
> our internal domains
> - run 2+ dnsdist servers as load balancer with regex and ip dependant rules
> - run xyz as recursive nameserver for our dialup / fibre clients
Consider running recursive DNS and authoritative DNS on separate IPs. 
You can still run it through the same dnsdist instance, but by splitting 
it on IPs you can just look at the destination IP to determine which 
backend to send queries to or whether to deny the query or not.
> We have domains hosted for ourselves but also customers. We would like
> to host those with powerdns with replicated postgres. As powerdns does
> not have ACL we plan to run dnsdist in front of the powerdns in order to
> make better decisions what to do with requests:
>
> requests from the www, recursive: REFUSE
> requests from the www, authoritative public domain: forward to powerdns
> requests from the www, authoritative private domain: REFUSE

Take a look at creating network mask group:

https://dnsdist.org/reference/netmaskgroup.html

to match specific source or destination addresses and take actions based 
on that.

> requests from our internal network, recursive: won't happen
> requests from our internal network, authoritative public domain: forward
> to powerdns
> requests from our internal network, authoritative private domain:
> forward to powerdns
>
> The plan is to protect our private domains from being resolved from any
> public IP. Will such kind of filter have big performance implications?
> What is best practice to do so?

It won't, but consider putting them on a separate IP that is not 
internet reachable if you want to be sure to keep it private.

Best regards,

Jacob