Local DNS not resolving

The issue I am facing:
I've added DNS records (A) in the web gui and pihole is not resolving them.

eg. sub.dev.local.home

From anywhere in my LAN the response is the same:

Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find sub.dev.local.home: SERVFAIL

pihole.log

Mar 17 14:04:09 dnsmasq[3356626]: query[A] sub.dev.local.home from 192.168.70.1
Mar 17 14:04:09 dnsmasq[3356626]: /etc/pihole/custom.list sub.dev.local.home is 192.168.70.10
Mar 17 14:04:09 dnsmasq[3356626]: query[DS] home from 192.168.70.1
Mar 17 14:04:09 dnsmasq[3356626]: forwarded home to 1.1.1.1

It appears pihole found the correct IP 192.168.70.10 in custom.list then went on to forward the domain .home upstream.

Not sure what's going on. Any help is greatly appreciated. Thanks

Details about my system:

Router:

  • Provides DHCP
  • Domain name: local.home
  • Forwards all DNS queries to Pihole

Environment:

  • Pihole OS: Ubuntu 20.04.2
  • Pihole: v5.2.4
  • Pihole web: v5.4
  • FTL: v5.7

What I have changed since installing Pi-hole:

  • Interface listening behavior: Listen on all interfaces, permit all origins
  • Never forward non-FQDNs: Checked
  • Use Conditional Forwarding: Checked

Conditional Forwarding setup:

  • LAN: 192.168.70.0/24
  • DHCP: 192.168.70.1
  • Local Domain: local.home

The upstream forward appears to be for a DNSSEC signature. Because .home is not delegated (and in fact is in the root zone as a hard "does not exist") I'm betting the SERVFAIL you see is a DNSSEC validation error.

2 Likes

What does the dig output for that hostname show?

Hi tresni,

I flicked a few "switches" on the pihole and router before I had a chance to see your response but it seems like the problem of forwarding the query upstream seems to have gone away. Looking at the configuration, it does look like I've turned off DNSSEC.

However, the issue with Local DNS not resolving still seems to be present.

# nslookup sub.dev.local.home
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find sub.dev.local.home: REFUSED

There are literally hundreds of lines of this in pihole.log

Mar 18 09:09:42 dnsmasq[3497630]: query[AAAA] sub.dev.local.home from 192.168.70.1
Mar 18 09:09:42 dnsmasq[3497630]: forwarded sub.dev.local.home to 192.168.70.1
# Which then ends with
Mar 18 09:11:43 dnsmasq[3497630]: reply error is REFUSED

I think there is a query loop somewhere in my system.

Hi Dan,

dig seems to have no trouble resolving it

# dig sub.dev.local.home

; <<>> DiG 9.16.1-Ubuntu <<>> sub.dev.local.home
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16172
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sub.dev.local.home.		IN	A

;; ANSWER SECTION:
sub.dev.local.home.	2	IN	A	192.168.70.10

;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Mar 18 09:02:11 AEDT 2021
;; MSG SIZE  rcvd: 63

I have since found out that a Local DNS record that is is part of the router's domain name does not work, while a DNS record outside a router's domain name works.

  • sub.dev.local.home: Not OK
  • sub.dev.home: OK

Sounds as if you had created a local DNS record for sub.dev record, but not for sub.dev.local.home - your router cannot know that, of course.

Adding the FQDN record as well should fix your problem.

I've added both sub.dev.local.home and sub.dev.home DNS records into pihole but only sub.dev.home is resolving correctly.
# nslookup sub.dev.home

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	sub.dev.home
Address: 192.168.70.10

# nslookup sub.dev.local.home

Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	sub.dev.local.home
Address: 192.168.70.10
;; connection timed out; no servers could be reached

I feel like this issue is leading off into another issue unintentionally. Should I open another ticket?

This is still your initial issue of trying to resolve local FQDNs, isn't it?

In both cases, an IP address is returned.

Strangely, the second sports an additional timeout.

Is that also true when sending those queries directly to your Pi-hole, e.g. dig @pi.hole sub.dev.home -or- nslookup sub.dev.home pi.hole?

Just curious: Why do you define local records for *.home and *.local.home, if only the latter would match your local domain?

Yes it is, but I didn't want to continually bring up new issues and string different issues into the one issue. I'm happy to continue to resolve it in this issue.

Correct

nslookup sub.dev.local.home 192.168.70.12

Server:		192.168.70.12
Address:	192.168.70.12#53

Name:	sub.dev.local.home
Address: 192.168.70.10
** server can't find sub.dev.local.home: REFUSED

Again, no problems resolving sub.dev.home.

I don't need both. I started off with sub.dev.local.home, discovered it didn't work, so I tried sub.dev.home. I guess I can live with sub.dev.home but I found it interesting that sub.dev.local.home didn't work

Is IPv6 enabled in your network?

When querying Pi-hole for sub.dev.local.home, what queries are registering in Pi-hole's logs?

grep local.home /var/log/pihole.log

IPv6 is disabled.

grep local.home /var/log/pihole.log

