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

[Jochen Demmer]

Hi,

you're saying I can use one dnsdist instance bound to different IPs for
all DNS traffic no matter if it's recursive or authoritative and even at
the same time for my protected authoritative domains?
Since there are several thousand domains we host for our customers and a
few protected ones I would have to keep dnsdinst informed about all of
those, right? This is not something I would like to do manually of
course. Without the dnsdist knowing how could it decide where to
redirect the query or even to deny the request in the first place?

Can someone please give a short example of how such an Action could look
like?
I've tried something like this but this is obviously not enough.

addAction(RegexRule(".internal\\.domain\\.net$"), PoolAction("privatezone"))

But this would need a second selector which would be this NMG thing. How
can I combine that?
I also made a small matrix on what shall be done which which requests.
See attached image.

What if I would have an automatic way to maintain the authoritative
domains in dnsdist, wouln't it have a quite big performance impact
because dnsdist would have to check every query target domain in order
to decide what to do with it?

Thank you
Jochen Demmer


Am 26.02.20 um 10:08 schrieb Jacob Bunk Nielsen via dnsdist:
> 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
>
> _______________________________________________
> dnsdist mailing list
> dnsdist at mailman.powerdns.com
> https://mailman.powerdns.com/mailman/listinfo/dnsdist

-- 
Jochen Demmer
System- und Netzwerkspezialist

RelAix Networks GmbH
Auf der Hüls 172
52068 Aachen

Tel.:      0241 / 990001-206
Fax:       0241 / 990001-149
E-Mail:    jdemmer at relaix.net
Internet:  http://www.relaix.net/

Geschäftsführer: Thomas Neugebauer
Amtsgericht Aachen, HRB 15108

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dnsdist_matrix.png
Type: image/png
Size: 17221 bytes
Desc: not available
URL: <http://mailman.powerdns.com/pipermail/dnsdist/attachments/20200227/0aa11c68/attachment-0001.png>