Out of interest what happens if you visit http://vigor.router in a browser, or if you ping it and visit the http://ipaddress? (make sure there's no browser extension forcing https everywhere). Do you get a router login screen or anything else?
Interestingly I do get the router's login page when I go to http://vigor.router - I wasn't expecting it to work because I haven't configured this name anywhere, however if I do nslookup, sure enough the pi-hole is resolving it:
C:\Users\User>nslookup vigor.router
Server: pi.hole
Address: 192.168.0.6
Non-authoritative answer:
Name: vigor.router
Address: 192.168.0.1
C:\Users\User>
It is a non-authoritative answer which implies it came from the cache. I don't have this name set up in my local pi-hole DNS settings so can only assume it's coming from the client_by_id table that I asked about in my post.
If someone can help me with the SQL to remove the host names in that table (without breaking the referential integrity) it would be much appreciated.
That result would imply that your router(?) at 192.168.0.1 is suppyling that name, which in turn may suggest your Pi-hole may receive that from its upstreams, either because you've enabled Pi-hole's Conditional Forwarding or you are using your router as (one of) Pi-hole's upstream resolver. Or perhaps your router would redirect outbound DNS requests to itself before forwarding them to a resolver of its own devise.
Pi-Hole is not configured with the IP address of my router for DNS, it is using quad9 and cloudflare and doesn't have any conditional forwarding configured. However I did have it set in the past to use my router (it was in /etc/resolv.conf) so I think what has happened is it's picked up the router name and added it into the client_by_id FTL DB table - now I have updated the resolver settings but the name is still floating around in the FTL DB, I would like to try and remove it from the DB but struggling with the SQL to do this (I get a constraint error) - was hoping someone might be able to help with that.
You should establish where that resolution actually comes from before considering to manipulate database entries.
From your Windows client, please rerun your previous:
nslookup vigor.router
Then check your /var/log/pihole.log for the corresponding entries, or use Tools | Tail pihole.log to monitor that lookup, and share those log lines.
Aaaargh this is driving me nuts!
pihole.log shows this:
Jan 3 11:52:14 dnsmasq[1017]: query[A] vigor.router from 192.168.0.119
Jan 3 11:52:14 dnsmasq[1017]: forwarded vigor.router to 1.1.1.1
Jan 3 11:52:14 dnsmasq[1017]: reply vigor.router is 192.168.0.1
Jan 3 11:52:14 dnsmasq[1017]: query[AAAA] vigor.router from 192.168.0.119
Jan 3 11:52:14 dnsmasq[1017]: cached vigor.router is NODATA-IPv6
If I use dig directly to cloudflare, quad9, google, I get this...
root@ntp1:~# dig @1.1.1.1 vigor.router.
; <<>> DiG 9.16.27-Raspbian <<>> @1.1.1.1 vigor.router.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43227
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Message has 2 extra bytes at end
;; QUESTION SECTION:
;vigor.router. IN A
;; ANSWER SECTION:
vigor.router. 60 IN A 192.168.0.1
;; Query time: 0 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jan 03 11:52:54 UTC 2023
;; MSG SIZE rcvd: 48
root@ntp1:~# dig @9.9.9.9 vigor.router.
; <<>> DiG 9.16.27-Raspbian <<>> @9.9.9.9 vigor.router.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34127
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Message has 2 extra bytes at end
;; QUESTION SECTION:
;vigor.router. IN A
;; ANSWER SECTION:
vigor.router. 60 IN A 192.168.0.1
;; Query time: 0 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Tue Jan 03 11:53:09 UTC 2023
;; MSG SIZE rcvd: 48
root@ntp1:~# dig @8.8.8.8 vigor.router.
; <<>> DiG 9.16.27-Raspbian <<>> @8.8.8.8 vigor.router.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30133
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Message has 2 extra bytes at end
;; QUESTION SECTION:
;vigor.router. IN A
;; ANSWER SECTION:
vigor.router. 60 IN A 192.168.0.1
;; Query time: 0 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jan 03 11:53:22 UTC 2023
;; MSG SIZE rcvd: 48
root@ntp1:~#
It looks like my Draytek Vigor router is doing DNS interception - I need to do some googling on that, maybe it's part of the parental control features but I've got all that turned off. There might be another setting somewhere I need to tweak.
1 Like
This would support my earlier guess:
So indeed:
EDIT: In addition, you may want to consider your ISP to redirect traffic as well. Some ISPs may offer security/parental control DNS features via their network (though given that a private range IP is returned, I don't consider that very likely).
Would that chaos class version test be a valid diagnostic to further confirm? Should return the text indicated but instead will return something or nothing from the router.
Perhaps not.
It may be an option only if you'd happen to know the expected outcome to compare it with - and public resolvers like 1.1.1.1 may not disclose version information at all. If the suspected redirection target would do so as well, we'd know as much as before.
(In the post you are referring to, we intended to send that dig specifically towards a root server.)
Besides, Pi-hole's log already established that something dodgy is happening upstream. 
Edit
I customarily use a less enigmatic lookup against a filtering public resolver to test for redirection:
nslookup flurry.com 80.241.218.68
If that doesn't return 0.0.0.0, something is redirecting DNS traffic.
1 Like
That's what I was wondering – running dig against selected servers, such the two root servers you use in that post, or against quad9 (tested here), would return a version text normally, but if the router is intercepting dns it would mess that up (router's version or blank) and reveal that interception is taking place. As you say though, Pi-hole has already shown this happening, albeit with some interpretation needed of what's being seen. This is all very useful info for similar situations arising in future.
I'm not sure that's a valid test, I think the router is specifically intercepting queries for "vigor.router" because it thinks "oooh that's me, I better return my IP address", anything else is being passed through. Right at the start of this thread you can see that it returns this name when a reverse lookup is done against it, but nowhere in the configuration have I set this name so it must be hard baked into the firmware, I suspect it's to help with the user manual, I haven't read it but it's probably easier to document the router management URL as "http://vigor.router" rather than trying to explain how to find out the IP address.
Unfortunately I had the Pi-hole set to use the vigor IP as it's DNS resolver so now that name seems to have found it's way into the client table and different clients are being identified with that name.
Let me see if I can upload a screenshot...
So now that the Pi-hole is not using the vigor anymore for it's DNS resolver what I'd like to do is remove these entries from the FTL DB.
If I remember correctly, I've resolved similar issues with odd or incorrect system names by creating a "fake" DNS entry in Pihole for a device, then deleting it.
Local DNS
DNS Records
Enter a fake domain name entry pointing to the IP address you're having a problem with
Delete the entry
Holy crap that worked! As well as setting the dummy DNS name I also had to delete the clients from the "network" page, but when they were rediscovered they came back without the host name. Brilliant, thanks!
A friend had a similar situation – Chromebook appearing in clients as "mint.lan" because he was running Linux Mint when Pi-hole first saw it. Then he was later running the Chromebook normally and Pi-hole still listed it as mint.lan. Fixed by taking the Chromebook off the network, deleting the DHCP lease, and reconnecting the Chromebook so it picked up a new lease and the correct hostname.
I'm really glad that helped! 
Just curious:
What is
nslookup vigor.router
returning now?
It's still returning itself (and intercepting the forwarded query), but is no longer appearing in the clients list (Pi hole is not using the vigor router for DNS resolution any longer, it uses itself)....
root@ntp1:~# nslookup vigor.router.
Server: 192.168.0.6
Address: 192.168.0.6#53
Non-authoritative answer:
Name: vigor.router
Address: 192.168.0.1
root@ntp1:~#
actually it looks like pi hole has cached it now:
Jan 3 22:45:08 dnsmasq[23979]: query[A] vigor.router from 192.168.0.6
Jan 3 22:45:08 dnsmasq[23979]: cached vigor.router is 192.168.0.1
Jan 3 22:45:08 dnsmasq[23979]: query[AAAA] vigor.router from 192.168.0.6
Jan 3 22:45:08 dnsmasq[23979]: cached vigor.router is NODATA-IPv6
Then there is a chance that those unwanted entries will reappear.
It seems you've observed that already at some stage in the past:
Pi-hole doesn't make up names for your clients - they have to come from another DNS resolver, or you have to define them in Pi-hole itself.
To mitigate this, you may use the latter to your advantage by creating and keeping Local DNS records for vigor.router pointing to your router's IP addresses.
But we haven't yet determined what caused your Pi-hole to associate some of your regular client IP addresses with that name:
Perhaps your router does return vigor.router for any reverse lookup that matches its own subnet?
If that's the case, you may want to tick Never forward reverse lookups for private IP ranges in Pi-hole's Settings | DNS, and you may have to create local DNS records for your local clients as well.
Yes, that's expected.
Records will go in and out of the cache all the time.
Pi-hole will cache any DNS record (in-memory) for as long as the TTL in the upstream response suggests. For your vigor.router A record, that has been 60 seconds:
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.