> On 21 May 2019, at 12:06, Tobi wrote:
>
> Hi Frank
>
> fully agree that this is very very very ugly. We never considered this a
> "longterm" solution but just as a temporary fix until the problem is
> solved upstream.
>
>> I managed an MSP for more than 15 years, we moved a lot of email as
Hi Frank
fully agree that this is very very very ugly. We never considered this a
"longterm" solution but just as a temporary fix until the problem is
solved upstream.
> I managed an MSP for more than 15 years, we moved a lot of email as
> well, so I feel your pain.
then you know its very hard t
Hi Tobi,
I managed an MSP for more than 15 years, we moved a lot of email as well, so I
feel your pain.
However, in all cases (about a hand-full that I can recall over that time)
where we had real reachability issues, we routed the other AS using a different
network path. In BGP speak: we pref
Brian
> In any case, it's the responsibility of the authoritative domain owner
> to host their domain on at least two different ASes (RFC 2182), if
> they care about people being able to resolve it.
Full agree with that, but our customer is not interested why he cannot
send a mail to the other en
On 20/05/2019 17:57, Tobi wrote:
- BGP routing issues (ex from Provider 1 you can reach target and from
provider 2 not)
That happens, but very rarely in my experience. In any case, it's the
responsibility of the authoritative domain owner to host their domain on
at least two different ASes
Hi Tobi,
Nico is completely right: it sounds like the wrong solution for your problem.
If your provider has issues reaching that destination, then the solution would
be to have your provider fix the reachability issue. Note that the second
reason you mention (src address rate limiting) won’t be
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
Hi,
On 20-May-2019 16:04 CEST, 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
Hi Frank
sorry I'm quite new to dnsdist :-)
I thought that a rule like this could work
> newServer({address='XX.YY.ZZ.ZZ:53', pool='remote'})
> addAction({"IP1", "IP2"}, PoolAction('remote'))
IP1 and IP2 are the IP addresses of the two authorative nameservers for
the zone in my tests. XX.YY.ZZ
> 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
Hi list
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 se
11 matches
Mail list logo
