Version 1.2.5 sometimes can't resolve google

I suspect this is because of !274 (merged), but there's not enough information to be confident that it's not a separate issue.

ATM it seems likely that !250 (merged) is the cause for resolution failures experienced by some people on 1.2.5, but so far no --verbose logs were provided by anyone...

The logs should look like [resl] => no valid NS left without really trying any/all of the NS set. (That's not a google-specific problem.)

mentioned in issue #179 (closed)

@vcunat The problem with --verbose is that if I restart kresd with --verbose, the problem disappears (it seems to appear at random, after hours of running kresd).

Yes, if it's what we think it is, it would be triggered when kresd doesn't receive any reply to some rarer nameserver queries, e.g. due to a temporary network failure, and the state would remain broken until restarting.

I managed to run kresd with the verbose option and found a lot of those

info kresd[20002]: [52034][resl] => no valid NS left

However I don't see why the issue is related, as my (LAN) network is not configured for Ipv6 and my provider is IPv4 only. Should I provide a portion of the logs? I'm also available for testing any fix, I guess I can manage to switch to any testing branch.

That change isn't really IPv6-specific; it's about more general changes in the heuristics choosing which nameservers are tried and in what order. We're working on a better fix.

@mhrusecky Could you pull last commit from dev-ondrej branch in turris-os-packages into RC? So affected people can install the version with the fix?

dev-ondrej branch of openwrt failed to build and I can't debug it right now.

So it might need some tweaking.

I'd like to confirm that the patch in !250 (merged) fix some of the issues, (or at least something in these commits: https://gitlab.labs.nic.cz/knot/resolver/compare/v1.2.5...master does)

I "released" my own version of knot-resolver from the master branch and installed it in my omnia.

Using this kind of test:

while true; do dig google.com; done

I used to get only SERVFAIL answers, and now I get proper A records. Still unsure if that fixes everything, will try to do some more tests tomorrow (it took me several hours to get the buildroot prepared...)

Maybe I was to fast confirming... Unfortunately this still happens:

2017-04-22T08:31:02+02:00 info kresd[21018]: [    0][plan] plan 'googleapis.l.google.com.' type 'A'
2017-04-22T08:31:02+02:00 info kresd[21018]: [11871][iter]   'googleapis.l.google.com.' type 'A' id was assigned, parent id 0
2017-04-22T08:31:02+02:00 info kresd[21018]: [11871][resl]   => NS is provably without DS, going insecure
2017-04-22T08:31:02+02:00 info kresd[21018]: [45353][iter]   'googleapis.l.google.com.' type 'A' id was assigned, parent id 0
2017-04-22T08:31:02+02:00 info kresd[21018]: [45353][resl]   => no valid NS left
2017-04-22T08:31:02+02:00 info kresd[21018]: [    0][resl] finished: 8, queries: 2, mempool: 65568 B
2017-04-22T08:31:02+02:00 info kresd[21018]: [    0][plan] plan 'youtubei.googleapis.com.' type 'A'
2017-04-22T08:31:02+02:00 info kresd[21018]: [25359][iter]   'youtubei.googleapis.com.' type 'A' id was assigned, parent id 0
2017-04-22T08:31:02+02:00 info kresd[21018]: [25359][ rc ]   => satisfied from cache
2017-04-22T08:31:02+02:00 info kresd[21018]: [25359][iter]   <= rcode: NOERROR
2017-04-22T08:31:02+02:00 info kresd[21018]: [25359][iter]   <= cname chain, following
2017-04-22T08:31:02+02:00 info kresd[21018]: [    0][plan] plan 'googleapis.l.google.com.' type 'A'
2017-04-22T08:31:02+02:00 info kresd[21018]: [17708][iter]   'googleapis.l.google.com.' type 'A' id was assigned, parent id 0
2017-04-22T08:31:02+02:00 info kresd[21018]: [17708][resl]   => NS is provably without DS, going insecure
2017-04-22T08:31:02+02:00 info kresd[21018]: [46515][iter]   'googleapis.l.google.com.' type 'A' id was assigned, parent id 0
2017-04-22T08:31:02+02:00 info kresd[21018]: [46515][resl]   => no valid NS left

I'm pretty sure that I'm using my "new" knot-resolver compiled from master:

root@turris:/tmp# opkg list | grep knot
knot-libdnssec - 2.4.2-1
knot-libknot - 2.4.2-1
knot-libzscanner - 2.4.2-1
knot-resolver - 1.2.6-2

Is there anything else I can help you with to diagnose this problem, @vcunat @ondrej ?

Another verbose log (for a non-Google domain) in ticket #179 (closed) .

@jplana: the quick workaround planned for Omnia is commit https://gitlab.labs.nic.cz/knot/resolver/commit/dcc75a1ee27d3ed34; you can simply apply it to 1.2.5 or master.

I believe we now have enough evidence that the NS reputation changes are what causes those problems.

Note that there are binaries for Omnia available with the patch applied: https://forum.turris.cz/t/problem-with-google/3967/43

@vcunat That revert seems to fix the issue, I've been running it for a while now and I only see those messages (no valid NS left) for a few queries (mostly PTR requests from internet trolls banging on my ssh port). I'll answer also in the forum.

@mhrusecky Could you push 1.2.5—3 from dev-ondrej via stable update channel?

mentioned in merge request !278 (merged)

closed via merge request !278 (merged)

closed via commit 6cca326f

mentioned in commit 6cca326f

@mhrusecky The test and dev-ondrej branch now contains 1.2.6-1 release that includes the fix.

Version 1.2.5 sometimes can't resolve google

Child items ...

Activity

Admin message

Version 1.2.5 sometimes can't resolve google

Activity