Op 06-03-13 19:02, Simon Kelley schreef:
>> Thanks for your response. In my tests the two main resolvers were
>> both equally fast (≈ 1 ms as they had the results cached), so even
>> though one may be a tiny bit quicker than the other, I doubt it would
>> be an explanation for it choosing a specifi
Op 04-03-13 00:29, Ed W schreef:
> Dnsmasq by default queries all dnsservers simultaneously and locks onto the
> one which gives the fastest response (rechecking every few queries or every
> 60 seconds - or some numbers like that)
>
> So I guess it's just bad luck that the fastest resolver has a
On 06/03/13 17:32, Sjors Gielen wrote:
Op 04-03-13 00:29, Ed W schreef:
Dnsmasq by default queries all dnsservers simultaneously and locks
onto the one which gives the fastest response (rechecking every few
queries or every 60 seconds - or some numbers like that)
So I guess it's just bad luck t
Dnsmasq by default queries all dnsservers simultaneously and locks onto
the one which gives the fastest response (rechecking every few queries
or every 60 seconds - or some numbers like that)
So I guess it's just bad luck that the fastest resolver has a bad record?
Using strictorder should pro
Hi all,
I've either got a case of some very very bad luck from my RNG, or a bug on my
hands. (Or I'm just being an idiot.)
I noticed that one of my upstream DNS servers has an old entry in its cache:
131.174.78.16:asterix 83904 [...] 2001:610:6d0:75:6c21:5fff:fea1:be1
131.174.78.17:
