"Name or service not known" when trying to access www.youtube.com from OSMC

(copied over from GitHub Issue #160 at DBMandrake’s request)

When I try to either log into YouTube or play a video from within Kodi, a progress window shows for two full minutes followed by nothing.

  • Both my OSMC installation and my Linux Mint desktop are on the same LAN, and both use DHCP.
  • Pinging youtube.com succeeds from both an OSMC terminal and my desktop.
  • Pinging www.youtube.com succeeds from my desktop, but fails from an OSMC terminal:
osmc@osmc:~$ ping -c 3 youtube.com
PING youtube.com ( 56 data bytes
64 bytes from seq=0 ttl=56 time=28.969 ms
64 bytes from seq=1 ttl=56 time=28.404 ms
64 bytes from seq=2 ttl=56 time=28.530 ms

--- youtube.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 28.404/28.634/28.969 ms
osmc@osmc:~$ time ping www.youtube.com
ping: bad address 'www.youtube.com'

real    1m32.578s
user    0m0.000s
sys 0m0.010s
osmc@osmc:~$ time wget -O /dev/null www.youtube.com
--2015-04-29 21:29:16--2015-04-29 21:32:10--  http://www.youtube.com/
Resolving www.youtube.com (www.youtube.com)... failed: Name or service not known.
wget: unable to resolve host address ‘www.youtube.com’

real    1m4.745s
user    0m0.040s
sys 0m0.020s

A debug log of me trying to play a video through Kodi is at http://paste.osmc.io/semutolapi.dos, but to me this issue seems to be at a deeper level than Kodi.

I’m running OSMC on a Raspberry Pi 2.

I’m happy to take direction on assisting further with the resolution of this issue.

Please try using a known good DNS server, such as or (the Google DNS servers).

Thanks for the quick response.

Both of my devices are on the same LAN, and both are set up to obtain DNS details from the DHCP server. Of those two devices, one of them (my desktop) is correctly resolving www.youtube.com.

How would you recommend that I alter this DNS setup? Should I try it at the DHCP server level, or give the OSMC box the explicit DNS server address (which seems to mean also giving it a static IP address)?

LxP, what happens if you try to ping the following domain instead:


According to an NSLOOKUP, www.youtube.com is actually an alias for that domain.

nslookup www.youtube.com

Non-authoritative answer:
Name: youtube-ui.l.google.com
Addresses: 2a00:1450:4009:801::200e
Aliases: www.youtube.com

The ping times out for me as if I’d ping-ed www.youtube.com.

I’ve been playing with nslookup and I’ve noticed something potentially interesting:

osmc@osmc:~$ nslookup youtube.com

Non-authoritative answer:
Name:	youtube.com

No problems there. Take a look at the warning emitted by this one though (first line of output):

osmc@osmc:~$ nslookup www.youtube.com
;; Truncated, retrying in TCP mode.

Non-authoritative answer:
www.youtube.CoM	canonical name = youtube-ui.l.google.com.
Name:	youtube-ui.l.google.CoM

If I do a Google search for that warning, I’m led to believe that the DNS response for www.youtube.com is larger than something on the OSMC system expects (presumably 512 bytes, according to this), so the request is just getting silently dropped…?

If I dig, I get these response sizes:

osmc@osmc:~$ dig youtube.com | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 285
osmc@osmc:~$ dig www.youtube.com | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 1096

so there seems to be merit in that idea. Is there some way to get the system accepting larger DNS responses? I’m up-to-date with all system packages (i.e. apt-get upgrade does zero operations).


Someone else reported some DNS issues recently. Good find here.

By default, we proxy DNS through ConnMan locally (it’s effectively the equivalent of NetworkManager + dnsmasq). There may be a bug in this system. Try editing (won’t exist by default) /etc/connman.prefs and adding:


And then run

sudo systemctl restart connman

@DBMandrake: the drop-in is useful already :wink:


  • Added /etc/connman.prefs with that content.
  • Assigned the same permissions and ownership as /etc/connman.conf (0644/root/root).
  • Restarted connman.
  • Restarted the entire OSMC system.

Sadly, there’s no change. DNS responses to www.youtube.com are still being “truncated,” and the request is repeating in TCP mode. nslookup handles this additional lookup gracefully; ping doesn’t.

Interestingly (perhaps), doing the same nslookup on my desktop, the first response is still truncated but everything else (including ping) still survives this occurrence, because everything seems to “pick up” the second response.

On this basis, it seems that something on the OSMC system just isn’t handling the size of the response for www.youtube.com (which in my case is apparently 1,096 bytes).

Is there any way to force the OSMC system to perform all DNS requests over TCP in the first place? This would prevent the UDP requests failing due to large response sizes, in turn preventing the need to re-request over TCP.

On further thought, this would only be a stop-gap solution. I guess the underlying system should just be able to gracefully handle DNS responses being larger than can fit in a UDP packet, and work properly when a DNS request is re-issued over TCP. My desktop does this, and my XBian box does this. I’d prefer to help work towards this solution for OSMC.

First, the drop-in is experimental at the moment. You may wish to edit /usr/bin/start-network directly and add --no-dns-proxy (temporarily to test, as apt-get dist-upgrade does not want this file to be edited by users).

You should check your DNS servers are set in /etc/resolv.conf, instead of ‘’ after you restart the service and --no-dns-proxy is working properly.

I’m not too clear on which line I need to edit in this file. The last five non-empty lines look like this:

  exec /usr/sbin/connmand -n -I eth0 --nodnsproxy --config=/etc/connman.conf
  exec /usr/sbin/connmand -n --config=/etc/connman.conf

I would guess that I’d be adding the --no-dns-proxy flag to one of these lines, but I note that there’s already a --nodnsproxy flag on one of them. Should I be adding that to the lower line as well?

At the moment, my resolv.conf file doesn’t have the expected entries:

osmc@osmc:~$ cat /etc/resolv.conf
# Generated by Connection Manager
nameserver ::1

You need to add it to the line in the else clause.

I would not expect /etc/resolv.conf to be populated automatically unless you were using DHCP. I’m not sure if ConnMan updates /etc/resolv.conf in line with DNS when configured statically or from DHCP.

--nodnsproxy added to the connmand line in the else clause, and system restarted.

  • resolv.conf now shows my nameserver.
  • ping www.youtube.com now works as expected.
  • The YouTube plugin can now play videos.

So in other words, my immediate issue is now resolved. Thanks for your assistance. I guess this strongly suggests a bug in the device-local proxy nameserver?

It does indeed.

Unfortunately, changing that script is not feasible long term, and when we release an update your system will break if you do not restore it.

You should use the /etc/connman.prefs approach for now.


I put that file in place earlier with these permissions and contents:

osmc@osmc:~$ stat /etc/connman.prefs | grep Uid
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
osmc@osmc:~$ cat /etc/connman.prefs

but even after restarting the system, my issue wasn’t resolved until I made the manual modification to /usr/bin/start-network, which I understand will disappear with upgrades.

Have I missed a step to making /etc/connman.prefs effective?

It won’t disappear, it will just break upgrades.

That should be fine, provided you’re on the latest version of ConnMan (we may not have pushed this to release yet). Either that or iit seems to be a bug we need to look into there.


I’ve reverted the change to /usr/bin/start-network and rebooted.

  • /etc/resolv.conf now no longer contains the address of my actual nameserver.
  • The device-local proxy nameserver is active again.
  • ping www.youtube.com still works though.

So it seems that my version of connmand (1.28) doesn’t honour the connman.prefs file.

It also seems that the device-local proxy nameserver is now okay. Not sure why; maybe some DNS data is now cached on the system. If things fail again, I guess I’ll re-introduce the --nodnsproxy flag to /usr/bin/start-network.


The version of network-osmc with the connman.prefs option has not been pushed out to release yet. That’s why the dnsproxy=no option is not working for @LxP.

I’ve pushed out an update to the network-osmc packages which adds support for /etc/connman.prefs as Sam described it, so if you check for and install updates you should find that you can then use dnsproxy=no in connman.prefs to permanently disable the use of the connman dns proxy.

It does look like a bug in the dns proxy in connman, I’ll open a ticket with them about this and see if this is a known issue or not.

By the way could you try the test here and see what results you get with the dnsproxy still enabled ?


Here is what I get:

osmc@rpi2:~$ dig +short rs.dns-oarc.net txt
" DNS reply size limit is at least 3980"
" sent EDNS buffer size 4000"
"Tested at 2015-04-30 10:08:26 UTC"

(It actually seems ok for me…)

I get very different results:

osmc@rpi2:~$ dig youtube.com | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 285
osmc@rpi2:~$ dig www.youtube.com | grep 'MSG SIZE'
;; MSG SIZE  rcvd: 289

It’s quite normal for Google in different countries to give very different DNS results though…

The problem reappeared a couple hours after removing that modification, so it probably was caching of some sort.

With no --nodnsproxy modification to /usr/bin/start-network, after rebooting and verifying that ping www.youtube.com times out again:

osmc@osmc:~$ cat /etc/resolv.conf
# Generated by Connection Manager
nameserver ::1
osmc@osmc:~$ ping www.youtube.com
ping: bad address 'www.youtube.com'
osmc@osmc:~$ dig +short rs.dns-oarc.net txt
" DNS reply size limit is at least 4090"
"Tested at 2015-04-30 10:33:15 UTC"
" sent EDNS buffer size 4096"

Unfortunately, no apparent response size restrictions in that report. My desktop on the same LAN has no problems accessing www.youtube.com, and the dig output from that machine is pretty much identical:

$ ping -c 1 www.youtube.com
PING youtube-ui.l.google.CoM ( 56(84) bytes of data.
64 bytes from 10-50-30-108.tpgi.com.au ( icmp_seq=1 ttl=59 time=17.4 ms

--- youtube-ui.l.google.CoM ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.404/17.404/17.404/0.000 ms
$ dig +short rs.dns-oarc.net txt
"Tested at 2015-04-30 10:38:11 UTC"
" sent EDNS buffer size 4096"
" DNS reply size limit is at least 4090"

so perhaps that test instead looks at an upstream DNS resolver (e.g. that of my ISP) rather than the device-local DNS proxy.

connman.prefs is now effective after installing the most recent updates. Thanks.

Are you sure you have dns proxy disabled above ? Did you restart the connman service or reboot ?

Because you will not have nameserver if the dns proxy is turned off, you should see the dns servers assigned by your DHCP server. (I assume you use DHCP)

If you are definitely still seeing this issue with dns proxy off (and correct nameservers shown in resolv.conf instead of then that rules out connman as the cause of the problem.

What dns servers are being assigned by your DHCP server - is it assigning your router/gateway as a dns server ? Check in networking in OSMC settings. If so your router is acting as a dns proxy and could potentially be causing the issue, even though other machines on the network seem ok.

Or it may be directly assigning your ISP’s DNS servers.

What happens if you leave dnsproxy=no, go into network settings, change from DHCP to Static IP (again I’m assuming you’re using DHCP) and manually change your DNS servers to and ? I would be very surprised if it didn’t work then.