Pi Hole and .com Domain

General
1

Hey, all -- been messing around with Pi Hole for a few months now and haven't been driven to drink QUITE yet. :slight_smile: Here's my setup:

I have an Asus router acting as the gateway and as the DHCP server. The Pi Hole has a static IP and is on a dedicated Micro PC. I have registered a .com domain and have it hosted at a DDNS server, pointing at my router. Currently, I have ports 80 and 443 open only for experimental purposes, and I plan to close them at some point in the future. I have no plans to use the domain for any services such as web hosting, email, or the like, although I may set up the VPN function on my router further down the road (hence the DDNS hosting).

The Asus router has a space for a domain name; I have the domain name entered there. The domain is also entered in the Pi Hole under "Settings > DNS" and not anywhere else. When I go to my Terminal, I would like to be able to use commands such as Ping and Traceroute with other devices on my home network solely by hostname (rather than FQDN). Currently, if I ping only by hostname, I get responses from my Asus external IP address. I would like them to come from my hostname's local IP address.

Also when I ping by hostname only, I get my Asus external IP address, regardless of whether the hostname exists or not. I'd like to get the proper error message. Finally, I would like my devices to have the standard "hostname.domain.com" format, which they currently don't. I would also like to disable ".local" if that's possible, although I can also see how that might be problematic.

This is my first foray into learning DNS, so any or all of the above may be naive. If any portion of the above appears to be more work than it's worth for my purpose (learning more about how this works, purely for my own edification), then I'm willing to drop it -- everything but the VPN server, but I don't think the Pi Hole is going to be relevant there.

2

A DynDNS server would just provide the public DNS records for a domain.
Your router's public IP addresses would be considered to host the actual domain, but if you do not run any server within your home network that your router would forward traffic to, then you wouldn't host anything yet.

Note that a public domain (like .com) is publically resolvable, i.e. it would be expected that any public DNS server would return DNS records (like A and AAAA) as configured for such a domain.

Commonly, a device OS may allow you to configure a plain, non-dot hostname that it would try to claim during DHCP negotiation (and probably for zero-configuration services like multicast DNS (mDNS)).

A router's DHCP server may accept that name or give it a different one, and it may or may not inject the respective DNS records for that name into its own DNS server.
In addition, it may distribute a local/search domain name (sometimes configurable) that it may or may not use to create additional FQDN DNS records for.
Clients may or may not use that domain for their DNS requests, by appending it to any given request.

To avoid overlap of public DNS with private network names, it is commonly recommended to use a non-public domain for private networks.
Commonly suggested local domains would be .internal, .lan, or .home.arpa. .local is to be avoided here, as that is reserved for mDNS usage and should not be mixed with plain DNS.

If you decide to use a public domain as local domain instead, you should be aware that your router's DNS (or Pi-hole) could shadow public DNS records, i.e. it may provide a different DNS reply than a public DNS server (e.g. a private range IPv4 for an A request).

Shadowing public DNS records is both sensible and possible, but you should be aware that any non-shadowed record would still be resolvable via public DNS, which can sometimes lead to unexpected or undesired results.
You should also be aware that, while Pi-hole can shadow public DNS records via Local DNS records, it does not fully support split-horizon DNS as would be required for arbitrarily providing resolution based on a requestor's IP, which may or may not pose a problem, depending on your requirements.

All of the above may affect your aspired name resolution.
For further advice, it would help if you share more details, e.g. actual output of commands that failed to meet your expectation.

Also, you may upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

3

Right, I registered that domain name and parked it at Dynu precisely because I'm probably going to set up the VPN Server on my Asus at some point. I do not have any other plans for the domain name, although I do have ports 80 and 443 open right now because I've been studying how to configure everything so that if Jacques Martrand in Paris tries to browse to the site, he'll get the site that I've set up here in my home. Once I'm done studying how those technologies work, I'll be closing those two ports again.

I also wanted to arrange things so that any device on my home LAN would receive the "hostname.mydomain.com" as an FQDN -- again, simply because I wanted to study how it works. If I'm reading you right, though, your response is that although it is hypothetically possible, I'm better using a highly individualized domain name of some kind, such "buckinghorn.wins"? If so, I'll just do that.

What's happening on my LAN right now is as follows.

