At that time, I had deliberately re-enabled the DNS proxy to run your requested test only.
To clarify, my issues were fully resolved after properly disabling the DNS proxy and rebooting. My DNS proxy is disabled again now, and I no longer have DNS problems. The majority of my previous post was just discussing the results of your requested test in case those results would help in any way.
For what it’s worth, I do have a LAN-local DNS server running bind which maps internal hostnames to internal IP addresses and forwards external hostnames requests to my ISP’s DNS servers. I had originally considered this to be a contributing factor to my issues, but then realised that all other devices on my LAN (including other Raspberry Pi 2’s running other Kodi distros, e.g. XBian) were not suffering from DNS problems.
In summary:
After disabling the DNS proxy on the OSMC device, the OSMC device has no DNS issues.
Other non-OSMC devices on my LAN with DNS proxies don’t have this issue.
Therefore, I continue to believe that it’s a connman issue, not an issue with my LAN setup.
However your reasoning that because other clients seem to be working OK that your bind server could not be contributing to the problem doesn’t stand up, and does nothing to help us diagnose what the problem might be - if we can’t reproduce the problem or identify it in some concrete way it won’t get fixed.
Different DNS clients have different behaviour in the way they make requests, it’s perfectly possible that connman’s dnsproxy exposes a bug in your bind server or the way your server is configured, or that conversely bind is exposing a bug in the way connman makes requests that doesn’t normally manifest. There could be some blame on both sides.
The fact that there are 10’s (100’s ?) of thousands of OSMC users and only one report of this on the forum suggests that this is not a widespread issue, and when I try to come up with possible reasons why you might be seeing it and everyone else (including me) is not I have to consider that your bind install acting as a forwarder could be a factor.
Please try changing your DNS settings to bypass your bind server (and turn connman’s dns proxy back on) as I asked so that we can at least prove or disprove that bind is having an influence on the issue.
Short of this there really isn’t anything else we can do.
Okay, I can see now how my bind installation could be playing a role in this issue. Please excuse my earlier ignorance, and thank you for your patience.
I’ve re-enabled the DNS proxy and rebooted in preparation for this test, but even while still “attached” to the bind server, DNS is now working normally. I guess this means I can’t perform any meaningful test at this stage.
The intermittent nature of this issue is frustrating, but should it surface again, I’ll perform the test as asked (i.e. bypass my bind server).
FWIW I’ve also having the same issue the OP posted about, but instead I’m seeing it happen for addon browsing, tvdb queries and a few other things. I have no such bind server configured on my local network, however I do have a Draytek router that perhaps exhibits similar funkiness to their bind server.
Turning off DHCP and using static assignment to point directly at the 8.8.8.8 Google DNS server resolves the issue. The connman.prefs file already exists in my installation, with dnsproxy=no already configured. Therefore there seems to be an issue with my router’s DNS forwarding (perhaps?) - but the same as the OP, there is no issue for any other device on the network.
EDIT: Modifying the nameserver config but maintaining DHCP is my workaround for now (using: connmanctl> connmanctl> config servicename --nameservers 8.8.8.8 8.8.4.4
I’d start a new post. We changed a lot since this thread was created, mainly we now no longer use the ConnMan DNS proxy by default because it sometimes does not deal appropriately with large response sizes.
This indicates a local network issue. I would try nslookup and take it from there.