These are chat archives for CZ-NIC/knot-resolver

8th
Aug 2017
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 02:56
wasnt a kresd issue, pf had the scrub line commented out
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 03:52
im looking at a packet capture comparing unbound/kresd on the grc test. they both query grc.com which is signed and has the DO bit
but then the next query is for dns.grc.com and kresd no longer sets the DO bit, but unbound does
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 07:02
more info on the entropy issue
I'm looking at the GRC tcpdump and I'm seeing transaction ids being reused within 150 ms of each other
different queries, not retransmits
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 07:23
it also looks like if you send the same query to two different listen ips, kresd will send that same query to the same upstream twice (maybe it does that even if the same query is sent twice to a single listen ip?)
Vladimír Čunát
@vcunat
Aug 08 2017 07:27
There certainly is some attempt on "deduplicating" same queries done in parallel, within each fork (not across), but I don't remember specifics.
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 07:39
any idea on the duplicate transaction ids?
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 08:56
curious, whats the benefit of userland rng vs just /dev/urandom? seems like the build requirements require a recent os that would already have a fast and secure rng
Vladimír Čunát
@vcunat
Aug 08 2017 08:58
I don't know. Reading files requires a syscall, so there's some inherent performance penalty. See also https://gitlab.labs.nic.cz/knot/knot-resolver/issues/233
Do you have logs showing the duplicate IDs? It's theoretically possible that there's some missing regeneration of the ID or something.
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 09:01
I have a packet capture, not verbose kresd logs
Vladimír Čunát
@vcunat
Aug 08 2017 09:06
Relevant parts of that might help me.
And the overall number of IDs and duplicates? It couldn't be just due to the birthday paradox, right?
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 09:12
no, it happens multiple times
1 query happens, a few more happen, then the id is duplicated, all within milliseconds
and when i saw a few more, i mean only a handful of queries
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 09:20
took a new capture with a verbose log
i see same query id being used for same query, but against different destination ips
Vladimír Čunát
@vcunat
Aug 08 2017 09:22
It keeps the ID if it's a retransmit of the same query, even if it's to a different IP.
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 09:23
whats timeout period? I see same id used for same query to same server in about 150ms
250ms
Vladimír Čunát
@vcunat
Aug 08 2017 09:24
250ms by default
(But it keeps accepting replies even some time after that.)
Mike Emigh
@nakame_maiku_twitter
Aug 08 2017 09:29
not seeing it reused on different queries yet... it may be that verbose logging slowed it down too much
possible race between re-sending a query, and having the response come in before the resend is sent, so the id ends up applied to a different packet?
Vladimír Čunát
@vcunat
Aug 08 2017 09:36
It's not a race. The IDs aren't changed when resending.