[dnsdist] Ipv4 and Ipv6 forwarding.

[Michael Van Der Beek]

Hi,

I've gone the route of having two dnsdist servers running.. one for ipv4 and one for ipv6 pointing towards ipv4 and ipv6 ports respectively.
Less rules = less decisions in packet routing.

For the configuration it looks something like this.
I was testing dnsdist on the same server as pdns. Initially I was using the pdns to listen to 192.168.10.10 
(IPs have been changed, and domain names)

setLocal('192.168.10.10:53',{reusePort=true})
addLocal('192.168.10.10:53',{reusePort=true})
addLocal('192.168.10.10:53',{reusePort=true})
addLocal('192.168.10.10:53',{reusePort=true})
addLocal('192.168.10.10:53',{reusePort=true})
addLocal('192.168.10.10:53',{reusePort=true})
addLocal('192.168.10.10:53',{reusePort=true})
addLocal('192.168.10.10:53',{reusePort=true})
setACL({'0.0.0.0/0','::/0'})
controlSocket("127.0.0.1:500")
setECSOverride(true)
setECSSourcePrefixV4(32)
setECSSourcePrefixV6(128)
newServer({address='1.1.1.1:200',pool='auth',useClientSubnet=true})
newServer({address='1.1.1.1:200',pool='auth',useClientSubnet=true})
newServer({address='1.1.1.1:200',pool='auth',useClientSubnet=true})
newServer({address='1.1.1.1:200',pool='auth',useClientSubnet=true})
newServer({address='1.1.1.1:200',pool='auth',useClientSubnet=true})
newServer({address='1.1.1.1:200',pool='auth',useClientSubnet=true})
newServer({address='1.1.1.1:200',pool='auth',useClientSubnet=true})
newServer({address='1.1.1.1:200',pool='auth',useClientSubnet=true})

addAction("test.com",PoolAction('auth'))
addAction("dns_normal.com",PoolAction('auth'))

I needed the useClientSubnet otherwise pdns could not know where the original source IP were from.

In other words drop all packets not part of domains listed
I created a dnsperf with a datafile just listing  ftp.test.com and www.test.com
So it would repeat the queries a lot of times.
dnsperf -d datafile -s 192.168.10.10 -b 1000000 -S 2 -T 4 -c 4 -n 100000000

I was going to add another set of rules for recursor like this to the bottom of the config but I was just testing the auth forwarding performance without the recursor first.
newServer({address='10.10.10.10',pool='recursor'})
newServer({address='10.10.10.10',pool='recursor'})
newServer({address='10.10.10.10',pool='recursor'})
newServer({address='10.10.10.10',pool='recursor'})
recursive_ips=newNMG()
recursive_ips:addMask('10.20.0.0/16')
addAction(NetmaskGroupRule(recursive_ips), PoolAction('recursor'))



Regards,

Michael
-----Original Message-----
From: dnsdist <dnsdist-bounces at mailman.powerdns.com> On Behalf Of Remi Gacogne
Sent: Friday, January 10, 2020 5:06 PM
To: dnsdist at mailman.powerdns.com
Subject: Re: [dnsdist] Ipv4 and Ipv6 forwarding.

Hi,

On 1/10/20 4:07 AM, Michael Van Der Beek wrote:
> The question is. Incoming ipv6 dns queries.. will it forward via the
> authv4 server or the authv6 server IP?

Not by default, but you can write some rules to route queries to different pool based on the address they were initially sent to, using NetmaskGroupRule [1].

> This is for the purpose of statistics.  I want to be able to know how 
> much v4 and v6 queries are arriving.
> 
> As far as I know.. as of 1.4 of dnsdist it does not have v6 statistics.
> So I have to rely on the auth server for statistics.

We do treat v4 and v6 the same way, but if you write the kind of rule I suggested above you will be able to infer the number of v4 and v6 queries from the rules counters.

> One other thing I discovered.. under load testing.
> 
> You can only have 4 threads specified, any more then that it will have 
> almost 0 request to threads >4.
> 
> Where the 4 main threads can be maxed out.

That's more than surprising, but you don't provide your configuration so we don't know which load-balancing policy you are using. The default, leastOutstanding, will try to maximize the cache-hit ratio by sending all queries to a single server, until it struggles (until it has more outstanding queries than the other servers, actually).
If you want a uniform repartition, I'd suggest the use of wrandom or roundrobin instead.

[1]: https://dnsdist.org/rules-actions.html#NetmaskGroupRule

Best regards,
--
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/