Mar 20 11:16:32 dnsmasq[3608298]: query[A] sub.dev.local.home from 192.168.70.1
Mar 20 11:16:32 dnsmasq[3608298]: /etc/pihole/custom.list sub.dev.local.home is 192.168.70.10
Mar 20 11:16:32 dnsmasq[3608298]: query[AAAA] sub.dev.local.home from 192.168.70.1
Mar 20 11:16:32 dnsmasq[3608298]: forwarded sub.dev.local.home to 192.168.70.1

It seems A record seems to be resolved correctly which returns 192.168.70.10 but AAAA records are forwarded (back) to the router. And the router doesn't know what to do with it then times out.

That's how I read it with my limited knowledge.

Correction: IPv6 is disabled on my router. So pihole does not have an IPv6 address. But I probably enabled IPv6 during the pihole configuration process:
pihole status

  [✓] DNS service is listening
     [✓] UDP (IPv4)
     [✓] TCP (IPv4)
     [✓] UDP (IPv6)
     [✓] TCP (IPv6)

That's a good guess, but I'm not sure whether that's the case here.

The DS query we saw in the logs earlier may (or may not) be associated with the successful answer directly before it, as it could initiate the CF triggered forward for AAAA records.

But commonly, Conditional Fowarding -in this case, for local.home- would disable DNSSEC (qouting dnsmasq docs).

-S, --local, --server=[/[<domain>]/[domain/]][<ipaddr>[#<port>]][@<source-ip>|<interface>[#<port>]]
(...)
--server=/internal.thekelleys.org.uk/192.168.1.1 will send all queries for internal machines to that nameserver, everything else will go to the servers in /etc/resolv.conf. DNSSEC validation is turned off for such private nameservers, UNLESS a --trust-anchor is specified for the domain in question.

So DNSSEC should only be involved if route-dist would have supplied a specific trust anchor for local.home, or maybe if the router would enforce DNSSEC by virtue of its own configuration.

That's fine.

I was considering IPv6 as a possible source for your local on-device DNS server at 127.0.0.53 on some of your clients bypassing Pi-hole via IPv6.
I guess since IPv6 is disabled in your router (i.e. no public IPv6 prefix for your network), you should be safe, unless your router would offer its own link-local IPv6 for DNS.

Correct, and that perfectly matches your earlier nslookup observations.

You've defined A records for sub.dev.local.home and sub.dev.home.
Pi-hole answers the correct A record IPv4 address to respective nslookups.
Due to Conditional Forwarding for local.home, Pi-hole also forwards a query for the AAAA record for sub.dev.local.home to its CF target.

It is yet unclear why that would result in seemingly arbitrary timeouts, SERVFAIL and REFUSED answers.
They could be a caused by a partial DNS loop.

Is your router configured to use Pi-hole as its upstream DNS server (as opposed to distributing Pi-hole as local DNS server via DHCP)?
If it is, CF won't give you per-client attribution for DNS requests anyway, since Pi-hole would see all DNS requests as originating from your router.

Disabling CF in Pi-hole should fix your issue.

In addition, forwarding anything to your router at all would only make sense if your router knew about local hostnames, and some routers don't. If your router falls into that category, disabling CF would be the correct choice.

If you were distributing Pi-hole as local DNS, you could also decide to add local DNS records with a more specific FQDN, and have that answered with NXDOMAIN or NODATA.
You seem to be using *.dev.local.home already.
You could hence try to create a custom dnsmasq configuration, e.g. /etc/dnsmasq.d/42-local-nxdomains.conf, with the following content:

server=/dev.local.home/

This would allow you to add sub.dev and sub.dev.local.home as local DNS records, but would stop AAAA queries to be forwarded upstream.
Your logs for a corresponding nslookup would look similar to:

query[A] sub.dev.local.home from 192.168.1.20
/etc/pihole/custom.list sub.dev.local.home is 192.168.1.110
query[AAAA] sub.dev.local.home from 192.168.1.20
config sub.dev.local.home is NODATA-IPv6

Less specific FQDNs like sub.local.home would still be forwarded to your router.

Yes it is.

I turned off CF and queries has dropped down to their previous rates ( ~ 200 / hour ).

Additionally, lookups to both sub.dev.home and sub.dev.local.home resolved correctly and quickly.

I'm not doing that atm. I will have to re-visit your suggestions for that at a later time.

For now, I will consider this issue as resolved.

Thanks for your time and perseverance.

A follow up question.

I've now turned off CF but I'm still seeing these:

Mar 22 10:15:03 dnsmasq[3914518]: query[A] localhost.local.home from 127.0.0.1
Mar 22 10:15:03 dnsmasq[3914518]: cached localhost.local.home is NXDOMAIN
Mar 22 10:15:03 dnsmasq[3914518]: query[AAAA] localhost.local.home from 127.0.0.1
Mar 22 10:15:03 dnsmasq[3914518]: cached localhost.local.home is NXDOMAIN

They are not a big issue. But I wonder if it's normal.

nslookup localhost.local.home 192.168.70.12

Server:		192.168.70.12
Address:	192.168.70.12#53

** server can't find localhost.local.home: NXDOMAIN

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