Hi Frank,

On 8/13/19 4:59 PM, Lichtnau Frank wrote:
> I think, it has to be with 'high latencies'.
> 
> I have: 
> - 1 pool (winmls) for windows-ad-dns-queries
> - 1 pool (mls) for rest of our internal domain
> - and a dns-forwarder (with 3 listener) for external dns-queries.
> 
> The pools work fine with latencies of 0.3 - 0.8 The single dns-forwarder has 
> latencies of 40 - 56. And there I have the drops.
> 
> For testing I reconfigure the external dns-queries over the pool(mls). 
> And than I have the drops in this pool.
> 
> I would try to install dnsdist 1.3.3 in debian 9, but it works not, because 
> some packet-dependencies was not given.
> And the  dnsdist-packet in debian 9 was to old.
> 
> Your tool is importent for me, because it helps me to capture queer manner of 
> our windows machines. 
> If the dns-server is gone, windows don't switch to the second dns-server in 
> his given list of dns-servers. 
> 
> BTW, I would build now a tool as workaround for checking dnsdist frequency.
> if the quote between queries and drops too bad or grow up I restart the 
> daemon.

So now I'm confused, are you experiencing the same issue reported by
Chris where dnsdist stops responding to every single query sent over UDP
after a while, or are you just experiencing some queries being dropped?

Queries being dropped happens for one of two reasons, either the backend
did not respond fast enough, for example because it is overloaded, or
dnsdist is struggling to keep up with the responses and could not
process them fast enough.
It is quite easy to see the difference between the two cases because in
the second one dnsdist will be CPU bound, which is easy to spot in top,
metronome or grafana. If the backend is not responding fast enough, then
you need to investigate the backend or eventually the network.

> I check your API api/v1/servers/localhost and see, that the value from
Column "Drops" are given in field=reused.
>
> Why ist he name reused and what means reused in this context?

I agree it's not clear but that's the same thing. Historically dnsdist
did not actively discover timeouts, ie a backend not responding, but
would notice later when picking up a state (a slot in the table dnsdist
uses to keep track of queries sent to backends) to forward a new query
that the state was still marked as "in use", meaning that the response
never came through. We will then "reuse" that state, and so the
corresponding metric is named "reused" even though nowadays we usually
notice the timeout by regularly scanning the table.

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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist

Reply via email to