IPv6 hosts are not resolved to hostnames in Query Log #2124

schuettecarsten · 2024-11-29T18:36:06Z

I can see several entries like this in Query Log:

The IPv6 host fd2b:43d7:e9a:b2:c022:bd26:228f:3e04 is known in network table:

So I would expect that the hostname is shown in query log, not the IPv6 address. I can see some more addresses that should be known in network table, but are not resolved. 99% are resolved, but 1% not.

Docker Tag nightly
Core vDev (development, 03932e8c)
FTL vDev (development, 8478079)
Web interface vDev (development, 96f9ee6a)

The text was updated successfully, but these errors were encountered:

DL6ER · 2024-11-29T20:11:46Z

Does a

dig -x fd2b:43d7:e9a:b2:c022:bd26:228f:3e04

return a host name for that IP?

schuettecarsten · 2024-11-29T20:23:25Z

In the docker container, it does not.
On the docker host, it does.

schuettecarsten · 2024-11-29T20:30:03Z

Ah okay. It looks like reverse DNS lookups are forwarded to the system resolver instead of upstream or Conditional Forwarding rules. I have a conditional forwarding rule true,192.168.0.0/16,192.168.11.1, but reverse lookups for 192.168.0.0/16 addresses are not sent to 192.168.11.1 but to the underlying system resolver. Also, conditional forwarding for IPv6 is not possible.

Mapping fd2b:43d7:e9a:b2:c022:bd26:228f:3e04 to the host name and to the IPv4 address is only available in network table.

DL6ER · 2024-11-30T10:03:16Z

It looks like reverse DNS lookups are forwarded to the system resolver instead of upstream or Conditional Forwarding rules.

FTL always forwards "to itself" regardless of the system resolver settings. Please try again with

dig -x fd2b:43d7:e9a:b2:c022:bd26:228f:3e04 @127.0.0.1

schuettecarsten · 2024-11-30T20:40:26Z

It does not resolve this address.
But it also does not forward this request to upstream or conditional forwarding (router).

DL6ER · 2024-11-30T20:58:33Z

So what does it do instead? Could you quote the corresponding lines from /var/log/pihole/pihole.log for us?

schuettecarsten · 2024-11-30T21:02:29Z

cf3abb9a01e7:/# dig -x fd2b:43d7:e9a:b2:c022:bd26:228f:3e04 @127.0.0.1

; <<>> DiG 9.18.31 <<>> -x fd2b:43d7:e9a:b2:c022:bd26:228f:3e04 @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52117
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;4.0.e.3.f.8.2.2.6.2.d.b.2.2.0.c.2.b.0.0.a.9.e.0.7.d.3.4.b.2.d.f.ip6.arpa. IN PTR

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Nov 30 22:01:58 CET 2024
;; MSG SIZE  rcvd: 101

Log shows nothing special about this request.

schuettecarsten · 2024-11-30T21:04:37Z

The docker container has IP address 192.168.11.2, the upstream server 192.168.11.3.
If I try to reverse-lookup this IP, I run into timeouts:

cf3abb9a01e7:/# dig -x 192.168.11.3 @127.0.0.1
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out

DL6ER · 2024-11-30T21:06:59Z

Log shows nothing special about this request.

Can you be more precise on this? We somehow need to identify why the conditional forwarding rules are not followed here.

If I try to reverse-lookup this IP, I run into timeouts

Also here, the logs would be useful. It could be that FTL itself runs into timeouts on the conditional forwarding target and then never replies back to your dig. Or the query never even reaches FTL, or ...

schuettecarsten · 2024-11-30T21:12:50Z

Log shows nothing new when I do these queries:

