Incorrect caching behaviour for certain domain

[bobvandevijver]

Versions

• Pi-hole: 6.1.4
• Web: 6.2.1
• FTL: 6.2.3

Platform

• OS and version: Debian 12 Bookworm

• Platform: VM

Expected behavior

gitlab.yyy.zzz needs to resolve to proxy01.xxx.yyy.zzz, which resolves to an IPv4/6-address.

Actual behavior / bug

For some reason, the CNAME record in the FTL cache becomes yyy.zzz instead of proxy01.xxx.yyy.zzz. See the line numbered log:

01 - Jul 31 18:21:43 dnsmasq[535872]: query[A] gitlab.yyy.zzz from 192.168.1.160
02 - Jul 31 18:21:43 dnsmasq[535873]: query[AAAA] gitlab.yyy.zzz from 192.168.1.160
03 - Jul 31 18:21:43 dnsmasq[535872]: forwarded gitlab.yyy.zzz to x:y:z::1112
04 - Jul 31 18:21:43 dnsmasq[535872]: reply gitlab.yyy.zzz is <CNAME>
05 - Jul 31 18:21:43 dnsmasq[535872]: reply proxy01.xxx.yyy.zzz is x.y.25.213
06 - Jul 31 18:21:43 dnsmasq[535873]: forwarded gitlab.yyy.zzz to x:y:z::1112
07 - Jul 31 18:21:43 dnsmasq[535873]: reply gitlab.yyy.zzz is <CNAME>
08 - Jul 31 18:21:43 dnsmasq[535873]: reply proxy01.xxx.yyy.zzz is v:x:y:z:c0:1:0:100
09 - Jul 31 18:21:43 dnsmasq[535874]: query[A] gitlab.yyy.zzz from 192.168.1.160
10 - Jul 31 18:21:43 dnsmasq[535874]: cached gitlab.yyy.zzz is <CNAME>
11 - Jul 31 18:21:43 dnsmasq[535874]: cached proxy01.xxx.yyy.zzz is x.y.25.213
12 - Jul 31 18:21:43 dnsmasq[535876]: query[AAAA] gitlab.yyy.zzz from 192.168.1.160
13 - Jul 31 18:21:43 dnsmasq[535876]: cached gitlab.yyy.zzz is <CNAME>
14 - Jul 31 18:21:43 dnsmasq[535876]: cached proxy01.xxx.yyy.zzz is v:x:y:z:c0:1:0:100
15 - Jul 31 18:21:43 dnsmasq[535877]: query[HTTPS] gitlab.yyy.zzz from 192.168.1.160
16 - Jul 31 18:21:43 dnsmasq[535877]: cached gitlab.yyy.zzz is <CNAME>
17 - Jul 31 18:21:43 dnsmasq[535877]: forwarded gitlab.yyy.zzz to x:y:z::1112
18 - Jul 31 18:21:43 dnsmasq[535877]: reply gitlab.yyy.zzz is <CNAME>
19 - Jul 31 18:21:43 dnsmasq[535877]: reply proxy01.xxx.yyy.zzz is NODATA
20 - Jul 31 18:21:47 dnsmasq[535887]: query[A] gitlab.yyy.zzz from 192.168.1.160
21 - Jul 31 18:21:47 dnsmasq[535887]: cached gitlab.yyy.zzz is <CNAME>
22 - Jul 31 18:21:47 dnsmasq[535887]: cached yyy.zzz is x.y.232.182
23 - Jul 31 18:21:47 dnsmasq[535888]: query[AAAA] gitlab.yyy.zzz from 192.168.1.160
24 - Jul 31 18:21:47 dnsmasq[535888]: cached gitlab.yyy.zzz is <CNAME>
25 - Jul 31 18:21:47 dnsmasq[535888]: cached yyy.zzz is v:x:y:z:dcad:beff:feef:40
26 - Jul 31 18:21:47 dnsmasq[535889]: query[HTTPS] gitlab.yyy.zzz from 192.168.1.160
27 - Jul 31 18:21:47 dnsmasq[535889]: cached gitlab.yyy.zzz is <CNAME>
28 - Jul 31 18:21:47 dnsmasq[535889]: cached yyy.zzz is NODATA
29 - Jul 31 18:21:51 dnsmasq[535899]: query[AAAA] gitlab.yyy.zzz from 192.168.1.160
30 - Jul 31 18:21:51 dnsmasq[535899]: cached gitlab.yyy.zzz is <CNAME>
31 - Jul 31 18:21:51 dnsmasq[535899]: cached yyy.zzz is v:x:y:z:dcad:beff:feef:40
32 - Jul 31 18:21:51 dnsmasq[535900]: query[HTTPS] gitlab.yyy.zzz from 192.168.1.160
33 - Jul 31 18:21:51 dnsmasq[535900]: cached gitlab.yyy.zzz is <CNAME>
34 - Jul 31 18:21:51 dnsmasq[535900]: cached yyy.zzz is NODATA
35 - Jul 31 18:21:51 dnsmasq[535903]: query[A] gitlab.yyy.zzz from 192.168.1.160
36 - Jul 31 18:21:51 dnsmasq[535903]: cached gitlab.yyy.zzz is <CNAME>
37 - Jul 31 18:21:51 dnsmasq[535903]: cached yyy.zzz is x.y.232.182
38 - Jul 31 18:21:55 dnsmasq[535905]: query[AAAA] gitlab.yyy.zzz from 192.168.1.160
39 - Jul 31 18:21:55 dnsmasq[535905]: cached gitlab.yyy.zzz is <CNAME>
40 - Jul 31 18:21:55 dnsmasq[535905]: cached yyy.zzz is v:x:y:z:dcad:beff:feef:40
41 - Jul 31 18:21:55 dnsmasq[535906]: query[A] gitlab.yyy.zzz from 192.168.1.160
42 - Jul 31 18:21:55 dnsmasq[535906]: cached gitlab.yyy.zzz is <CNAME>
43 - Jul 31 18:21:55 dnsmasq[535906]: cached yyy.zzz is x.y.232.182

