We were in the middle of watching an episode of a TV series last night (via Jellyfin) and the connection suddenly dropped out and we were unable to continue. Jellyfin then would not connect to the server.
We tried another app (Emby - as I also have that service running on the same server) and had exactly the same problem. After quite a bit of investigation, I worked out that the Roku was failing to use the internal DNS (as configured by the router) and was unable to lookup the IP address from the local network name. All other devices in the house (phones, laptops etc) can access the server by name, but the Roku suddenly can't. Most other devices are connected via wifi whereas the Roku is connected via an ethernet cable, but it seems unlikely that this would make a difference. The server is on the same subnet (and also connected by ethernet) as the Roku.
I couldn't find anything in the Roku settings to check what DNS server was being used.
I've got it working again for now by replacing the DNS name with the IP address of the server, but this seems a ridiculous set-up considering that the DNS server is working for everything else on the network.
I tried resetting the Roku and also cleared the network settings (which caused a reboot as well), but it doesn't seem to make any difference.
It seems particularly odd that this happened half-way through an episode, so no firmware or application updates would have happened in that time.
Can anyone suggest why this might have suddenly happened?
So you rebooted the Roku, but you didnt reboot the modem/router/gateway or the "server"? (I assume some sort of media server/NAS)
If one of my devices had a problem with LAN-side DNS and or access to a LAN-side server and I rebooted the device and the problem still remained, the next logical steps would be to reboot/troubleshoot the DNS device and the server (regardless if other devices were connecting properly).
As to the why, difficult to assess without knowing the where/how/what - I'd suspect a resource allocation/limitation issue with the DHCP/DNS server service in the modem/gateway/router myself.
I don't know why it suddenly stopped working, but I can't imagine why it ever did work. I've never heard of using a DNS server's name. After all, the whole purpose of DNS is to translate a name to an IP address. What was translating that server name to an IP address so your devices could contact it? I suspect some fallback server was being used and its IP address was entered somewhere. Perhaps via your ISP. Stick with using the IP address of your DNS server and all will be well.
Proper DNS server configuration always uses an IP address. You never configure a name for a DNS server, as the purpose of a DNS server is to turn the name into an IP address. So to find the DNS server it has to be by IP address.
So, assuming you merely misstated what you meant. As @renojim and @StreamerUser mentioned all the network settings for your Roku (and every other device on your network that isn't hard-coded) is provided by a DHCP server on your network. For almost all home users, that's their Internet router. Whatever it has configured for DNS services is what it provides to your networked devices. By default, most DNS servers tell the network to use itself as the DNS server, and it acts as a DNS proxy to reach out to the Internet for name resolution. However, it is also aware of connected devices within the network, and can provide that name information within your network.
Now, can that DNS function in the router fail? It certainly can. I encountered an issue with my DSL modem/router that would work completely fine, but would not pass DNS packets through the router. Even my equipment with static IP settings could not get name resolution to work. A connected device that was working when DNS failed would remain connected, but nothing new could get a connection. I had to reboot my router on a daily basis until I got a new one from my ISP.
So, reboot your router, then reboot your Roku. Chances are everything will work now. If it fails again, try the router reboot again. If that again fixes it, then your router is failing and needs replacing.
I'd like to also point out that this issue shouldn't be causing a problem with internal devices connecting to each other. Services like Emby or Plex use a different method to connect between players and the server, and can normally find each other without the need for DNS. DLNA uses a network broadcast advertising itself, and the players can find the server. I don't know what you were connecting to with Jellyfin, but if it was strictly IP based that could be the issue with it. I can't say for Emby, though. When I've played with Emby, it found my server with no issues.
I think I wasn't quite clear in what I was saying. When I said "I worked out that the Roku was failing to use the internal DNS (as configured by the router) and was unable to lookup the IP address from the local network name", I meant that the Roku was unable to lookup the IP address of the media server from the local network name, using the DNS. The DNS server is configured in the router as "192.168.3.107" - a local server running dnsmasq among other things. The jellyfin roku app is configured to look up the server address by name and that's the bit that suddenly started failing.
I haven't tried rebooting the router, mainly because it's a TP-Link Deco, which has an irritating bug that it changes IP range every time you reboot. I have the DNS server's address set as a "reserved address", so it's always 107 at the end, but if I reboot, it'll probably become 192.168.68.107 or something like that instead. Rebooting the Deco routers then requires me to reconfigure the DNS server and restart everything, which is a massive pain in the backside so I'd (grudgingly) rather just leave jellyfin configured with the IP address of the media server rather than rebooting the router just because the roku's being weird.
I don't understand why rebooting the server would be required when every other device on the network (apart from the router) works fine and has continued to work fine.
Is there any way to see what DNS server the Roku thinks it should be talking to? It's obviously successfully doing DNS queries as netflix etc work fine, but it can't be talking to the router-configured DNS server as local address lookups don't work.
Unfortunately, there doesn't appear to be any way to see the full network configuration. Roku has a number of "hidden" menus, and one was labeled Network. I just tried it but all it did was take me to the Settings/Network menu. That screen only shows the assigned IP address, gateway and MAC address. It appears the old detailed screen has been removed. Of course, the secret menus have always been something that Roku says could be changed or removed at any time.
Something tells me my problem is related to this, because it happened all of a sudden to 3 Rokus in my house, and it no longer works hard connected via ethernet cable either. Basically, the Rokus find the internet connection (well, it gets the time and there is a green check) but there is no connection. Rebooted everything a million times, in specific order, made sure settings on router were 2.5 instead of 5, checked modes, switched channels to 1, then 6, then 11, turned off WPS, etc., etc. Now it’s turned into a proper mystery. We do use a second router for our Rokus because our apartment is long, and the main router doesn’t reach the whole apartment, so not sure there is something in that setup I need to check, but I was suspecting a DNS problem specifically with Roku because I have no problems with anything else (or loading the same content via laptop or phone).
@melusinagr your second router is configured just as an access point, right? Having cascading routers within a network can certain cause hiccups.
I'm having the same issue. I have a DNS server on my network to resolve local hostnames and my router forces all DNS traffic to that server, including any Roku hardcoded DNS queries to 126.96.36.199. Sometimes jellyfin.mydomain.com work and sometimes not. Always the IP works.
Checking the DNS queries on my Pi-Hole I find successful responses from the pi-hole, so the Roku seems to be querying and receiving the correct address.
I only allow 188.8.131.52/184.108.40.206 udp 53(cloudflare) traffic and log any mac "breaking the rules" my three Roku's fail to comply, yet each device continues to operate normally as it continually attempts connections to 220.127.116.11/18.104.22.168 53 every ten seconds. I just wonder what traffic they are selling to Google in some backdoor deal. Want a lil privacy, step 1: stop using your service provider and google DNS servers. My Rokus have their own vlan; I do not trust Roku.
Roku developers are a lil slow: I have three APs on my network and one of my Rokus is unaware how to handle a multiple radio setup, so it arbitrarily attempts to join the first radio ssid it finds, which is invariably the radio too far away. The onus of multiple AP (radios) support largely falls onto the device. Smart multi-radio setups handle fast roaming to radio hop, and channel optimization, yet, there really is nothing to prevent having "home" linksys style wifi routers using the same config SSID/WPA and optimize the channels on your own, IE: setups like Cox Panoramic Wifi are a waste of money.
Not to pick on Roku, but my Hydrawise too is too stupid and arbitrarily radio hops and dies. I now have dedicated SSIDs to radios to help out my fellow embedded system engineers that skipped the day they taught coding at school. Trying to explain this to support is a waste of time.
|Apr 15 08:15:59||[165166.609087] Firewall: Denied CONN=vlan MAC=10:56:ca:60:db:80:ac:ae:19:34:1e:65:08:00 src=10.10.0.116 DST=22.214.171.124 LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=11774 DF PROTO=UDP SPT=50102 DPT=53 LEN=48 MARK=0x3|
|Apr 15 08:15:57||[165165.019336] Firewall: Denied CONN=vlan MAC=10:56:ca:60:db:80:ac:ae:19:34:1e:65:08:00 src=10.10.0.116 DST=126.96.36.199 LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=56610 DF PROTO=UDP SPT=42632 DPT=53 LEN=48 MARK=0x3|
|Apr 15 08:15:47||[165154.516912] Firewall: Denied CONN=vlan MAC=10:56:ca:60:db:80:ac:ae:19:34:1e:65:08:00 src=10.10.0.116 DST=188.8.131.52 LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=10551 DF PROTO=UDP SPT=50102 DPT=53 LEN=48 MARK=0x3|
|Apr 15 08:15:47||[165154.516474] Firewall: Denied CONN=vlan MAC=10:56:ca:60:db:80:ac:ae:19:34:1e:65:08:00 src=10.10.0.116 DST=184.108.40.206 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=10488 DF PROTO=UDP SPT=44437 DPT=53 LEN=44 MARK=0x3|
|Apr 15 08:15:47||[165154.515601] Firewall: Denied CONN=vlan MAC=10:56:ca:60:db:80:ac:ae:19:34:1e:65:08:00 src=10.10.0.116 DST=220.127.116.11 LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=55256 DF PROTO=UDP SPT=42632 DPT=53 LEN=48 MARK=0x3|
|Apr 15 08:15:36||[165143.644366] Firewall: Denied CONN=vlan MAC=10:56:ca:60:db:80:ac:ae:19:34:1e:65:08:00 src=10.10.0.116 DST=18.104.22.168 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=54941 DF PROTO=UDP SPT=36487 DPT=53 LEN=44 MARK=0x3|