Query log does not show hostnames from pihole DHCP

Help
24

The right order for flushing all the database memory should be

  1. stop FTL,
  2. flush the network database, and
  3. start FTL.

The network database flushing in the current v6.0 development code already takes care of this internally as FTL is now responsible for flushing the tables.

Thanks, I've overseen this very detail. In this case, my suggestion of enabling the DEBUG_RESOLVER mode is even more interesting as we already know that FTL does know the new name and we merely have to find out why the old name is not replaced as it should have been.

25

Heey, sorry for the late reply.

Sadly I am aware of this, though need to convince my wife about the investment in new hardware here :slight_smile:

Good catch. I changed the DHCP domain from the default lan to ip. So it is really strange that lan is used.

How can I do this manually? As when I stopped FTL the web GUI was gone, and the SQL statement complained that I tried modifying a locked table.

Results from var/log/pihole/FTL.log:
log.txt (70.8 KB)

26

Interestingly enough, your Pi-hole does not seem to be able to reply

[2023-06-15 16:46:18.185 19868/T19886] Trying to resolve 192.168.2.245
[2023-06-15 16:46:18.186 19868/T19886] Setting nameservers to:
[2023-06-15 16:46:18.186 19868/T19886]  EXT 0: fe80::1:53 (IPv6)
[2023-06-15 16:46:18.189 19868/T19886]  ---> "" (not found internally: Name or service not known
[2023-06-15 16:46:18.190 19868/T19886] Setting nameservers back to default:
[2023-06-15 16:46:18.190 19868/T19886]  EXT 0: fe80::1:53 (IPv6)
[2023-06-15 16:46:18.194 19868/T19886]  ---> "" (not found externally: Name or service not known)
[2023-06-15 16:46:18.199 19868/T19886]  ---> not found
[2023-06-15 16:46:18.200 19868/T19886] Client 192.168.2.245 -> "" is new

even when

works ...

The obvious difference here is the address of the nameserver being asked. Just for completeness, could you also try

dig -x 192.168.2.245 @fe80::1

on your Pi-hole?

27

Today something strange happened.

I was going through the query log, to see if something was blocked that caused the issue that I was seeing with spotify.
I saw IPs as usual.

Though as I could not spot a related blocked host, I disabled blocking for 5 minutes using the WEB UI with periods of blocking in between from up-to 5 minutes as well, I disabled blocking 3 times.

Then suddenly I realized that there were no longer IPs listed, but the DHCP device names.
At first not all (Funny enough, the test IP 245 stayed) though then also that one was showing the hostname.

All are also using the ip domain prefix.

I have disabled the blocking earlier also, though back then it did not change a thing.

The only thing I also changed 36 hours ago (though did not have effect until now, but might be related) was to enable IPv6 in the DHCP settings. The strange thing is that the DHCP lease is set to 24 hours, and most devices renewed their DHCP lease this morning the second time already after I changed this in the settings.

I hope this helps you to debug the issue further. If there is anything you want me to try on my device, please tell me. Happy to run some more tests if it helps you debug this.

Here are the results of both dig commands.

 dig -x 192.168.2.245 @192.168.2.2

; <<>> DiG 9.16.37-Raspbian <<>> -x 192.168.2.245 @192.168.2.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60334
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;245.2.168.192.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
245.2.168.192.in-addr.arpa. 0   IN      PTR     dennis-laptop.ip.

;; Query time: 39 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Sat Jun 17 09:43:16 CEST 2023
;; MSG SIZE  rcvd: 85

and

dig -x 192.168.2.245 @fe80::1

; <<>> DiG 9.16.37-Raspbian <<>> -x 192.168.2.245 @fe80::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9977
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;245.2.168.192.in-addr.arpa.    IN      PTR

;; Query time: 9 msec
;; SERVER: fe80::1%2#53(fe80::1)
;; WHEN: Sat Jun 17 09:43:37 CEST 2023
;; MSG SIZE  rcvd: 55

Edit
I looked through the long term data, and the query log seems to be containing the correct hostnames since the new lease on yesterday already (first new lease after enabling IPv6). That does not explain why I did see IPs this morning...

28

Thanks for you report. I reviewed the related code yesterday again but forgot to come back here and reply to you. What I found is that there is an issue with FTL not being able to resolve hostnames when no IPv4 name servers were defined. I think this matches your observation that changing IPv6-related settings improved the situation. It furthermore supports what we have seen above:

which shows that Pi-hole did not actually try to use itself (fe80::1 is the router). And, as expected, your second dig you've just shown above confirms that the router does not know a hostname for this address.

This is an interesting edge case. The machine running your was not configured with IPv6 upstream connectivity, however, that does not stop it from using link-local (fe80:...) IPv6 communication. The sole and only configured DNS server was an IPv6 server at fe80::1 (your router on the link). Due to an incorrect assumption (namely that there will always be IPv4 DNS servers configured), FTL failed to self-assign itself into the name resolution chain and, hence, you did not get the host name. Whatever your change did, apparently, FTL is now able to self-assign and was able to refresh the hostnames.

I added this now to the currently under development v6 code so we have this covered in the future:

https://github.com/pi-hole/FTL/commit/3dcbaf7d9fce357312e8ccd01344a30d169e274b

1 Like
31

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