ping goodhostname = cannot resolve, unknown host
ping badhostname = cannot resolve, unknown host
ping goodhostname.mydomain.com = Resolves to my router's external IP, but pings time out
ping badhostname.mydomain.com = Resolves to my router's external IP, but pings time out
ping goodhostname.local = resolves to the private IP for goodhostname and receives responses
ping badhostname.local = cannot resolve, unknown host

So where would you suggest I start -- go to each location on the router and on the Pi Hole and clear any setting that has myhostname.com in it?

4

Please start by sharing actual command output, as requested.

Your above descriptions would only allow for generic advice as follows:

As mentioned, .local is the domain reserved for mDNS usage.
DNS isn't involved in those resolution results.

For the same reason, ping isn't adequate to analyse DNS issues, as it employs a variety of procedures to resolve names, not just DNS.
Instead, use nslookup, dig or drill.

As those involve a public domain, Pi-hole wouldn't be involved.
Resolution results are returned by public DNS, unless you shadowed those domains in Pi-hole.
ping timing out has nothing to do with DNS, it would suggest a connectivity issue - in this specific case, probably because your router is not responding to ping requests.

For commenting on those, sharing actual output would be required.
But as mentioned, output from nslookup or dig would be preferred.

Also, sharing a debug token would allow us to see your local definitions and check your DNS configuration for other local resolution specifics.

No, my recommendation was to consider using one of the generic, non-public domains intended for use in private networks.

DNS is a public service that can be accessed globally, while the machines in your local network and the names that they are using are only known in that private network, either by virtue of your router or Pi-hole.

By using a public domain for your local network, you are potentially blending those namespaces together. This is viable, with the caveats about shadowing public records I've mentioned previously, but you want to consider carefully which names you would want to appear in public DNS (via your DynDNS provider), and how you'd like them to resolve when at home connected to your private network (via Pi-hole, either by serving local definitions or by forwarding to a public DNS server), and when away connected to a public network (via public DNS servers).

5

Adding to above, I would advice against using/configuring a public domain name as a search suffix domain at home!
If you do, the public DNS records you've create for that domain wont resolve on your local network bc those queries wont be forwarded to upstream but blocked instead by below settings (those queries are considered "local"):

image
image832Ă—494 46 KB

Your router does something similar.
And if you disable above settings, certain local queries that cant be answered by Pi-hole or router will leak to the public upstream DNS server(s) which is not desired.

You can configure a private sub domain instead like home below for the public domain dehakkelaar.nl:

$ sudo pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
   domain-name: "home.dehakkelaar.nl"

$ dig +short @dns.google. dehakkelaar.nl.
85.17.60.100

$ dig +short @dns.google. home.dehakkelaar.nl.
$

That way queries for names intended for local at home will not escape your LAN.
And public records you've created for the public domain will still resolve at home.
But will require you to administer DNS records at two places for at home and public.

6

I had a feeling that when I undertook this little project, I might be biting off more than I was ready to chew, and it’s now clear that I might no even have had a clear idea of just how big a bite I was taking. That being the case, I’m going to review some things and take a a few steps backward. Thank you to all for your feedback.

As to providing specific output for pings and the like, I’m always leery about doing so out of privacy concerns — which is amusingly ironic, considering that I was about to do it in a far worse way without even realizing it.

Okay, signing off for a while… I’ll probably be back in a few months to ask about the latest mess over gotten myself into!

7

It seems to me you are almost there.
Relevant considerations have been covered by our conversation.

What is missing is some additional diagnostics and foremost some knowledge about your current configuration, which you could provide by simply sharing a debug token with the Pi-hole team.

Your debug log would allow us to review your configuration and steer you in the right direction.

8

Hm. Okay, maybe so. Please excuse me, I'm really not used to asking for help, so I'm never really sure whether I'm doing it right or only being a nuisance. Anyway:

In the interim, I have been attempting to remove all references to my .com domain name and replace them with home.arpa instead. This can always be revisited in the future when I have a firmer grasp on DNS, but for now, simplification would appear to be in order.

Let's see how I'm doing so far:

https://tricorder.pi-hole.net/zInJdNxv/

11

Apologies for replying late.

There was an intermittent certificate issue which prevented us from accessing your log, and by now, it has expired.

Could you please share a fresh token?

12

Sure, here you go.
https://tricorder.pi-hole.net/zUOjos50/

It really is amazing to me that this is so difficult. The thing that sent me down this rabbit hole so long ago was that I had set up a number of WiFi light bulbs that were all showing up with the same hostname. All I wanted to accomplish was to be able to assign my own hostname to those bulbs -- and, subsequently, to the other devices on my network as well -- and then to have those hostnames behave the way one would normally expect them to behave, responding to pings and so on by hostname (not FQDN). I would have thought that assigning hostnames by creating DHCP reservations on the Asus router would be all that was required. Not even close!

13

And yes, it would be that simple - provided your router would populate its internal DNS server from its DHCP server's information. Some routers don't.

Your debug log shows that you have defined a single DNS record within your Pi-hole:

*** [ DIAGNOSING ]: contents of /etc/pihole

-rw-r--r-- 1 root root 36 Sep  2 14:38 /etc/pihole/custom.list
   192.168.10.61 chandelier2.home.arpa

You have also correctly configured Pi-hole's Conditional Forwarding, for the same local domain that your router is distributing via DHCP:

*** [ DIAGNOSING ]: Setup variables
    REV_SERVER=true
    REV_SERVER_CIDR=192.168.10.0/24
    REV_SERVER_TARGET=129.168.10.1
    REV_SERVER_DOMAIN=home.arpa

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 312 bytes from enp2s0:192.168.10.1
     Offered IP address: 192.168.10.2
     DHCP options:
      Message type: DHCPOFFER (2)
      domain-name: "home.arpa"
      dns-server: 192.168.10.2
      router: 192.168.10.1
      --- end of options ---

Also, your router's DHCP server correctly distributes your Pi-hole machine's IPv4 as local DNS server.

This would result in clients querying Pi-hole for DNS, and Pi-hole asking your router to resolve local domains, except for the chandelier one that it would answer directly.

Let's check if your router at 192.168.10.1 would supply correct DNS replies for local names.
Please share the output of:

nslookup hostname 192.168.10.1

nslookup hostip 192.168.10.1

Substitute hostname with a hostname from your network, and hostip with that host's IP address.

14

I've been thinking that, after having had this Asus RT-AX55 for just under a year, I might be reaching the limits of what I want to accomplish inside the home. Perhaps my suspicions are right. Separate discussion, though.

