Slow name resolution related issue specifically for octopi.local

Get Help Networking
1

What is the problem?
When attempting to use DNS name of octopi.local from the octopi box, name resolution seams to be delayed to around 10 seconds, making certain parts of octoprint abandon name resolution and assume the name resolution has failed.

After name resolution has occured, all other network function is at the speed you would expect. Upon testing with other random names to check DNS resolution timings, these all respond <1 second.

What did you already try to solve it?
If I add octopi.local to my hosts file, this problem goes away. But this is a workaround and I'm trying to find the solution.

Logs (syslog, dmesg, ... no logs, no support)
Probably the most useful logging I can give you is copied below, but if there is benefit from other logs, please let me know. There is no logging of the name resolution in syslog as I've checked it over.

pi@octopi:~ $ dig octopi.local +search

; <<>> DiG 9.11.5-P4-5.1+deb10u3-Raspbian <<>> octopi.local +search
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27516
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;octopi.local.                  IN      A

;; ANSWER SECTION:
octopi.local.           2       IN      A       192.168.68.50

;; Query time: 10 msec
;; SERVER: 192.168.68.5#53(192.168.68.5)
;; WHEN: Wed Mar 17 11:11:04 GMT 2021
;; MSG SIZE  rcvd: 57

pi@octopi:~ $ nslookup
> server
Default server: 192.168.68.5
Address: 192.168.68.5#53
> octopi.local
Server:         192.168.68.5
Address:        192.168.68.5#53

Name:   octopi.local
Address: 192.168.68.50
;; connection timed out; no servers could be reached
> pi@octopi:~ $

I see the connection timed out response above (and this takes some time to come up) but I cannot see what or why that is happening. Performing an NSLOOKUP from my mac, provides no such error message and response is instant.

Additional information about your network (Hardware you are trying to connect to, hardware you are trying to connect from, router, access point, used operating systems, ...)

DNS server is PiHole. There is a local DNS entry added for octopi.local. Logs from PiHole show the name resolution is being asked and resolved from local cache on PiHole (which is what you'd expect as it's locally added to the server)

2

octopi.local is resolved not via regular DNS but by so called mDNS. It involves multicast requests send on your network and can be quite long or fail completely depending on your network setup, how stuff is cached by your router and so on.

I'm unclear on why you even would use octopi.local from itself, that's what 127.0.0.1 or localhost is for. You don't have to use octopi.local to address your OctoPi instance, least of all from itself, if your router assigns a static IP or a less ephemeral host name you can use that just as well. octopi.local is simply what should usually allow you to find it on your network even if all else fails.

3

So it's a bit of an odd one - For reasons that I'm not aware of right now, octodash was installed referring to octopi.local - That has subsequently been changed and sorted. But once I'd started looking into it, I didn't like how it wasn't cleanly dealing with that request, where another machine was. Having tested further, other Raspbian based OS seem to act the same. WINTEL and Mac (Intel and Apple silicon), all deal with the call to octopi.local without the delay.

I'll put it down to OS, but will continue to look into why this is such an issue