Whatever dot local

April 12, 2016 6:06 PM

I am getting some flaky activity with .local addresses on my LAN. I tell CUPS to print to ipp://computer-a.local:631 and it works some of the time, but takes about 15 minutes to print when it does. But as soon as I use a direct IP address, printing works great. What's the deal? Where should I look to start troubleshooting .local address issues?

I'm usually printing between two Ubuntu 14.04 systems. But I've also noticed that sometimes http://computer-b.local/ampache doesn't resolve either. Other times, it's great. It's driving me nuts because the .local system is pretty easy to remember and I'd like to use it. Thanks!

posted by circular to Computers & Internet (6 answers total)

When IP addresses work and names don't resolve, or resolve poorly, that's DNS through and through. What's running DNS on the network? Is the DNS daemon up, running, free of errors? There's not two somethings trying to run DNS on the network and in conflict with each other are there? Bad DNS entries, weird ARP tables, flaky router (if that's running the DNS), there's a few things to try. I'll try and check back in on the thread tomorrow.
posted by deezil at 7:16 PM on April 12, 2016 [1 favorite]

But I've also noticed that sometimes http://computer-b.local/ampache doesn't resolve either.

Agree that this sounds like a DNS issue. Verify this by adding computer-a.local to your hosts file on computer-b. If things work immediately, you've probably got a DNS configuration or communication issue with the DNS server. If they don't, you may have some sort of connection issue on your network.

Also try other things that do name resolution (not just printing). Ping, connect to a file share, etc. This eliminates CUPS or the ports you're using as a source of the problem.
posted by cnc at 7:23 PM on April 12, 2016 [1 favorite]

.local is handled through all the zeroconf networking stuff that's all the rage. Microsoft and Apple have different implementations that don't work well together (unicast vs. multicast) and Ubuntu essentially uses Apple's implementation. Make sure that your Microsoft boxes have Bonjour and Ubuntu has avahi installed.

Your /etc/nsswitch.conf should read:

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
posted by xyzzy at 7:32 PM on April 12, 2016 [6 favorites]

Response by poster: > What's running DNS on the network? Is the DNS daemon up, running, free of errors?

ASUS RT-N66U router, I think. Not sure how to check the DNS daemon. It has a spot where I can specify a separate DNS server.

Just now I tried: ssh [e-mail] and got this message:

ssh: Could not resolve hostname computer-a.local: nodename nor servname provided, or not known

Then I tried the IP and it worked. Then five seconds after that, I went into my browser and typed http://computer-a.local/ampache and that worked. So weird.

Ping is doing the same thing.

> Verify this by adding computer-a.local to your hosts file on computer-b

Oh that's a good idea. I'll try that.

> Your /etc/nsswitch.conf should read:

Yep! It does.

Edit: I did notice this in the system log on the router, not sure if it's relevant but it happened when I was just trying various .local connections on a client:

Apr 13 08:26:03 nmbd[530]: [2016/04/13 08:26:03, 0] nmbd/nmbd_namequery.c:query_name_response(109)
Apr 13 08:26:03 nmbd[530]: query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.1 for name WORKGROUP<1>.
Apr 13 08:26:03 nmbd[530]: This response was from IP 192.168.1.209, reporting an IP address of 192.168.1.209.
posted by circular at 8:27 AM on April 13, 2016

Best answer: .local is handled through all the zeroconf networking stuff that's all the rage. Microsoft and Apple have different implementations that don't work well together (unicast vs. multicast) and Ubuntu essentially uses Apple's implementation.

This I did not know. Good info!

Apr 13 08:26:03 nmbd[530]: query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.1 for name WORKGROUP<1>.
Apr 13 08:26:03 nmbd[530]: This response was from IP 192.168.1.209, reporting an IP address of 192.168.1.209.

I'm shooting in the dark here, but this combined with what was said above sounds like you're getting a response from the DNS server and the computer itself, which is going to cause you problems.

Yep - A quick web search reveals that using .local with a DNS server is problematic. I would at this point just stop using .local altogether because I have some minimal understanding of DNS. This may not be the answer for you, however. Best practice this days seems to be to use a subdomain of a registered domain. If that doesn't work, you might go with .test instead of .local.
posted by cnc at 9:36 AM on April 13, 2016

Response by poster: > Best practice this days seems to be to use a subdomain of a registered domain

Ohhh! Now that, I can do. I think I'll proceed that way. Would love to troubleshoot DNS further but this sounds like it'll work just fine. Thanks!
posted by circular at 2:44 PM on April 13, 2016