Not connecting to applications like Discord

Software SW bugs discussion
1

I don’t know what to include here to describe the issue. I wanted to know if I’m the only one experiencing this issue where my connection to the internet works perfectly but for some reason I cannot connect to Discord after some time (if I stop using it for 10 min or so). The same happens on my phone connected to the same router.

I’m not sure if it’s possible it’s a router issue or if I should look into my computer / phone settings. What seems weird to me is that it only happens when I use my turris router. Everything works as normal when on 5G or on other wifi.

Thanks for the help

2

I’ve been seeing the same thing. It’s not connecting per sè, rather it’s sometimes unable to look up certain domain names, including discord.com. If I SSH into it and run nslookup discord.com while it’s happening I get “no such domain.”

3

I’d see the options how to approach this the same way as in Dig error for debian.org and only for debian.org - #2 by vcunat

4

I’ve already got forwarding disabled though

5

OK, there’s still that debugging approach in the link.

6

Now I’ve enabled resolver debugging, I’ll come back when it happens again

7

For one query when explosm.net failed I see:

May 22 07:36:30 damma kresd[17843]: [iterat][00000.00]   'explosm.net.' type 'A' new uid was assigned .01, parent uid .00
May 22 07:36:30 damma kresd[17843]: [cache ][00000.01]   => skipping exact RR: rank 030 (min. 030), new TTL -1222
May 22 07:36:30 damma kresd[17843]: [cache ][00000.01]   => no NSEC* cached for zone: explosm.net.
May 22 07:36:30 damma kresd[17843]: [cache ][00000.01]   => skipping zone: explosm.net., NSEC, hash 0;new TTL -123456789, ret -2
May 22 07:36:30 damma kresd[17843]: [cache ][00000.01]   => skipping zone: explosm.net., NSEC, hash 0;new TTL -123456789, ret -2
May 22 07:36:30 damma kresd[17843]: [zoncut][00000.01]   found cut: explosm.net. (rank 010 return codes: DS 1, DNSKEY 1)
May 22 07:36:30 damma kresd[17843]: [resolv][00000.01]   => NS is provably without DS, going insecure
May 22 07:36:30 damma kresd[17843]: [select][00000.00] NO6: is KO [exploit]
May 22 07:36:30 damma kresd[17843]: [select][00000.01]   => id: '36919' choosing: 'andy.ns.cloudflare.com.'@'2a06:98c1:50::ac40:2165#00053' with timeout 10000 ms zone cut: 'explosm.net.'
May 22 07:36:30 damma kresd[17843]: [resolv][00000.01]   => id: '36919' querying: 'andy.ns.cloudflare.com.'@'2a06:98c1:50::ac40:2165#00053' zone cut: 'explosm.net.' qname: 'exPlOSM.neT.' qtype: 'A' proto: 'tcp'
May 22 07:36:30 damma kresd[17843]: [worker][00000.01]   => connecting to: '2a06:98c1:50::ac40:2165#00053'
May 22 07:36:30 damma kresd[17843]: [select][00000.01]   NO6: timed out, but bad already
May 22 07:36:30 damma kresd[17843]: [select][00000.01]   => id: '36919' noting selection error: 'andy.ns.cloudflare.com.'@'2a06:98c1:50::ac40:2165#00053' zone cut: 'explosm.net.' error: 3 TCP_CONNECT_FAILED
May 22 07:36:30 damma kresd[17843]: [iterat][00000.01]   'explosm.net.' type 'A' new uid was assigned .02, parent uid .00
May 22 07:36:30 damma kresd[17843]: [select][00000.00] NO6: is KO [exploit]
May 22 07:36:30 damma kresd[17843]: [select][00000.02]   => id: '51029' choosing: 'andy.ns.cloudflare.com.'@'2803:f800:50::6ca2:c165#00053' with timeout 10000 ms zone cut: 'explosm.net.'
May 22 07:36:30 damma kresd[17843]: [resolv][00000.02]   => id: '51029' querying: 'andy.ns.cloudflare.com.'@'2803:f800:50::6ca2:c165#00053' zone cut: 'explosm.net.' qname: 'ExPLosM.Net.' qtype: 'A' proto: 'udp'
May 22 07:36:35 damma kresd[17843]: [gnutls] (5) REC[0x57135e0]: SSL 3.3 Application Data packet received. Epoch 2, length: 147

…

May 22 07:36:40 damma kresd[17843]: [select][00000.02]   => id: '51029' noting selection error: 'andy.ns.cloudflare.com.'@'2803:f800:50::6ca2:c165#00053' zone cut: 'explosm.net.' error: 1 QUERY_TIMEOUT
May 22 07:36:40 damma kresd[17843]: [worker][00000.00] internal timeout for resolving the request has expired
May 22 07:36:40 damma kresd[17843]: [resolv][00000.00] request failed, answering with empty SERVFAIL

I wonder why it looks like it’s trying to run the query over IPv6, I don’t have that available.

1 Like
8

Thanks; I believe I know what happened in this case and we’ll be improving the heuristic to avoid it.

But people without working IPv6 should better get their resolver configured not to use IPv6. You won’t need to wait for this fix to avoid the case and even generally that configuration should slightly improve latency, etc. From my point of view the ideal way of doing this (with recent-ish Turris OS) is to set IPv6 to disabled in the GUI /reforis/network-settings/wan.

From DNS server’s point of view the detection isn’t so easy. Individual server might not respond, or there might be some kind of a short outage somewhere on the way (specific to IPv6 or not), or perhaps your network hasn’t fully started up yet, etc.