Domains
Your network domain serves as the namespace for identifying devices on your local network, enabling you to access devices by name (such as printer.internal or server.home.arpa) rather than memorizing IP addresses such as 192.168.3.10.
The choice of domain impacts several key areas: DNS resolution, potential for conflicts with public internet domains, query leakage to upstream DNS providers, and compatibility with other network protocols. A well-chosen domain ensures reliable local name resolution.
This post also describes configuring Pi-hole to work optimally with your selected domain, particularly in scenarios where Pi-hole operates alongside existing DHCP servers.
Choosing a domain name
If you do not own a domain, there are several options available to you:
home.arpa
The domain home.arpa has been officially reserved for home networks. It has the advantage that there is no possible risk of collision with an external domain name, and from a privacy perspective device names on your network should not leak to your upstream dns provider.
internal
A proposal is currently in place for the domain internal to be reserved for private networks, with similar advantages to home.arpa, but usable outside of the home-networking environment, such as by businesses. The proposal is backed by IANA, ICANN (who have already reserved internal for this purpose), and by Google.
- domain provided by router/modem manufacturer
For example fritz.box is commonly used by AVM's Fritz!Box range of home modem/routers.
- Consider avoiding ad-hoc domains
The domains lan, home, network, private are frequently used on an ad-hoc basis as they are not currently allocated as TLDs. However the behaviour of these domains is not defined or guaranteed to be suitable for use. They also suffer from the problem that queries for these domains if unanswered by your network may leak to your upstream DNS provider.
- Do not use
local
The domain local is reserved for mDNS (multicast DNS) and may cause conflicts or hard to diagnose network issues. It should not be used as the domain on your network.
For networks where Pi-hole is not providing DHCP services.
By default, Pi-hole will not forward requests for local domain names to the upstream DNS (including .home.arpa and .internal, as this is disallowed by the standard/proposal).
If Pi-hole is not set up as your DHCP server, then you may want to enable conditional forwarding and direct queries relating to devices within your network to the system hosting your DHCP server (typically your modem/router in a home network). This will allow connection by name rather than needing the ip within your network, and will likewise allow Pi-hole to identify devices making queries by their hostname rather than ip.
You will need your modem/router's ip address and network address range which will be available to you on your modem/routers settings.
For example, if your home network were to use the domain .internal, with a network spanning 192.168.3.0-192.168.3.255, and your modem router's ip address is 192.168.3.1. The entry in the conditional forwarding option would be as follows:
true,192.168.3.0/24,192.168.3.1,internal
Detailed instructions are available in the Pi-hole DNS settings page (under expert mode).
If Pi-hole is providing both DHCP and DNS services for your network
You should only need to set your domain in Pi-hole's settings, and most devices should pick it up automatically via DHCP along with their IP address. If configuring any devices manually, be sure to use the same domain that you have told Pi-hole.
Testing your domain configuration
After configuring your domain, you can verify whether it's working correctly by testing local device name resolution. In the examples below, change printer.home.arpa and 192.168.3.10 to a hostname and ip address that are present on your network.
Linux/macOS (using dig)
# Test resolving a device on your network
dig printer.home.arpa
# Test reverse lookup (IP to hostname)
dig -x 192.168.3.10
Microsoft Windows (using nslookup)
# Test resolving a device on your network
nslookup printer.home.arpa
# Test reverse lookup (IP to hostname)
nslookup 192.168.3.10
What to expect
- Successful resolution: You should see the device's IP address returned
- Failed resolution: Check that the device name and domain are correct, and that conditional forwarding is properly configured
- Reverse lookup: Should return the device's hostname if DHCP is managing name assignments
If resolution fails, then verify your Pi-hole DNS settings.