1. Lines 1 - 14: look great, normal A/AAAA resolving
2. Line 15-16: looks okay for a HTTPS action
3. Line 17: Wait, why is a cached CNAME forwarded to the upstream resolver? Maybe because of the HTTPS query?
4. Line 18-19: The response looks good
5. Line 20-21: New query, looks cached
6. Line 22: Wait, looks like it is now using the wrong CNAME
7. Line 20-43: Cache is incorrect

Steps to reproduce

Not sure how, it only happens sporadically.

Debug Token

• URL: https://tricorder.pi-hole.net/aWmai8ui/

Additional context

This might have been an issue for quite some time, but as gitlab.yyy.zzz recently changed (two weeks back) it now comes forward. In the past, it was a CNAME for yyy.zzz, which is where it is falling back to.

[DL6ER]

Note that dnsmasq may simply be handling things out-of-order here so the assessment that lines are the immediate effect of the proceeding line may simply not be true. This is so that we can still process other queries while we are waiting for upstream replies.

Please enable

sudo pihole-FTL --config misc.extraLogging true

to have dnsmasq log query IDs, allowing us to see what really happens here. Please note that all this is not saying there is no issue, but we should first try to be as sure as possible so we can be sure we are looking at fixing the right things.

[bobvandevijver]

@DL6ER Here you go, exactly the same behaviour with the extra logging enabled. Looks the same to me, after the HTTPS query with NODATA (64525) the cache looks broken.

Also generated a new log: https://tricorder.pi-hole.net/ldgcWy6K/

