So the default for Pi-Hole DHCP setup is local, any suggestions for the value to put in the domain field?
Huh, neat. Didn't know that. I'll open a ticket against that.
I think most people use ".lan" instead, although it's really up to you.
Could you elaborate on this? I'd like to see this also in a separate thread if you think it doesn't fit in here. Are you refering to this paragraph?
This document specifies that the DNS top-level domain ".local." is a
special domain with special semantics, namely that any fully
qualified name ending in ".local." is link-local, and names within
this domain are meaningful only on the link where they originate.
This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
addresses in the FE80::/10 prefix, which are link-local and
meaningful only on the link where they originate.
But then there is also
It is unimportant whether a name ending with ".local." occurred
because the user explicitly typed in a fully qualified domain name
ending in ".local.", or because the user entered an unqualified
domain name and the host software appended the suffix ".local."
because that suffix appears in the user's search list. The ".local."
suffix could appear in the search list because the user manually
configured it, or because it was received via DHCP [RFC2132] or via
any other mechanism for configuring the DNS search list. In this
respect the ".local." suffix is treated no differently from any other
search domain that might appear in the DNS search list.
When we see a proof for that .local is problematic, we will surely change the default in the next release of Pi-hole.
My main hang-up was Appendix G:
Appendix G. Private DNS Namespaces
The special treatment of names ending in ".local." has been
implemented in Macintosh computers since the days of Mac OS 9, and
continues today in Mac OS X and iOS. There are also implementations
for Microsoft Windows [B4W], Linux, and other platforms.Some network operators setting up private internal networks
("intranets") have used unregistered top-level domains, and some may
have used the ".local" top-level domain. Using ".local" as a private
top-level domain conflicts with Multicast DNS and may cause problems
for users. Clients can be configured to send both Multicast and
Unicast DNS queries in parallel for these names, and this does allow
names to be looked up both ways, but this results in additional
network traffic and additional delays in name resolution, as well as
potentially creating user confusion when it is not clear whether any
given result was received via link-local multicast from a peer on the
same link, or from the configured unicast name server. Because of
this, we recommend against using ".local" as a private Unicast DNS
top-level domain. We do not recommend use of unregistered top-level
domains at all, but should network operators decide to do this, the
following top-level domains have been used on private internal
networks without the problems caused by trying to reuse ".local." for
this purpose:.intranet. .internal. .private. .corp. .home. .lan.
But my experience with this is solely from my reading and discussing with friends.
I'll experiment with it and start a new thread when I've compiled what I find.
c:
EDIT: Forgot to reply to @DL6ER
1 Like
Thanks, I skipped the appendix. Obviously for no good reason, we'll discuss this change internally.
P.S.: I separated this discussion from the original thread.
1 Like
Following up for anyone that may have been curious about this like I was.
In my limited testing, I found the following:
nslookup used exclusively DNS, and successfully resolved .local records hosted by DNSMasq.
Other applications (Firefox, wget, and Chrome (not shown in image)) did not even attempt DNS, using exclusively MDNS and failing.
Testing was conducted in a fresh Ubuntu Desktop 16.04.3 VMWare instance using DNSMasq to serve DNS and using configurations that roughly mimic what may be generated from a Pi-hole install.
I'd be happy to test other configurations, tweaks, and applications while I've got this VM set up.