I have a Raspberry Pi 3 Model B Plus Rev 1.3 with Raspberry Pi OS Lite (64-Bit) installed which is currently a port of Debian Bullseye.

I also have OpenWRT installed on my router and have configured a few hostnames on it. For example, one is ipmi.local mapped to

My router is configured to broadcast itself as the DNS for all clients to use. I believe this is default behavior anyway.

On my Windows machine I'm able to ping all of the hostnames I've configured by both domain name (i.e. ipmi.local) and IP address.

From my Raspberry Pi, I can ping these devices by IP address, but not the domain name.

ping ipmi.local returns ping: ipmi.local: Name or service not known

However, pinging external URLs works.

When I run cat /etc/resolv.conf I see:

domain lan
nameserver fdbd:de1e:aa69::1

which is the correct address of my router.

So, since my Raspberry Pi apparently has the correct DNS server set (my router), and my router has hostnames configured correctly, why are other devices able to ping these hostnames, but my Raspberry Pi cannot?

  • You are abusing the mDNS service (Windows is a serial abuser). .local is reserved for mDNS and you should NEVER attempt to allocate it. .local is NOT resolved by a DNS it is a signal to perform a multicast broadcast.
    – Milliways
    Jan 29 at 11:32
  • Aha, I did not know that. Is there any best practice for TLD naming conventions for internal sites?
    – Iceape
    Jan 29 at 14:08
  • I changed it from ipmi.local to ipmi.home and can ping from the raspberry pi now. I also found this question serverfault.com/questions/17255/… which recommends ideally leasing a domain from a registrar and using its subdomains. Or using certain TLD suffixes such as .home. If you want to create an answer about not using .local, I'll accept it.
    – Iceape
    Jan 29 at 16:02
  • I am glad my comment helped, but this question does not appear to be about the Pi. In fact it is unclear what you have done but it appears to be about configuring your router or general internet standards.
    – Milliways
    Jan 30 at 6:23
  • Yeah, it was ultimately about me having used a .local extension. I thought it was the pi since it was the only device that couldn't ping my server. It hadn't crossed my mind that the problem could be with .local and you pointed that out to me so I wanted to give you credit for it.
    – Iceape
    Jan 30 at 8:29

1 Answer 1


As Milliways observed, .local is reserved for mDNS resolution (<-worth a read) only, and using it as hostname for a node that isn't running such, intending it to be resolved via normal DNS, may lead to problems.

If that node is running an mDNS service, and the pi is too (avahi, which is enabled by default), though, that should work, although if it is not it is probably not worth hassling with since there are other less complicated means (such as using a different arbitrary domain).

Conversely, that wikipedia article in the "linux" section describes a method of giving normal DNS priority via configuration in /etc/nsswitch.conf. This is explained in greater detail in man nsswitch.conf.

There is a yet simpler way to get that working on linux if you are just using a handful of static IP addresses, which it sounds like you are. Edit into /etc/hosts:   ipmi.local

And it will instantly be resolved. The mappings declared in that file supersede any other address resolution method (unless that can be configured differently in nsswitch.conf, which I have not checked).

If you are happy with using arbitrary names instead, just pick anything and check it's not being used in some gotcha way by googling it ('.local' would have turned up).

IANA, the "Internet Assigned Numbers Authority", maintains a list of all the top level domains it considers valid, if you really want to ensure there is no collision there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.