Aug  3 12:50:16 dnsmasq[898696]: TCP 5801 192.168.1.240/64520 query[AAAA] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:16 dnsmasq[898697]: TCP 5941 192.168.1.240/64521 query[A] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:16 dnsmasq[898696]: TCP 5801 192.168.1.240/64520 forwarded gitlab.yyy.zzz to 1.1.1.2
Aug  3 12:50:16 dnsmasq[898696]: TCP 5801 192.168.1.240/64520 reply gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898696]: TCP 5801 192.168.1.240/64520 reply proxy01.xxx.yyy.zzz is v:x:y:z:c0:1:0:100 (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898697]: TCP 5941 192.168.1.240/64521 forwarded gitlab.yyy.zzz to 1.1.1.2
Aug  3 12:50:16 dnsmasq[898697]: TCP 5941 192.168.1.240/64521 reply gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898697]: TCP 5941 192.168.1.240/64521 reply proxy01.xxx.yyy.zzz is x.y.25.213 (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898698]: TCP 6081 192.168.1.240/64523 query[AAAA] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:16 dnsmasq[898698]: TCP 6081 192.168.1.240/64523 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898698]: TCP 6081 192.168.1.240/64523 cached proxy01.xxx.yyy.zzz is v:x:y:z:c0:1:0:100 (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898699]: TCP 6221 192.168.1.240/64524 query[A] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:16 dnsmasq[898699]: TCP 6221 192.168.1.240/64524 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898699]: TCP 6221 192.168.1.240/64524 cached proxy01.xxx.yyy.zzz is x.y.25.213 (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 query[HTTPS] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 forwarded gitlab.yyy.zzz to 1.1.1.2
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 reply gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 reply proxy01.xxx.yyy.zzz is NODATA (DNSSEC signed)
Aug  3 12:50:19 dnsmasq[898712]: TCP 8041 192.168.1.240/64548 query[AAAA] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:19 dnsmasq[898712]: TCP 8041 192.168.1.240/64548 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:19 dnsmasq[898712]: TCP 8041 192.168.1.240/64548 cached yyy.zzz is v:x:y:z:dcad:beff:feef:40 (DNSSEC signed)
Aug  3 12:50:19 dnsmasq[898713]: TCP 8181 192.168.1.240/64549 query[A] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:19 dnsmasq[898713]: TCP 8181 192.168.1.240/64549 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:19 dnsmasq[898713]: TCP 8181 192.168.1.240/64549 cached yyy.zzz is x.y.232.182 (DNSSEC signed)
Aug  3 12:50:21 dnsmasq[898714]: TCP 8321 192.168.1.240/64551 query[AAAA] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:21 dnsmasq[898714]: TCP 8321 192.168.1.240/64551 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:21 dnsmasq[898714]: TCP 8321 192.168.1.240/64551 cached yyy.zzz is v:x:y:z:dcad:beff:feef:40 (DNSSEC signed)
Aug  3 12:50:21 dnsmasq[898715]: TCP 8461 192.168.1.240/64552 query[A] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:21 dnsmasq[898715]: TCP 8461 192.168.1.240/64552 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:21 dnsmasq[898715]: TCP 8461 192.168.1.240/64552 cached yyy.zzz is x.y.232.182 (DNSSEC signed)
Aug  3 12:50:22 dnsmasq[898717]: TCP 8648 192.168.1.240/64554 query[AAAA] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:22 dnsmasq[898717]: TCP 8648 192.168.1.240/64554 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:22 dnsmasq[898717]: TCP 8648 192.168.1.240/64554 cached yyy.zzz is v:x:y:z:dcad:beff:feef:40 (DNSSEC signed)
Aug  3 12:50:22 dnsmasq[898718]: TCP 8788 192.168.1.240/64555 query[A] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:22 dnsmasq[898718]: TCP 8788 192.168.1.240/64555 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:22 dnsmasq[898718]: TCP 8788 192.168.1.240/64555 cached yyy.zzz is x.y.232.182 (DNSSEC signed)

[DL6ER]

Ah, yes, interesting:

Initially, before the HTTPS query:

Aug  3 12:50:16 dnsmasq[898697]: TCP 5941 192.168.1.240/64521 query[A] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:16 dnsmasq[898697]: TCP 5941 192.168.1.240/64521 forwarded gitlab.yyy.zzz to 1.1.1.2
Aug  3 12:50:16 dnsmasq[898697]: TCP 5941 192.168.1.240/64521 reply gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898697]: TCP 5941 192.168.1.240/64521 reply proxy01.xxx.yyy.zzz is x.y.25.213 (DNSSEC signed)

and a bit later from the cache:

Aug  3 12:50:16 dnsmasq[898699]: TCP 6221 192.168.1.240/64524 query[A] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:16 dnsmasq[898699]: TCP 6221 192.168.1.240/64524 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898699]: TCP 6221 192.168.1.240/64524 cached proxy01.xxx.yyy.zzz is x.y.25.213 (DNSSEC signed)