To take the first thing first: that entry about the chandelier (as you've probably already surmised) was something I did as part of my troubleshooting efforts. It can be deleted at any time.

The DHCP pool on the router is currently defined as:
192.168.10.7
192.168.10.200
Inclusive. I left the space at the bottom for static IPs for server-oriented device (such as the Orville itself) and the upper end for configuring the router's VPN server if I ever decide to look into that, along with some other free space for any other non-DHCP addresses I might want for experimental purposes. Not sure whether that matters, so let's try one in the pool, one not. The first is a linux box with a static IP, the second is a DHCP-reserved light bulb:

nslookup tydirium 192.168.10.1

Server: 192.168.10.1
Address: 192.168.10.1#53

** server can't find tydirium: NXDOMAIN

nslookup 192.168.10.3 192.168.10.1

Server: 192.168.10.1
Address: 192.168.10.1#53

** server can't find 3.10.168.192.in-addr.arpa: NXDOMAIN

nslookup Lamp1_Bulb1 192.168.10.1

Server: 192.168.10.1
Address: 192.168.10.1#53

** server can't find Lamp1_Bulb1: NXDOMAIN

nslookup 192.168.10.30 192.168.10.1

Server: 192.168.10.1
Address: 192.168.10.1#53

** server can't find 30.10.168.192.in-addr.arpa: NXDOMAIN
15

Your nslookup results prove that your router's internal DNS server does not know about local names.
This is a deficiency of your router, but we are far from being out of options. :wink:

If you can't address this on your router, it should be easy enough to attach plain, non-dot names to IP addresses via Pi-hole's Local DNS records in that case.
If you've got lots of clients, it may be more convenient to edit /etc/pihole/custom.list directly instead.

Just make sure that your router would hand out fixed IP addresses to each and any of your clients.

Optionally, you could additionally create a custom configuration at /etc/dnsmasq.d/42-local-domain-awareness.conf with the following contents:

expand-hosts
domain=home.arpa
local=/home.arpa/

This would have Pi-hole also resolve *.home.arpa DNS records for your plain hostnames.
It also would make switching your local domain name easier (if you'd consider to return using your public domain or a subdomain thereof), as you'd just have to change that above and in your router.

Check for potential syntax errors:

pihole-FTL dnsmasq-test

If OK, run pihole restartdns to take those settings into effect - that also applies to manually editing custom.list.

Note that the upcoming Pi-hole v6 would expose related options via its UI (in Expert Mode), so creating a custom file wouldn't be required.

Alternatively, you may opt to shift DHCP from your router's DHCP server to Pi-hole's, which would limit the amount of naming to those clients that you actually want to label with a specific name (like your light bulbs). Enabling Pi-hole's DHCP server would also make above custom configuration redundant, as it would automatically apply them.

Of course, your router has to support disabling its DHCP server, or at least shrink its range to just accomodate your Pi-hole machine.

16

I’ve been trying to use Pi Hole’s Local DNS feature… that’s what that “Chandelier” entry is, part of my investigation. (Result: I can no longer see that device on my network at all, by hostname, FQDN, or IP address.)

Manually editing the custom.list file is the kind of solution I was trying to avoid in the first place, so I don’t want to try that. However, domain awareness looks promising. I’ll give that a look when I get home this evening and let you know how it goes.

17

That would suggest a different additional issue altogether:
If clients cannot resolve Local DNS records, that would indicate that they are not using Pi-hole for DNS.

Run from a client in your network (i.e. not your Pi-hole machine), please share the output of:

nslookup pi.hole

nslookup chandelier2.home.arpa

nslookup chandelier2.home.arpa 192.168.10.2
18

Okay, I’ll take a look at that when I get home as well.

My subway commute is long, and I’m almost out of podcasts. Regarding what I said earlier, do you know of any routers that can be configured to intercept DNS requests that the user has intended for a device on the LAN?

Hrm. Just writing that sentence makes me see why almost everyone advises against it. So many ways that a bad hostname can be mishandled.

19

I tried using the Pi Hole DHCP a few months or so ago, and everything was working perfectly. Then I foolishly continued studying the matter and saw several people advising that using the Pi Hole DHCP was recommended only if your router did not support DHCP, so I moved DHCP back to the router, everything broke again, and it hasn't worked right since (including a couple of nights ago when I tried moving it back to the Pi Hole).

Anyway.

Just for additional amusement, this morning right before I left for work, Network Radar on my iPhone suddenly decided to start showing FQDNs again -- but Network Radar on my MacBook Air does not; I've been going over the settings on both with a fine-toothed comb and can't see where the distinction lies.

Here are the chandelier results you were asking about. I'm going to have a look at the domain awareness option you mentioned, and then I really should knock it off for at least a little while and try to get some homework done.

nslookup pi.hole

Server: 192.168.10.2

Address: 192.168.10.2#53

** server can't find pi.hole: NXDOMAIN

nslookup chandelier2.home.arpa

Server: 192.168.10.2

Address: 192.168.10.2#53

** server can't find chandelier2.home.arpa: NXDOMAIN

nslookup chandelier2.home.arpa 192.168.10.2

Server: 192.168.10.2

Address: 192.168.10.2#53

** server can't find chandelier2.home.arpa: NXDOMAIN
20

What does below show (EDIT: run from that same client)?

nslookup -class=chaos -type=txt version.bind 192.168.10.2

Should be similar to below:

$ nslookup -class=chaos -type=txt version.bind 10.0.0.4
Server:         10.0.0.4
Address:        10.0.0.4#53

version.bind    text = "dnsmasq-pi-hole-v2.90+1"
21

Not very:

nslookup -class=chaos -type=txt version.bind 192.168.10.2
Server:		192.168.10.2
Address:	192.168.10.2#53

Non-authoritative answer:
version.bind	text = "Q9-P-7.6"

Authoritative answers can be found from:
22

Thats not Pi-hole answering :smiley:
Is 192.168.10.2 suppose to be the Pi-hole host?

Can check with below on the Pi-hole host:

ip -br -4 address show scope global

If so, check for router related settings that could redirect DNS traffic.
If the client on which you did the nslookup's runs anti virus software, try disabling it temporarily.
And do the version.bind lookup again.