Inconsistent DNS SRV and TXT Record Resolution When Using Search Domains

Help Community Help
1

The issue I am facing:
I am encountering inconsistent behavior with Pi-hole when resolving SRV and TXT DNS records for subdomains of the search domain set in Pi-hole. For example, when executing dig _minecraft._tcp.minecraft.gability.com -t SRV, I receive an NXDOMAIN response, indicating that the record does not exist:

; <<>> DiG 9.10.6 <<>> _minecraft._tcp.minecraft.gability.com. -t SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55986
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;_minecraft._tcp.minecraft.gability.com. IN SRV

;; Query time: 42 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Mar 13 11:55:18 CET 2024
;; MSG SIZE  rcvd: 67

Additionally, appending a dot at the end of the domain name (indicating it's a fully qualified domain name) did not resolve the issue:

; <<>> DiG 9.10.6 <<>> _minecraft._tcp.minecraft.gability.com. -t SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55986
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;_minecraft._tcp.minecraft.gability.com. IN SRV

;; Query time: 42 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Mar 13 11:55:18 CET 2024
;; MSG SIZE  rcvd: 67

However, when I change the search domain to a different value and re-execute similar dig commands, the SRV and TXT records resolve correctly, indicating the issue is tied to how Pi-hole handles the specific search domain.

Details about my system:

  • Pi-hole version: v5.17.3 (Core), v5.21 (Web), v5.25.1 (FTL)
  • Operating System: Debian 11
  • Hardware: Raspberry Pi (aarch64)
  • DNS server used upstream: Google DNS (8.8.8.8 and 8.8.4.4). Same result with unbound.
  • Network setup: Pi-hole is the DHCP server and DNS resolver in the network.

What I have changed since installing Pi-hole:

  • Configured Pi-hole to use Google DNS as the upstream DNS server.
  • Attempted to append a dot at the end of the domain name to treat it as a fully qualified domain name, which did not resolve the issue.
  • Enabled DHCP server functionality within Pi-hole.
  • Removed Unbound DNS from my setup, previously used as a recursive server.
  • Attempted to debug and resolve the issue by checking Pi-hole and system configurations, flushing DNS caches, and testing with direct dig queries.
  • Nothing useful in logs.
  • Adding the search domain search gability.com manually to /etc/resolv.conf didn't do anything.
  • I ran pihole -d and check that everything looks fine.
2

You didn't state the search domains you use, nor how such a search domain should affect resolution.

Also, please 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

Hi Bucking_Horn

Thank you for your prompt response. My apologies for the oversight in my initial explanation. Here are the elaborated details:

Search Domains:

  • The search domain configured in my Pi-hole is gability.com. When this search domain is set, I observe that Pi-hole does not resolve SRV and TXT records for subdomains under gability.com correctly.

Impact on Resolution:

  • With the search domain gability.com configured, queries like dig _minecraft._tcp.minecraft.gability.com -t SRV or dig _acme-challenge.gability.com -t TXT return NXDOMAIN. This suggests that Pi-hole might be interpreting these queries within the local domain context, impacting their resolution externally.

Example Where Omission Worked:

  • When I remove the search domain or change it to a different value, the resolution succeeds. For instance, querying dig _minecraft._tcp.minecraft -t SRV without gability.com as the search domain successfully retrieves the expected SRV records.
; <<>> DiG 9.10.6 <<>> _minecraft._tcp.minecraft -t SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59256
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_minecraft._tcp.minecraft.	IN	SRV

;; AUTHORITY SECTION:
.			1446	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2024031300 1800 900 604800 86400

;; Query time: 52 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Wed Mar 13 11:56:24 CET 2024
;; MSG SIZE  rcvd: 129

Debug Log:

I hope this information clarifies the situation. Please advise on the next steps or if additional details are required.

4

No, it doesn't - it returns NXDOMAIN:

gability.com is a public domain.

Why are you using a public domain as local/search domain?

That would only make sense if you are hosting a local DNS server that is authoritative for that domain. While this is quite possible, it would be highly unusual for a consumer grade home network.

With your current config, Pi-hole will act as authoritative DNS server for gability.com, i.e. the corresponding records have to be administered by Pi-hole itself, e.g. via Local DNS records.
Your debug log doesn't show any custom SRV record configurations, so your observation is expected.

For typical home usage, you should use designated domains like lan or home.arpa instead.

5

Why are you using a public domain as local/search domain?

Probably this is a lack of experience. I have a full cluster of machines at home. Some of these machines contain production applications and some of them are only local applications. I was thinking about mimicking what cloud providers have (public and private DNS) where you can have a set of domains charing the same root but some of them are exposed to publicity and some are internal.

That would only make sense if you are hosting a local DNS server that is authoritative for that domain. While this is quite possible, it would be highly unusual for a consumer grade home network.

I now understand you and your advice makes much sense. but let me shoot a final question. Can the home domains share a subdomain from the base one (ex. home.gability.com)? I am asking from the best practice perspective rather than the technical feasibility.

6

Your gability.com is public, so a publically accessible DNS server will be authoritative for it, holding its DNS record definitions. That DNS server will receive and process DNS requests from DNS resolvers like Quad9, Cloudflare, Google or a local unbound from users using Pi-hole and unbound all over the world.

As Pi-hole is operating as a local DNS server within the boundaries of your private network, it will answer to DNS requests of clients from your local network only.
As it is the first DNS server in your clients DNS requests, you could shadow public DNS records with Pi-hole, e.g. by defining gability.com to point to 192.168.1.2.
While this would allow your local clients to access 192.168.1.2, it would cut them from learning gability.com's public IP via DNS.

You could well use that mechanism to put a name to your local host's IPs that reflects your public domain by defining the respective Local DNS records in Pi-hole (with or without Pi-hole acting as DHCP server), but should stay aware that your local clients will only see Pi-hole's answers, while the rest of the world will see the answers from public DNS servers.

For public DNS, note that home.gability.com is yet a different domain, so as DNS is a hierarchical distributed system, a different DNS server could be authoritative for it. It would depend on your contract whether you can manage that subdomain as well.

It's not entirely clear what you want to achieve, but you'd have to be careful about where you put your DNS records.
For example, if you'd want that _minecraft._tcp.minecraft.home.gability.com to stage Minecraft LAN parties at home, I'd consider moving that SRV and other respective DNS records to your Pi-hole.
If you'd use that to host a match between some friends over the Internet, then those records should probably stay with your domain registrar's public DNS server.

For a web server at 192.168.1.42 that you'd want to allow public access to while hosting it from your private network, you probably want both a public DNS record like apache.home.gability.com as well as a local DNS record for that same domain in Pi-hole, so that local clients will talk to 192.168.1.42, while public clients will resolve that name to the public IPv4 of your router, port forwarding traffic to your local server.
If you don't want to expose that publically, but still use it yourself when away from home, then use VPN software to securely access your private network instead (which would require no public DNS entry for apache.home.gability.com).

1 Like
7

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.