Hello!
I am aware that the solution I am aiming for is not the optimum.
However, I use fly.io as a platform where I have already distributed DNSDIST
containers to over 20 locations with Anycast IP.
The problem comes with the limitations of the fly - one app is bound to a set
of IPs. You can not
Hello Bernd,
* Bernd KLAUS via dnsdist [230107 11:01]:
> Regarding:
> „ My first suggestion would be to not need to do the name based
> forwarding by separating the incoming recurosr and auth traffic on ip
> address or port“
>
> So i should forward all querys to the recursor?
I believe the best
Hy Otto,
Thanks for your Feedback.
I will look into the KV thing.
Regarding:
„ My first suggestion would be to not need to do the name based
forwarding by separating the incoming recurosr and auth traffic on ip
address or port“
So i should forward all querys to the recursor?
BR Bernd
> Am 07.
Hi,
My first suggestion would be to not need to do the name based
forwarding by separating the incoming recurosr and auth traffic on ip
address or port. If that is not feasible, take a look at
https://dnsdist.org/reference/kvs.html
Have a process update the kv-database and dnsdist can use that t
Hello!
I have a question regarding the architecture of DNSDIST in front of an
authorative pdns instance as well as an recursor.
I`ve looked at: https://doc.powerdns.com/authoritative/guides/recursion.html
- however, the solutions described are kind of static.
Eg. Domains send to the auth-inst
