1 Dub
2017
1 Dub
'17
5:06
Hi Vladimir--
Thanks for the reply!
On Thu 2017-03-30 09:31:57 -0400, Vladimír Čunát wrote:
I'm unable to reproduce this, unfortunately, and
that makes finding the
cause harder. Does it often happen to you?
yes, it happens reliably and repeatedly :/ I can generate another trace
any time you'd like, by terminating kresd, clearing the cache, and then
triggering an automatic restart by sending a request to the
systemd-managed socket. Would it help to see a second trace to compare?
There's one probably unimportant thing that
puzzles me in the log - the
plan to find www.ietf.org AAAA at 15:29:25. It happens when the clients
you show only have asked one request - for www.ietf.org A. It appears
as if some client has asked it explicitly precisely at that time - is
that possible?
It's possible that some other client was asking for it at the same time,
i know there is a monitoring service that asks for this particular query
from this particular resolver with some frequency, but it seems unlikely
that it triggered right at this time.
You are right that
'ns1.yyz1.afilias-nst.info.' type 'AAAA' is what got
stuck. Root hints never (fully) answer that - they may only serve as
the first step in resolution chain. I think there might be a badly
handled dependency loop somewhere among the sub-requests, but I'm
currently unable to pinpoint how exactly that might happen.
if there's any other data i can give you that would be useful to debug,
don't hesitate to ask!
--dkg