2024-11-30 17:00:02.736 CET [50/T114] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-11-30 17:00:02.736 CET [50/T114] INFO: Tried to resolve PTR "3.11.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-11-30 18:00:02.816 CET [50/T114] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-11-30 18:00:02.816 CET [50/T114] INFO: Tried to resolve PTR "3.11.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-11-30 19:00:02.736 CET [50/T114] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-11-30 19:00:02.737 CET [50/T114] INFO: Tried to resolve PTR "3.11.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-11-30 20:00:02.826 CET [50/T114] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-11-30 20:00:02.826 CET [50/T114] INFO: Tried to resolve PTR "3.11.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-11-30 21:00:02.816 CET [50/T114] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-11-30 21:00:02.816 CET [50/T114] INFO: Tried to resolve PTR "3.11.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-11-30 22:00:02.906 CET [50/T114] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-11-30 22:00:02.906 CET [50/T114] INFO: Tried to resolve PTR "3.11.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)

DL6ER · 2024-12-01T05:54:34Z

Okay, so it seems inside your container FTL is not listening on port 53 although it should. Did you change

dns.port

in /etc/pihole/pihole.toml ?

Please run ss -tulpen to check if FTL is listening as it should, e.g., I see

Netid   State    Recv-Q   Send-Q     Local Address:Port     Peer Address:Port   Process                                                                         
udp     UNCONN   0        0                0.0.0.0:53            0.0.0.0:*       uid:100 ino:600734 sk:1 cgroup:unreachable:5bf2 <->                            
udp     UNCONN   0        0                0.0.0.0:123           0.0.0.0:*       uid:100 ino:597696 sk:2 cgroup:unreachable:5bf2 <->                            
udp     UNCONN   0        0                   [::]:53               [::]:*       uid:100 ino:600736 sk:3 cgroup:unreachable:5bf2 v6only:1 <->                   
udp     UNCONN   0        0                   [::]:123              [::]:*       uid:100 ino:598602 sk:4 cgroup:unreachable:5bf2 v6only:1 <->                   
tcp     LISTEN   0        200              0.0.0.0:80            0.0.0.0:*       uid:100 ino:600743 sk:5 cgroup:unreachable:5bf2 <->                            
tcp     LISTEN   0        32               0.0.0.0:53            0.0.0.0:*       uid:100 ino:600735 sk:6 cgroup:unreachable:5bf2 <->                            
tcp     LISTEN   0        200              0.0.0.0:443           0.0.0.0:*       uid:100 ino:600745 sk:7 cgroup:unreachable:5bf2 <->                            
tcp     LISTEN   0        200                 [::]:80               [::]:*       uid:100 ino:600744 sk:8 cgroup:unreachable:5bf2 v6only:1 <->                   
tcp     LISTEN   0        32                  [::]:53               [::]:*       uid:100 ino:600737 sk:9 cgroup:unreachable:5bf2 v6only:1 <->                   
tcp     LISTEN   0        200                 [::]:443              [::]:*       uid:100 ino:600746 sk:a cgroup:unreachable:5bf2 v6only:1 <->

schuettecarsten · 2024-12-01T12:30:53Z

cf3abb9a01e7:/# ss -tulpen
Netid          State           Recv-Q          Send-Q                   Local Address:Port                      Peer Address:Port          Process
udp            UNCONN          0               0                           127.0.0.11:40559                          0.0.0.0:*
udp            UNCONN          0               0                              0.0.0.0:53                             0.0.0.0:*
udp            UNCONN          0               0                                    *:53                                   *:*
tcp            LISTEN          0               0                              0.0.0.0:443                            0.0.0.0:*              uid:100 ino:461872 sk:9ae4c6b6
tcp            LISTEN          0               0                              0.0.0.0:53                             0.0.0.0:*              uid:100 ino:461859 sk:c25a6448
tcp            LISTEN          0               0                              0.0.0.0:80                             0.0.0.0:*              uid:100 ino:461870 sk:c86e8e50
tcp            LISTEN          0               0                           127.0.0.11:44399                          0.0.0.0:*              ino:458684 sk:5872d0f1
tcp            LISTEN          0               0                                    *:443                                  *:*              uid:100 ino:461873 sk:3725c796
tcp            LISTEN          0               0                                    *:53                                   *:*              uid:100 ino:461861 sk:44afd041
tcp            LISTEN          0               0                                    *:80                                   *:*              uid:100 ino:461871 sk:e8c1d5e6