Then comes the HTTPS query

Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 query[HTTPS] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 forwarded gitlab.yyy.zzz to 1.1.1.2
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 reply gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:16 dnsmasq[898700]: TCP 6361 192.168.1.240/64525 reply proxy01.xxx.yyy.zzz is NODATA (DNSSEC signed)

and then, after the HTTPS query

Aug  3 12:50:21 dnsmasq[898715]: TCP 8461 192.168.1.240/64552 query[A] gitlab.yyy.zzz from 192.168.1.240
Aug  3 12:50:21 dnsmasq[898715]: TCP 8461 192.168.1.240/64552 cached gitlab.yyy.zzz is <CNAME> (DNSSEC signed)
Aug  3 12:50:21 dnsmasq[898715]: TCP 8461 192.168.1.240/64552 cached yyy.zzz is x.y.232.182 (DNSSEC signed)

where obviously proxy01.xxx.yyy.zzz != yyy.zzz

---

What does 1.1.1.2 return when you ask it for A gitlab.yyy.zzz and HTTPS gitlab.yyy.zzz ?

dig A gitlab.yyy.zzz @1.1.1.2
dig HTTPS gitlab.yyy.zzz @1.1.1.2

[bobvandevijver]

Here you go:

bobv@XPS15-9520-Bob:/projects$ dig A gitlab.yyy.zzz @1.1.1.2

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> A gitlab.yyy.zzz @1.1.1.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63722
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gitlab.yyy.zzz.             IN      A

;; ANSWER SECTION:
gitlab.yyy.zzz.      900     IN      CNAME   proxy01.xxx.yyy.zzz.
proxy01.xxx.yyy.zzz. 900 IN   A       x.y.25.213

;; Query time: 20 msec
;; SERVER: 1.1.1.2#53(1.1.1.2) (UDP)
;; WHEN: Sun Aug 03 20:24:40 CEST 2025
;; MSG SIZE  rcvd: 95

bobv@XPS15-9520-Bob:/projects$ dig HTTPS gitlab.yyy.zzz @1.1.1.2

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> HTTPS gitlab.yyy.zzz @1.1.1.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15090
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gitlab.yyy.zzz.             IN      HTTPS

;; ANSWER SECTION:
gitlab.yyy.zzz.      900     IN      CNAME   proxy01.xxx.yyy.zzz.

;; AUTHORITY SECTION:
yyy.zzz.             3600    IN      SOA     ns1.mijn.host. hostmaster.yyy.zzz. 1752691672 10800 3600 604800 3600

;; Query time: 28 msec
;; SERVER: 1.1.1.2#53(1.1.1.2) (UDP)
;; WHEN: Sun Aug 03 20:25:00 CEST 2025
;; MSG SIZE  rcvd: 139

[DL6ER]

I contacted Simon Kelley, the maintainer of the dnsmasq caching DNS server we are embedding and which working right here at the hearth of FTL. Let's see if he has a clue because this is 100% his code and he's also the one who knows best what to fix where exactly.

[DL6ER]

Please run

sudo pihole checkout ftl update/dnsmasq

to get the proposed bugfix and check if it does work as you'd expect thereafter!

---

pihole-FTL -v

should show

v6.2.3-148-g345efc10

when you grabbed the correct binary. It may take a few minutes until it is ready.

[bobvandevijver]

Just did that, but I'm seeing another version in the output:

bobvandevijver@pihole-vm:~$ pihole-FTL -v
vDev-345efc1

It does seem to match with the latest commit of that branch, so I assume that is the correct version?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please comment or update this issue or it will be closed in 5 days.

[bobvandevijver]

I haven't seen the issue return since running the update/dnsmasq version, so it seems to be fixed for me. @DL6ER Is there any indication when that version comes to the main branch so I can revert back to the normal versions?

[DL6ER]

We are preparing for the next release (see #2616) but high workloads on the maintainers in their "real life jobs" (as in: what pays the bills) leave very little room right now. It may happen next week or next month. We are getting closer but there are - unfortunately - no guarantees at all... I'd love to have better news for you, seriously.

[bobvandevijver]

I completely understand, I am balancing the same kind of things! Already happy with the confirmation that this will be included in the next version, will be patiently waiting for the release 🙂 Keep up the great work!

[DL6ER]

Sure, thanks! The fix was in #2603 which is already part of branch development which is always the base for any next release.