DNS-over-TCP: Just a single transaction?

Foris → DNS → Use forwarding: Use provider’s DNS resolver

Currently, I am a debugging an issue of mine. To ease debugging, I disabled DNSSEC. For testing, I use SSH and there pkgupdate. In that case, DNS resolution does not work (still investigating; know several workarounds = happy). In Wireshark, I see, after two (?) attempts, that my Turris MOX falls back from DNS-over-UDP to DNS-over-TCP. However, instead of using one TCP connection for each DNS transaction, my Turris MOX re-uses one TCP connection. In some cases, it even issues several DNS transactions side-by-side. I call that ‘bulk behavior’.

The problem: My DNS server allows only one transaction per TCP connection. Only the very first DNS query is answered. With a new TCP connection, again, only the first DNS query is answered. I have not looked up the RFCs whom to blame. My question: Does anyone know a configuration flag or setting which I can tweak, so my Turris MOX opens a new TCP connection for each DNS transaction?

You can’t tweak that. Multiple messages in a single TCP connection is over 30 years old.

If the ISP’s resolver is of this quality, I don’t think you’d want to forward to them. My first (personal) choice would be to go without forwarding, but now there are various public providers, too (some as one-click in Foris).

There seems to be particular RFC pertinent to reuse in DoT, least by judging from this bug still (shockingly) being unresolved for unbound

[1] https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4089

Thanks, I know the alternatives and workarounds. However, that was my initial choice when I clicked through the configuration wizard. Perhaps other users have the same scenario. Therefore, I look into that issue.

Well, this DNS resolver is the most used one in Germany, at least I guess so. It is the DNS server in the AVM FRITZ!OS. My Turris MOX has severe issues with FRITZ!OS as upstream router. One isolated issue is this single transaction thing. I still have to figure out why I face all my issues (some services in Turris OS ignore that setting and still go for full-resolver mode, some services use some different DNS server, why does Turris MOX not like those initial answers and falls back to TCP at all, …).

By the way, because near to every Internet provider gives away a FRITZ!Box, used ones are terrible cheap in eBay. For example, the FRITZ!Box 7362 SL or FRITZ!Box 7520 still get the latest AVM FRITZ!OS. Although they come with a DSL modem, those can be re-configured via the Web wizard to re-use your existing broadband connection. It might be a good testing device in-front of Turris OS.

Since the FOS on the FB is proprietary closed source code it is unknown what their dnsd implementation really entails.

I’m sad this will affect so many people by default. I’m generally not fond of doing workarounds because of others breaking long-established protocol standards; we actually tend to push the other way now (example).

I don’t know what the workaround would even look like. Doing one query per connection by default is certainly out of the question; it’s just expensive and harming “good implementations” in order to help “bad” ones.

I’ve personally never been liked the default to forward to ISP resolvers, exactly because their quality is relatively commonly a problem, and doing “advanced” stuff like DNSSEC validation (or this topic) tend to expose hidden issues. I heard some ISP offer custom services that rely on using their DNS, so one way probably can’t please (almost) everyone.

I was not about changing the default for everyone. Especially for DNS-over-TLS, doing several transactions is more than obvious. I was just about tweaking this to debug further. Currently, my Turris MOX behaves totally crazy and I do not know why. I identified that issue and hoped, it helped me to understand to other issues. Is there any trick to debug the Knot Resolver in detail?

Depends. There’s verbose logging in kresd; probably difficult to understand to those who don’t know how it works. Then there’s the classic tcpdump (wireshark).