I did not change dns.port

  ] ### CHANGED, default = []
  piholePTR = "NONE" ### CHANGED, default = "PI.HOLE"
  blockTTL = 15 ### CHANGED, default = 2
  domainNeeded = true ### CHANGED, default = false
  domain = "" ### CHANGED, default = "lan"
  bogusPriv = false ### CHANGED, default = true
  interface = "eth0" ### CHANGED, default = ""
  queryLogging = false ### CHANGED, default = true
  ] ### CHANGED, default = []
    mode = "NODATA" ### CHANGED, default = "NULL"
      IPv4 = "192.168.11.2" ### CHANGED, default = ""
      IPv6 = "fd2b:43d7:e9a:b::2" ### CHANGED, default = ""
    interval = 10 ### CHANGED, default = 60
    active = false ### CHANGED, default = true
    active = false ### CHANGED, default = true
    active = false ### CHANGED, default = true
  port = "80r,[::]:80r,443s,[::]:443s" ### CHANGED, default = "80,[::]:80,443s,[::]:443s"
    pwhash = <removed>
  macvendor = "/macvendor.db" ### CHANGED, default = "/etc/pihole/macvendor.db"

Some of these settings are set by the docker container. I mainly turned off ntp server.

DL6ER · 2024-12-02T17:46:37Z

This is odd. So inside the container FTL is listening on port 53, as expected, yet dig returns a timeout and there is nothing in the log. Probably a stupid question but could you check once again you called dig ... @127.0.0.1 in the right container and did not, e.g., accidentally spawn a new one that somehow failed to resolve? Does a dig [email protected] work in the very same container?

schuettecarsten · 2024-12-03T08:20:31Z

root@GatewayDummi:~# docker ps
CONTAINER ID   IMAGE                                                          COMMAND                  CREATED        STATUS                  PORTS                                       NAMES
b4d6222d82a1   pihole/pihole:nightly                                          "start.sh"               21 hours ago   Up 19 hours (healthy)                                               pihole
11576cfc3473   adguard/dnsproxy:latest                                        "/opt/dnsproxy/dnspr…"   3 days ago     Up 19 hours                                                         dnsproxy
root@GatewayDummi:~#

root@GatewayDummi:~# docker exec -ti b4d6222d82a1 bash

b4d6222d82a1:/# ps -fax
  PID TTY      STAT   TIME COMMAND
23802 pts/0    Ss     0:00 bash
23810 pts/0    R+     0:00  \_ ps -fax
    1 ?        Ss     0:00 /bin/bash /usr/bin/start.sh
   19 ?        Ss     0:00 /usr/sbin/crond
  152 ?        S      0:00 tail --follow=name -n +110 /var/log/pihole/FTL.log
   47 ?        S      0:00 /bin/bash -c /usr/bin/pihole-FTL no-daemon >/dev/null
   49 ?        S<l   27:43  \_ /usr/bin/pihole-FTL no-daemon

b4d6222d82a1:/# ss -tulpen
Netid              State               Recv-Q              Send-Q                             Local Address:Port                              Peer Address:Port              Process
udp                UNCONN              0                   0                                        0.0.0.0:53                                     0.0.0.0:*
udp                UNCONN              0                   0                                     127.0.0.11:59462                                  0.0.0.0:*
udp                UNCONN              0                   0                                              *:53                                           *:*
tcp                LISTEN              0                   0                                        0.0.0.0:443                                    0.0.0.0:*                  uid:100 ino:19168 sk:d5858c30
tcp                LISTEN              0                   0                                        0.0.0.0:80                                     0.0.0.0:*                  uid:100 ino:19166 sk:61b7f435
tcp                LISTEN              0                   0                                        0.0.0.0:53                                     0.0.0.0:*                  uid:100 ino:16668 sk:1a2b0faf
tcp                LISTEN              0                   0                                     127.0.0.11:42419                                  0.0.0.0:*                  ino:15590 sk:4c6a6907
tcp                LISTEN              0                   0                                              *:443                                          *:*                  uid:100 ino:19169 sk:a5d7cf31
tcp                LISTEN              0                   0                                              *:80                                           *:*                  uid:100 ino:19167 sk:65174548
tcp                LISTEN              0                   0                                              *:53                                           *:*                  uid:100 ino:16670 sk:e1ecc911

Addes blank lines befoe each command after copy/paste here.
So, yes, I am sure this is the pihole container.

b4d6222d82a1:/# dig -x 192.168.11.1 @127.0.0.1

; <<>> DiG 9.18.31 <<>> -x 192.168.11.1 @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62110
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Dec 03 09:14:19 CET 2024
;; MSG SIZE  rcvd: 54

b4d6222d82a1:/# dig -x 192.168.11.3 @127.0.0.1
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out

; <<>> DiG 9.18.31 <<>> -x 192.168.11.3 @127.0.0.1
;; global options: +cmd
;; no servers could be reached

Both hosts are pingable, the IP address of the pihole container is 192.168.11.2:

root@GatewayDummi:~# docker exec -ti b4d6222d82a1 bash
b4d6222d82a1:/# ping 192.168.11.1
PING 192.168.11.1 (192.168.11.1): 56 data bytes
64 bytes from 192.168.11.1: seq=0 ttl=64 time=0.416 ms
^C
--- 192.168.11.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.416/0.416/0.416 ms

b4d6222d82a1:/# ping 192.168.11.3
PING 192.168.11.3 (192.168.11.3): 56 data bytes
64 bytes from 192.168.11.3: seq=0 ttl=64 time=0.268 ms
^C
--- 192.168.11.3 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.268/0.268/0.268 ms

192.168.11.3 is the upstream DNS server running Adguard DNS proxy.

schuettecarsten · 2024-12-03T08:59:38Z

Maybe some details about my setup are helpful:

I use a Raspi 4 as OpenWRT router. The router handles DHCP (v4/v6) and incoming DNS requests, it forwards requests to a pihole server (192.168.11.2) running as docker container on the router. I have a separate macvlan network (192.168.11.0/24) for this. Pihole should handle blocklists and forward upstream requests to a second container running Adguard DNS proxy (192.168.11.3). All this works fine so far.

But if pihole needs to reverse-lookup local IP addresses, it should send these requests back to the OpenWRT dnsmasq at 192.168.11.1. This works for IPv4 using conditional forwarding and a rule like true,192.168.0.0/16,192.168.11.1 but fails for IPv6.

schuettecarsten · 2024-12-03T09:02:26Z

Huh, I just changed the conditional forwarding rule to true, 192.168.0.0/16,192.168.11.1,internal, so add a domain name, and now the reverse lookup for 192.168.11.3 works. Changing it back without the internal domain name brings the timeouts back. But the issue that reverse lookups on 127.0.0.1 fail persists.

From logs during pihole startup:

2024-12-04 08:03:29.312 CET [49M] INFO: Blocking status is enabled
2024-12-04 08:03:29.455 CET [49/T86] INFO: Compiled 5 allow and 3 deny regex for 20 clients in 48.0 msec
2024-12-04 08:03:33.364 CET [49/T88] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-12-04 08:03:33.365 CET [49/T88] INFO: Tried to resolve PTR "1.11.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-12-04 08:03:35.444 CET [49/T88] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-12-04 08:03:35.445 CET [49/T88] INFO: Tried to resolve PTR "169.179.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-12-04 08:03:37.524 CET [49/T88] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-12-04 08:03:37.525 CET [49/T88] INFO: Tried to resolve PTR "177.179.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-12-04 08:03:39.604 CET [49/T88] ERROR: Cannot receive UDP DNS reply: Timeout - no response from upstream DNS server
2024-12-04 08:03:39.605 CET [49/T88] INFO: Tried to resolve PTR "1.11.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)

DL6ER · 2024-12-03T17:42:25Z

The only change this extra domain will introduce into your local (automatically generated) dnsmasq config is adding an additional line like

server=/internal/192.168.11.1

i.e., specifying that lookups for TLD internal are to be sent to 192.168.11.1. It should have no other effect...

Could you please create a diff of the file /etc/pihole/dnsmasq.conf once when it works and once without the domain (when it doesn't work)?

schuettecarsten · 2024-12-04T09:20:13Z

I got the root cause for the DNS timeouts - it was a forwarding issue, Pihole sends the request back to the router, the router to pihole and so on. Timeouts occured on rate-limit, the whole thing crashed if I disable rate limiting. The problem is that I cannot tell pihole to send "internal" PTR requests back to the router without using conditional forwarding.

But the original issue is still there:
I would expect pihole to "match" unknown addresses with the network table.

DL6ER · 2024-12-05T18:28:21Z

Why is your router using your Pi-hole for DNS in the first place? What is it this device is "looking up"? Does it really need DNS filtering or is it more like you want to be able to use the Pi-hole to monitor all DNS activity in your network - including the router's one?
The issue here is that DNS is stateless and we cannot easily prevent such a loop from happening.

I still don't know why you haven't seen anything of this in your logs...

But the original issue is still there:
I would expect pihole to "match" unknown addresses with the network table.

Yes, and this should actually be done. Please enable debug.resolver and restart FTL. Then, check your /var/log/pihole/FTL.log file for the address not resolving to a name. FTL should document the places it is looking in, including the network table. It should also document why it fails to do this in your case.

schuettecarsten · 2024-12-05T19:02:20Z

Why is your router using your Pi-hole for DNS in the first place? What is it this device is "looking up"? Does it really need DNS filtering or is it more like you want to be able to use the Pi-hole to monitor all DNS activity in your network - including the router's one?

As written, there was a configuration bug on my side.

Yes, and this should actually be done. Please enable debug.resolver and restart FTL. Then, check your /var/log/pihole/FTL.log file for the address not resolving to a name. FTL should document the places it is looking in, including the network table. It should also document why it fails to do this in your case.

Logfile:

2024-12-05 19:57:18.892 CET [1309/F47] DEBUG_ANY: Reopening Gravity database for this fork
2024-12-05 19:57:18.900 CET [1310/F47] DEBUG_ANY: Reopening Gravity database for this fork
2024-12-05 19:57:18.904 CET [1309/F47] DEBUG_RESOLVER: Trying to obtain host name of "fd2b:43d7:e9a:b2:b1a5:c79a:f5b:ded6" from network_addresses table
2024-12-05 19:57:18.906 CET [1309/F47] DEBUG_RESOLVER: Check for a host name associated with IP address fd2b:43d7:e9a:b2:b1a5:c79a:f5b:ded6
2024-12-05 19:57:18.906 CET [1309/F47] DEBUG_RESOLVER:  ---> not found
2024-12-05 19:57:18.906 CET [1309/F47] DEBUG_RESOLVER: Checking for a host name associated with the same device (but another IP address)
2024-12-05 19:57:18.907 CET [1309/F47] DEBUG_RESOLVER: Found database host name (same device) fd2b:43d7:e9a:b2:b1a5:c79a:f5b:ded6 -> laptopc3253.lan
2024-12-05 19:57:18.915 CET [1309/F47] DEBUG_ANY: Closing gravity database
2024-12-05 19:57:18.916 CET [1310/F47] DEBUG_ANY: Closing gravity database

Query log:

Network table:

DL6ER · 2024-12-05T19:19:49Z

I am missing a few log lines here, I guess what you have been quoting is what is printed when you open the clients page. Can you check for more resolver debug lines with this IP address?

We are specifically looking for something like

DEBUG_RESOLVER: Client fd2b:43d7:e9a:b2:b1a5:c79a:f5b:ded6 -> "..." is new

schuettecarsten · 2024-12-05T21:40:27Z

I cannot find a "is new" message in the latest logs but will flush and restart pihole tomorrow.
Here is what I found so far:

Each hour:

2024-12-05 21:00:06.918 CET [47/T112] DEBUG_RESOLVER: Skipping client fd2b:43d7:e9a:b2:b1a5:c79a:f5b:ded6 -> "" because it should not be refreshed: Only refreshing IPv4 names
2024-12-05 22:00:06.727 CET [47/T112] DEBUG_RESOLVER: Skipping client fd2b:43d7:e9a:b2:b1a5:c79a:f5b:ded6 -> "" because it should not be refreshed: Only refreshing IPv4 names

And sometimes:

2024-12-05 20:20:03.313 CET [47/T112] DEBUG_RESOLVER: Skipping client fd2b:43d7:e9a:b2:b1a5:c79a:f5b:ded6 -> "" because it is not new
2024-12-05 20:20:06.363 CET [47/T112] DEBUG_RESOLVER: Skipping client fd2b:43d7:e9a:b2:b1a5:c79a:f5b:ded6 -> "" because it is not new

schuettecarsten · 2024-12-06T08:32:09Z

I need to use a different test device today, so here are the details:

Network table:

Pihole logs:

2024-12-06 09:22:41.062 CET [49/T284] DEBUG_RESOLVER: Resolving PTR "169.179.168.192.in-addr.arpa" on 127.0.0.1#53 (UDP)
2024-12-06 09:22:41.075 CET [49/T284] DEBUG_RESOLVER: DNS query for PTR "169.179.168.192.in-addr.arpa" returned status NoError (0)
2024-12-06 09:22:41.075 CET [49/T284] DEBUG_RESOLVER: Answer 0 is PTR "169.179.168.192.in-addr.arpa" => "laptopc3253.lan"
2024-12-06 09:22:41.075 CET [49/T284] DEBUG_RESOLVER: Client 192.168.179.169 -> "laptopc3253.lan" is new

2024-12-06 09:22:41.077 CET [49/T284] DEBUG_RESOLVER: Trying to resolve fd2b:43d7:e9a:b2:bcd9:887e:4e0b:edd
2024-12-06 09:22:41.077 CET [49/T284] DEBUG_RESOLVER: Resolving PTR "d.d.e.0.b.0.e.4.e.7.8.8.9.d.c.b.2.b.0.0.a.9.e.0.7.d.3.4.b.2.d.f.ip6.arpa" on 127.0.0.1#53 (UDP)
2024-12-06 09:22:41.079 CET [49/T284] DEBUG_RESOLVER: DNS query for PTR "d.d.e.0.b.0.e.4.e.7.8.8.9.d.c.b.2.b.0.0.a.9.e.0.7.d.3.4.b.2.d.f.ip6.arpa" returned status NXDomain (Non-Existent Domain) (3)
2024-12-06 09:22:41.079 CET [49/T284] DEBUG_RESOLVER: Trying to obtain host name of "fd2b:43d7:e9a:b2:bcd9:887e:4e0b:edd" from network_addresses table
2024-12-06 09:22:41.080 CET [49/T284] DEBUG_RESOLVER: Check for a host name associated with IP address fd2b:43d7:e9a:b2:bcd9:887e:4e0b:edd
2024-12-06 09:22:41.081 CET [49/T284] DEBUG_RESOLVER:  ---> not found
2024-12-06 09:22:41.081 CET [49/T284] DEBUG_RESOLVER: Checking for a host name associated with the same device (but another IP address)
2024-12-06 09:22:41.081 CET [49/T284] DEBUG_RESOLVER:  ---> not found
2024-12-06 09:22:41.081 CET [49/T284] DEBUG_RESOLVER: Client fd2b:43d7:e9a:b2:bcd9:887e:4e0b:edd -> "" is new

Query log shows host name for IPv4 requests:

Query log shows IPv6 address for IPv6 addresses and does to "resolve" it using network table:

DL6ER · 2024-12-06T17:09:31Z

This is some form of a chicken-and-egg problem here. My working hypothesis is that your client gets the IP address "freshly" and then issues queries. Pi-hole sees the new host name, tries to resolve the host name and fails because it is not yet known in the network table. Then, asynchronously at some later point in time, FTL has a chance to determine the MAC address associated to this IPv6 address and can correlate the addresses in the network table. It is here forth known (so also when you looked), but it wasn't known at the single point in time when the query was new.

Apple was one of the first companies whose devices randomized their IPv6 address frequently. In the very early days of this feature, it was really aggressive on this potentially creating hundreds of "new" devices per hour (!) even in a small home-scale network. Hence, we changed the default for trying to resolve IPv6 addresses to only once at the very beginning.

You could try changing the refresh setting from resolver.refreshNames = "IPV4_ONLY" to resolver.refreshNames = "ALL" and check if this resolves the issue. I know this is not the ideal situation but maybe it doesn't even matter in you local network. If this works, we can think about postponing the initial refreshing of the IPv6 host name to a point after we know it has been likely that the network table is able to have already correlated the address and, hence, can provide the missing IPv6 host name. However, host name refreshing may take up to an additional hour.

You could also try the new branch tweak/delay_v6_names which tries to overcome this issue more elegantly by simply delaying IPv6 name resolution only a bit:

sudo pihole checkout ftl tweak/delay_v6_names

Int he docker world, you'd need to bake your own image but it is relatively easy to do so.

schuettecarsten · 2024-12-07T13:05:00Z

I will try.

But I think that reverse lookups for IPv6 addresses are not the main issue here. Network tables shows that pihole somewhere knows that - in my case - 192.168.179.169 and fd2b:43d7:e9a:b2:bcd9:887e:4e0b:edd are addresses from the same device. So what I would expect is that query log shows the device host name for the IPv4 address (it does) and the IPv6 address (it does not).

On my network, OpenWRT/dnsmasq does not resolve the IPv6 addresses to the hostname, I do not exactly know, why. Maybe because OpenWRT uses dnsmasq for DHCPv4 and odhcpd for DHCPv6, but dnsmasq does not know about the IPv6 leases. Also, SLAAC breaks dns resolution. So using the network table to merge IPv4 and IPv6 together is a great approach.

moya2162 · 2024-12-08T06:33:09Z

@schuettecarsten

Are you using EDNS0 to use MAC address to assign hostnames to ipv6 addresses? In my case ive noticed that when i get a new ipv6 address I have to wait for the hourly PTR cycle which will then check against my piholes network device history and match MAC addresses and then assign the hostname to the address which will then be reflected in the query log.

Also please take a look at my previous issue here and see if you think its similar to what you are experiencing? (#1978)

schuettecarsten · 2024-12-08T13:36:27Z

@moya2162

Are you using EDNS0 to use MAC address to assign hostnames to ipv6 addresses?

Yes, that's the plan.

moya2162 · 2024-12-08T23:13:38Z

Do you have EDNS0 enabled in OpenWRT?

schuettecarsten · 2024-12-09T07:22:30Z

@moya2162

Do you have EDNS0 enabled in OpenWRT?

Sure and that works fine. The options have been introduced to OpenWRT some month ago and are also available in LuCI (openwrt/openwrt#15965 and openwrt/luci#7198). I use pihole as ustream DNS server. That's also to make sure that pihole is involved when clients use SLAAC or the default gateway as DNS server.

moya2162 · 2024-12-09T08:29:04Z

Sounds like your setup should work fine then. I have same setup with OpenWRT and Pihole using EDNS0 and my ipv6 clients resolve with SLAAC. The only issue i had was how fast the ipv6 hostnames resolve in pihole, which is discussed in the issue i linked previously.

schuettecarsten · 2024-12-13T08:45:13Z

Well, it still does not work as expected on my setup. IPv6 addresses are not resolved in pihole.

For my computer, I can see one "Network table" entry, but I can see three types of entries in statistics and query log. One for the host name, one for the IPv4 address and one for the IPv6 address. Regardless if I use SLAAC or DHCPv6 or whatever. IPv6 addresses are not mapped to the network table. This makes logs, statistics and maybe blocking somewhat useless and unreliable.

DL6ER · 2024-12-13T20:14:45Z

Did you try with the custom binary from the special branch I prepared? How do the related DEBUG_RESOLVER lines look like now?

DL6ER added the Pi-hole v6.0 label Nov 29, 2024

DL6ER mentioned this issue Dec 6, 2024

Delay IPv6 client name lookups #2130

Draft

5 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

IPv6 hosts are not resolved to hostnames in Query Log #2124

IPv6 hosts are not resolved to hostnames in Query Log #2124

schuettecarsten commented Nov 29, 2024 •

edited

Loading

DL6ER commented Nov 29, 2024 •

edited

Loading

schuettecarsten commented Nov 29, 2024

schuettecarsten commented Nov 29, 2024 •

edited

Loading

DL6ER commented Nov 30, 2024

schuettecarsten commented Nov 30, 2024

DL6ER commented Nov 30, 2024

schuettecarsten commented Nov 30, 2024

schuettecarsten commented Nov 30, 2024

DL6ER commented Nov 30, 2024

schuettecarsten commented Nov 30, 2024

DL6ER commented Dec 1, 2024

schuettecarsten commented Dec 1, 2024

DL6ER commented Dec 2, 2024

schuettecarsten commented Dec 3, 2024

schuettecarsten commented Dec 3, 2024

schuettecarsten commented Dec 3, 2024 •

edited

Loading

DL6ER commented Dec 3, 2024

schuettecarsten commented Dec 4, 2024 •

edited

Loading

DL6ER commented Dec 5, 2024

schuettecarsten commented Dec 5, 2024

DL6ER commented Dec 5, 2024 •

edited

Loading

schuettecarsten commented Dec 5, 2024

schuettecarsten commented Dec 6, 2024 •

edited

Loading

DL6ER commented Dec 6, 2024

schuettecarsten commented Dec 7, 2024

moya2162 commented Dec 8, 2024

schuettecarsten commented Dec 8, 2024

moya2162 commented Dec 8, 2024

schuettecarsten commented Dec 9, 2024

moya2162 commented Dec 9, 2024

schuettecarsten commented Dec 13, 2024

DL6ER commented Dec 13, 2024

IPv6 hosts are not resolved to hostnames in Query Log #2124

IPv6 hosts are not resolved to hostnames in Query Log #2124

Comments

schuettecarsten commented Nov 29, 2024 • edited Loading

DL6ER commented Nov 29, 2024 • edited Loading

schuettecarsten commented Nov 29, 2024

schuettecarsten commented Nov 29, 2024 • edited Loading

DL6ER commented Nov 30, 2024

schuettecarsten commented Nov 30, 2024

DL6ER commented Nov 30, 2024

schuettecarsten commented Nov 30, 2024

schuettecarsten commented Nov 30, 2024

DL6ER commented Nov 30, 2024

schuettecarsten commented Nov 30, 2024

DL6ER commented Dec 1, 2024

schuettecarsten commented Dec 1, 2024

DL6ER commented Dec 2, 2024

schuettecarsten commented Dec 3, 2024

schuettecarsten commented Dec 3, 2024

schuettecarsten commented Dec 3, 2024 • edited Loading

DL6ER commented Dec 3, 2024

schuettecarsten commented Dec 4, 2024 • edited Loading

DL6ER commented Dec 5, 2024

schuettecarsten commented Dec 5, 2024

DL6ER commented Dec 5, 2024 • edited Loading

schuettecarsten commented Dec 5, 2024

schuettecarsten commented Dec 6, 2024 • edited Loading

DL6ER commented Dec 6, 2024

schuettecarsten commented Dec 7, 2024

moya2162 commented Dec 8, 2024

schuettecarsten commented Dec 8, 2024

moya2162 commented Dec 8, 2024

schuettecarsten commented Dec 9, 2024

moya2162 commented Dec 9, 2024

schuettecarsten commented Dec 13, 2024

DL6ER commented Dec 13, 2024

schuettecarsten commented Nov 29, 2024 •

edited

Loading

DL6ER commented Nov 29, 2024 •

edited

Loading

schuettecarsten commented Nov 29, 2024 •

edited

Loading

schuettecarsten commented Dec 3, 2024 •

edited

Loading

schuettecarsten commented Dec 4, 2024 •

edited

Loading

DL6ER commented Dec 5, 2024 •

edited

Loading

schuettecarsten commented Dec 6, 2024 •

edited

Loading