[Pdns-users] pdns-recursor delegate some queries to another recursor
Tobi <jahlives@gmx.ch>
jahlives at gmx.ch
Mon May 20 16:57:52 UTC 2019
Nico
we know of the following reasons from our own experience:
- BGP routing issues (ex from Provider 1 you can reach target and from
provider 2 not)
- per SRC limits on the recipient side
and there for sure are many other reasons we have not experienced (yet) :-)
Thats why we thought it would be nice to offload such queries onto an
other resolver, with another provider or from a different AS
Cheers
--
tobi
Am 20.05.19 um 18:19 schrieb Nico CARTRON:
> Hi,
>
> On 20-May-2019 16:04 CEST, <pdns-users at mailman.powerdns.com> wrote:
>
>>> wonder if the following is possible somehow with pdns-recursor. Our main
>>> recursor A sometimes has problems talking to some auth servers. In the
>>> same time another recursor B in our network still can talk to such an
>>> auth server.
>>>
>>> So we wonder if we could somehow send queries for such auth servers via
>>> the other recursor. The decission to send queries to the other box is
>>> based on the IP address of the auth server. The idea is to route such
>>> queries from recursor A to recursor B while all other queries from
>>> recursor A should still be sent without recursor B.
>>>
>>> Is something like that possible in pdns-rescursor or do we have to use a
>>> tool like dnsdist?
>>
>> Hi Tobi,
>>
>> I recommend using dnsdist for this use-case! Sending traffic to backend dns
>> servers is what dnsdist is made for!
>
> While it's true that what Frank suggested is totally doable with dnsdist (and
> actually one of its missions), it would be interesting though to understand why
> one of your recursors has issues to reach the authoritative server, and another
> recursor has no issue.
>
> A couple of questions:
> - are they running the same Recursor version?
> - are they on the same network / same site / faced by the same network
> equipments, if any (e.g. firewall) / any ACL in place
> - which OS are they running (if differences between the 2)
>
> Cheers,
>
More information about the Pdns-users
mailing list