My query log keeps showing a client called "Vigor.router" but I don't have this name anywhere on my network but it seems to be linked to multiple clients.
I previously noticed that my Pi had 192.168.0.1 set up as it's default DNS resolver in /etc/resolv.conf, and if I sent a reverse lookup for my default router 192.168.0.1, it would reply with "Vigor.router"...
I have since updated my Pi so it's now using itself for DNS resolution (resolv.conf now has it's own IP address 192.168.0.6), and I have defined some host entries in the local DNS section:
The problem is that "Vigor.router" is still floating around in my system - if I go to the "known clients" drop down under "client group management" it's appearing multiple times in the list against other clients and also in the query log.
I had a look in the FTL database and cleared out both network and networks_addresses but it just keeps coming back. Then I found another table which seems to store the client names and IPs where I can see "Vigor.router" appearing multiple times:
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:
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.
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.
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.
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.
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.
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)....
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.routerA record, that has been 60 seconds:
