Running dnsbench shows that the pihole is a "Non-routable local internet address" with about 20ms cached access time and the conclusions flag it as "This system's nameserver intercepts name errors."
I'm using unbound in recursive mode as my sole nameserver.
A quick websearch shows that this is not really a unique software name. Do you mean this one?
edit Ah, it seems it's this one, I've just seen the title of the post.
How do you run the test exactly and is there any help text available for the status?
is this a bad or a good thing?
This is expected, it is an IP address in your home network.
This is a bit slow but also not bad.
The documentation for dnsbench is at https://www.grc.com/dns/operation.htm
Here's a snippet from the documentation referring to the "Non-Routable" status:
Orange colored servers may be somewhat less desirable to use depending upon your feelings about the handling of typos and nonexistent domain names: The Benchmark colors a nameserver orange when it does not return an error in response to a query for a non-existent domain name. DNS nameservers are supposed to simply return a “Not Found” error to indicate that the requested domain name does not exist. But ISPs and third-party DNS service providers are adopting a new “revenue-enhancing” trick: Instead of returning an error, they redirect the user's browser to their own marketing-related search page. This gives them a way of being “helpful” and of generating some additional marketing and advertising revenue from your typos or bad links — by causing you to confront a page you didn't ask for and probably don't want.
All of these are changes to the normal operation of the utility. Normally the nameserver will be listed in green as "Available and working", so the orange "Non-routable..." is an unexpected change and indicates something changed in the way the nameserver is responding.
Intercepting name errors is what ISPs do when they redirect to advertisements. This is unexpected from the pihole.
Cached DNS lookups usually take <1ms, so 20ms is a pretty large increase. Again, an unexpected result.
I reverted to the master release and dnsbench returned to normal operation. Then I went back to v5.9 and the problem returned. One last change back to master and all is good again.
Confirmed with docker containers. Though I'm not really sure how to interpret this. @DL6ER I am imagining this is down to something that has changed at the dnsmasq level?
192.168.1.253 = pihole/pihole:beta-v5.9
127.0.0.1 = pihole/pihole:latest
The beta version returns status NODATA instead of the expected NXDOMAIN for non existing domains, even though the upstream DNS server definitely responded with NXDOMAIN.
Is that a deliberate change or a bug?
# Lookup against pihole/pihole:beta-v5.9 using my router as upstream DNS server
$ dig ldsaaoskfaksdf.com @127.0.0.1
; <<>> DiG 9.16.1-Ubuntu <<>> ldsaaoskfaksdf.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38659
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ldsaaoskfaksdf.com. IN A
;; Query time: 60 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jul 05 00:08:57 CEST 2021
;; MSG SIZE rcvd: 47
# Lookup against my router directly
$ dig ldsaaoskfaksdf.com @192.168.178.1
; <<>> DiG 9.16.1-Ubuntu <<>> ldsaaoskfaksdf.com @192.168.178.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4377
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ldsaaoskfaksdf.com. IN A
;; AUTHORITY SECTION:
com. 883 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1625436507 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 192.168.178.1#53(192.168.178.1)
;; WHEN: Mon Jul 05 00:09:14 CEST 2021
;; MSG SIZE rcvd: 120
Could you please share the corresponding lines matching your first dig from /var/log/pihole.log*?
I pretty much also experience the rather slow cached access time, like dmile.
I killed the container again and lost the logs to that specific query, so here are new ones:
It's like the beta version refuses to accept NXDOMAIN as an answer.
Here is a lookup against my router first to show the answer really is NXDOMAIN:
$ dig lasdoasdfioh.askfh @192.168.178.1 +nostats
; <<>> DiG 9.16.1-Ubuntu <<>> lasdoasdfioh.askfh @192.168.178.1 +nostats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23878
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;lasdoasdfioh.askfh. IN A
;; AUTHORITY SECTION:
. 2278 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021070500 1800 900 604800 86400
And here are a few lookups for different records against the pihole/pihole:beta-v5.9 docker container using my router as upstream DNS server again:
$ dig a lasreuitzdfioh.askfh @127.0.0.1 +nostats
; <<>> DiG 9.16.1-Ubuntu <<>> a lasreuitzdfioh.askfh @127.0.0.1 +nostats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31198
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;lasreuitzdfioh.askfh. IN A
$ dig aaaa lasreuitzdfioh.askfh @127.0.0.1 +nostats
; <<>> DiG 9.16.1-Ubuntu <<>> aaaa lasreuitzdfioh.askfh @127.0.0.1 +nostats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44459
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;lasreuitzdfioh.askfh. IN AAAA
$ dig mx lasreuitzdfioh.askfh @127.0.0.1 +nostats
; <<>> DiG 9.16.1-Ubuntu <<>> mx lasreuitzdfioh.askfh @127.0.0.1 +nostats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1083
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;lasreuitzdfioh.askfh. IN MX
They all result in NODATA, even though for the MX record, Pi-hole won't say that. Also, why is the aa flag set in all answers from the beta Pi-hole version? Does the new version think it is authoritative for these non-existing resource records? Or am I misinterpreting that flag?
# excerpt from pihole.log
Jul 5 14:52:25: query[A] pi.hole from 127.0.0.1
Jul 5 14:52:25: internal pi.hole is 127.0.0.1
Jul 5 14:52:39: query[A] lasreuitzdfioh.askfh from 172.20.0.1
Jul 5 14:52:39: forwarded lasreuitzdfioh.askfh to 192.168.178.1
Jul 5 14:52:39: reply lasreuitzdfioh.askfh is NODATA-IPv4
Jul 5 14:52:43: query[AAAA] lasreuitzdfioh.askfh from 172.20.0.1
Jul 5 14:52:43: forwarded lasreuitzdfioh.askfh to 192.168.178.1
Jul 5 14:52:43: reply lasreuitzdfioh.askfh is NODATA-IPv6
Jul 5 14:52:49: query[MX] lasreuitzdfioh.askfh from 172.20.0.1
Jul 5 14:52:49: forwarded lasreuitzdfioh.askfh to 192.168.178.1
Jul 5 14:52:55: query[A] pi.hole from 127.0.0.1
Jul 5 14:52:55: internal pi.hole is 127.0.0.1
Jul 5 14:53:26: query[A] pi.hole from 127.0.0.1
As a side note, the current stable version (pihole/pihole:latest) won't say anything about the non-existence of the MX record in the logs or on the dashboard either, but at least dig will receive the correct NXDOMAIN status. Actually, the current stable version won't say anything about the non-existence of any record other than A and AAAA, the Reply column will always show N/A. Maybe that is something that can be fixed as well together with the issue at hand.
# this is against the pihole/pihole:latest docker container
$ dig mx lasdoasdfioh.askfh @127.0.0.1 +nostats
; <<>> DiG 9.16.1-Ubuntu <<>> mx lasdoasdfioh.askfh @127.0.0.1 +nostats
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39032
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;lasdoasdfioh.askfh. IN MX
;; AUTHORITY SECTION:
. 2025 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021070500 1800 900 604800 86400
1 Like
It is a bug, I traced it down to the exact commit in dnsmasq that caused this and will report my finding to the mailing list.
Very good investigation, that's actually the issue here. The bug in dnsmasq causes it to think that we forwarded a query for a locally known name (because it was for an unknown type). Even though the answer is NXDOMAIN, dnsmasq rewrites it since it think it knows that the domain exists, even if upstream doesn't.
1 Like
I pushed a possible fix to the release branch, docker will follow in a bit. Please update.
