1 Dub
2017
1 Dub
'17
12:42
On 1.4.2017 05:06, Daniel Kahn Gillmor wrote:
Hi Vladimir--
Thanks for the reply!
On Thu 2017-03-30 09:31:57 -0400, Vladimír Čunát wrote:
Intereting, I'm not able to reproduce it either.
dkg, would it be possible to get a pcap file from your attempt?
Something like
$ tcpdump -i any -w /tmp/dns.pcap 'port 53' &
$ dig @::1 www.ietf.org A
could be sufficient, just send us /tmp/dns.pcap and longs from the same
attempt.
I would recommend to run this on a idle machine so other processes do
not interfere and no personal data are leaked from other DNS queries.
Thank you!
--
Petr Špaček @ CZ.NIC
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!