Resolving CNAMEs for allowlist entries

In my pi-hole setup I have a list of domains that starts with a regex .* deny followed by a lot of allows for various streaming services. When I query one of the allowed entries that is a CNAME pi-hole resolves the CNAME and all other DNS entries that it refers to. ie:

$ dig @pihole iview-vod-hls.akamaized.net

...

;; ANSWER SECTION:
iview-vod-hls.akamaized.net. 16163 IN   CNAME   a1977.dscv.akamai.net.
a1977.dscv.akamai.net.  16      IN      A       123.253.149.41
a1977.dscv.akamai.net.  16      IN      A       123.253.149.82

...

which shows as the following in the pi-hole logs:

dnsmasq[147]: query[A] iview-vod-hls.akamaized.net from 192.168.1.126
dnsmasq[147]: forwarded iview-vod-hls.akamaized.net to 192.168.1.1
dnsmasq[147]: reply iview-vod-hls.akamaized.net is <CNAME>
dnsmasq[147]: reply a1977.dscv.akamai.net is 123.253.149.41
dnsmasq[147]: reply a1977.dscv.akamai.net is 123.253.149.82

However I would like to take advantage of the support added in v6 for allowlist subscriptions and convert these individual allow rules into an allowlist to make it easier to manage the entries. Unfortunately when using the allowlist it doesn't seem to resolve the CNAME entries the same way the individual rules are. ie:

$ dig @pihole iview-vod-hls.akamaized.net

...

;; ANSWER SECTION:
iview-vod-hls.akamaized.net. 2  IN      A       0.0.0.0

...

the pi-hole logs indicates that it is blocked during CNAME inspection:

dnsmasq[147]: query[A] iview-vod-hls.akamaized.net from 192.168.1.126
dnsmasq[147]: forwarded iview-vod-hls.akamaized.net to 192.168.1.1
dnsmasq[147]: reply iview-vod-hls.akamaized.net is <CNAME>
dnsmasq[147]: reply a1977.dscv.akamai.net is blocked during CNAME inspection
dnsmasq[147]: regex denied iview-vod-hls.akamaized.net is 0.0.0.0

I would prefer not to have to add every single entry that each CNAME resolves to (which in some cases may be many levels deep and often changing).

I am wondering if this is the expected behaviour or if there is a way for the allowlist entries to be treated the same way as the individual entries are? Or am I stuck having to manage things using the individual entries?

Please share your allow list file.

Also, please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

https://tricorder.pi-hole.net/TA1qh1qW/

The allowlist is just the following:

### Required
ctv.iview.abc.net.au
api.seesaw.abc.net.au
cdn.iview.abc.net.au
api.iview.abc.net.au
# Video files
iview-vod-hls.akamaized.net

### Queried but functional without
# mylogin-api.abc.net.au - required for login?
# res.iview.abc.net.au
# res.abc.net.au - font files
# recommendations.abc.net.au - show recommendations
# deliver.oztam.com.au

Note that some of these entries in the allowlist are also added as individual entries, but disabled.

Your debug log shows your custom lists to be correctly configured, enabled adnd assigned to a custom group, including two clients using that group.
Probably unrelated to your observation, but I noticed that both of those clients are on a subnet (each) different from that of your Pi-hole (2 192.168.x.x vs. 10.x.x.x).

Your observation is not related to CNAMEs, but to the order of precedence for matching allowed and blocked domains:

(emphasis mine)

As you have defined a regex block:

That regex block trumps your subscribed allowlist, showing in the log:

Your observation matches the expected behaviour.

Note that regular allowed domains will trump any blacklist, so you can keep using your existing definitions.

The 10.x.x.x address is just the network namespace within the Pi-hole container. Pi-hole is exposed via the host interface on a 192.168.x.x address.


Thanks for the clarification about the regex blocked domains having a higher priority. That clears thing up a bit.

Now I've tried replacing the regex .* block with the following default-deny blocklist:

||net^

(as an aside I'm assuming there is no equivalent of the .* regex using blocklists?)

However even with the correct prioritising of allowlists/blocklists it seems like the CNAME resolution behaviour is still different from the individual domain entries:

dig @pihole iview-vod-hls.akamaized.net

...

;; ANSWER SECTION:
iview-vod-hls.akamaized.net. 2  IN      A       0.0.0.0

...

From the logs it appears that the CNAME entries are still being blocked:

dnsmasq[147]: query[A] iview-vod-hls.akamaized.net from 192.168.1.126
dnsmasq[147]: forwarded iview-vod-hls.akamaized.net to 192.168.1.1
dnsmasq[147]: reply iview-vod-hls.akamaized.net is <CNAME>
dnsmasq[147]: reply a1977.dscv.akamai.net is blocked during CNAME inspection
dnsmasq[147]: gravity blocked iview-vod-hls.akamaized.net is 0.0.0.0

Here is an update debug log if it helps: https://tricorder.pi-hole.net/TzjHLCLk/


True, but I was hoping to use allowlists to make it easier to mange allowed entries and also provide the ability to enable/disable groups of entries with a single click (instead of having to find all the individual entries and enable/disable them individually)

Perhaps that list didn't parse correctly.
Could you share the output from updating gravity?

Output from gravity update:

  [i] Upgrading gravity database from version 18 to 19
  [i] Neutrino emissions detected...
  [✓] Pulling blocklist source list into range

  [✓] Preparing new gravity database
  [✓] Creating new gravity databases
  [i] Using libz compression

  [i] Target: http://<redacted>/lgtv-streaming-allowlists/iview.list
  [✓] Status: No changes detected
  [✓] Parsed 5 exact domains and 0 ABP-style domains (allowing, ignored 0 non-domain entries)

  [i] Target: http://<redacted>/lgtv-streaming-allowlists/default-deny.list
  [✓] Status: No changes detected
  [✓] Parsed 0 exact domains and 1 ABP-style domains (blocking, ignored 0 non-domain entries)

  [✓] Building tree
  [i] Number of gravity domains: 1 (1 unique domains)
  [i] Number of exact denied domains: 0
  [i] Number of regex denied filters: 1
  [i] Number of exact allowed domains: 1
  [i] Number of regex allowed filters: 0
  [✓] Swapping databases
  [✓] The old database remains available
  [✓] Cleaning up stray matter

  [✓] Done.

Also the output from using Search Lists:

Found 1 domain exactly matching 'iview-vod-hls.akamaized.net':

  - iview-vod-hls.akamaized.net
    exact allow domain
    added:         2024-03-24 21:04:36
    last modified: 2024-03-27 10:27:26
    disabled, used in 1 group
    comment: "iView"

Found 2 lists exactly matching 'iview-vod-hls.akamaized.net':

  - http://<redacted>/lgtv-streaming-allowlists/default-deny.list
    block list
    added:         2024-03-26 19:59:47
    last modified: 2024-03-27 10:24:03
    last updated:  2024-03-27 10:24:30 (1 domains)
    enabled, used in 1 group
    no comment
    matching entries:
    - ||net^

  - http://<redacted>/lgtv-streaming-allowlists/iview.list
    allow list
    added:         2024-03-24 23:07:10
    last modified: 2024-03-27 10:24:04
    last updated:  2024-03-27 10:24:30 (5 domains)
    enabled, used in 1 group
    comment: "iView"
    matching entries:
    - iview-vod-hls.akamaized.net

Number of results per type:
  - 1 exact domain matches
  - 0 regex domain matches
  - 1 allowlist (antigravity) matches
  - 1 blocklist (gravity) matches

That looks ok to me.

Could you check whether your domain-based blocks for those same domains would be still active?
Your allowlist would not override those.

What I used to reproduce this:

$ cat /etc/pihole/abp.list
||abcd.net^

and the allowed domain:

Seems to work as expected for me:

$ dig abcd.net

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> abcd.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59864
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;abcd.net.                      IN      A

;; ANSWER SECTION:
abcd.net.               2       IN      A       0.0.0.0

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Mar 28 09:34:55 CET 2024
;; MSG SIZE  rcvd: 53
$ dig xyz.abcd.net

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> xyz.abcd.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3384
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;xyz.abcd.net.                  IN      A

;; ANSWER SECTION:
xyz.abcd.net.           21600   IN      A       165.160.13.20
xyz.abcd.net.           21600   IN      A       165.160.15.20

;; Query time: 24 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Mar 28 09:36:54 CET 2024
;; MSG SIZE  rcvd: 73

@jerrykan please run

sudo pihole-FTL --config debug.queries true

and then query the domain you expect not to be blocked again. Afterwards, please check your log file /var/log/pihole/FTL.log


In my example above:

2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: **** new UDP IPv4 query[A] query "xyz.abcd.net" from lo/127.0.0.1#35020 (ID 109882, FTL 35528, src/dnsmasq/forward.c:1804)
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: xyz.abcd.net is known as not to be blocked (allowed)
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: **** got cache reply: xyz.abcd.net is 165.160.13.20 (ID 109882, src/dnsmasq/rfc1035.c:2047)
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: Set reply to IP (4) in src/dnsmasq_interface.c:2089
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: FTL_CNAME called with: src = xyz.abcd.net, dst = xyz.abcd.net, id = 109882
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: xyz.abcd.net is known as not to be blocked (allowed)
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: Query 109882: CNAME xyz.abcd.net ---> xyz.abcd.net
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: **** got cache reply: xyz.abcd.net is 165.160.15.20 (ID 109882, src/dnsmasq/rfc1035.c:2047)
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: FTL_CNAME called with: src = xyz.abcd.net, dst = xyz.abcd.net, id = 109882
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: xyz.abcd.net is known as not to be blocked (allowed)
2024-03-28 09:38:19.113 [834289M] DEBUG_QUERIES: Query 109882: CNAME xyz.abcd.net ---> xyz.abcd.net

The important part here is xyz.abcd.net is known as not to be blocked (allowed) (this is a cached reply).

After restarting FTL to force the cache being cleared:

2024-03-28 09:39:58.215 [1890424M] DEBUG_QUERIES: **** new UDP IPv4 query[A] query "xyz.abcd.net" from lo/127.0.0.1#41499 (ID 25, FTL 30605, src/dnsmasq/forward.c:1804)
2024-03-28 09:39:58.215 [1890424M] DEBUG_QUERIES: xyz.abcd.net is not known
2024-03-28 09:39:58.215 [1890424M] DEBUG_QUERIES: DNS cache: 127.0.0.1/xyz.abcd.net is whitelisted (domainlist ID: 2)
2024-03-28 09:39:58.216 [1890424M] DEBUG_QUERIES: **** forwarded xyz.abcd.net to 8.8.8.8#53 (ID 25, src/dnsmasq/forward.c:554)
2024-03-28 09:39:58.226 [1890424M] DEBUG_QUERIES: **** new IPv4 dnssec-query[DS] query "net" from -/<internal>#53 (ID 26, FTL 30606, src/dnsmasq/forward.c:1102)
2024-03-28 09:39:58.226 [1890424M] DEBUG_QUERIES: **** forwarded net to 8.8.8.8#53 (ID 26, src/dnsmasq/forward.c:1102)
2024-03-28 09:39:58.232 [1890424M] DEBUG_QUERIES: **** got upstream reply from 8.8.8.8#53: net is DNSKEY (ID 26, src/dnsmasq/dnssec.c:1106)
2024-03-28 09:39:58.232 [1890424M] DEBUG_QUERIES: Set reply to DNSSEC (11) in src/dnsmasq_interface.c:2176
2024-03-28 09:39:58.232 [1890424M] DEBUG_QUERIES: **** new IPv4 dnssec-query[DS] query "abcd.net" from -/<internal>#53 (ID 27, FTL 30607, src/dnsmasq/forward.c:1102)
2024-03-28 09:39:58.232 [1890424M] DEBUG_QUERIES: **** forwarded abcd.net to 8.8.8.8#53 (ID 27, src/dnsmasq/forward.c:1102)
2024-03-28 09:39:58.242 [1890424M] DEBUG_QUERIES: **** new IPv4 dnssec-query[DNSKEY] query "net" from -/<internal>#53 (ID 28, FTL 30608, src/dnsmasq/forward.c:1102)
2024-03-28 09:39:58.242 [1890424M] DEBUG_QUERIES: **** forwarded net to 8.8.8.8#53 (ID 28, src/dnsmasq/forward.c:1102)
2024-03-28 09:39:58.247 [1890424M] DEBUG_QUERIES: **** got upstream reply from 8.8.8.8#53: net is DNSKEY (ID 28, src/dnsmasq/dnssec.c:955)
2024-03-28 09:39:58.247 [1890424M] DEBUG_QUERIES: Set reply to DNSSEC (11) in src/dnsmasq_interface.c:2176
2024-03-28 09:39:58.247 [1890424M] DEBUG_QUERIES: **** got upstream reply: net is DNSKEY (ID 28, src/dnsmasq/dnssec.c:955)
2024-03-28 09:39:58.248 [1890424M] DEBUG_QUERIES: **** got upstream reply: abcd.net is no DS (ID 27, src/dnsmasq/dnssec.c:1144)
2024-03-28 09:39:58.248 [1890424M] DEBUG_QUERIES: Set reply to NODATA (1) in src/dnsmasq_interface.c:2176
2024-03-28 09:39:58.248 [1890424M] DEBUG_QUERIES: **** DNSSEC xyz.abcd.net is INSECURE (ID 25, src/dnsmasq/forward.c:1403)
2024-03-28 09:39:58.248 [1890424M] DEBUG_QUERIES: **** got upstream reply from 8.8.8.8#53: xyz.abcd.net is 165.160.13.20 (ID 25, src/dnsmasq/rfc1035.c:1047)
2024-03-28 09:39:58.248 [1890424M] DEBUG_QUERIES: Set reply to IP (4) in src/dnsmasq_interface.c:2176
2024-03-28 09:39:58.248 [1890424M] DEBUG_QUERIES: **** got upstream reply: xyz.abcd.net is 165.160.15.20 (ID 25, src/dnsmasq/rfc1035.c:1047)

The important bits here are: xyz.abcd.net is not known followed by DNS cache: 127.0.0.1/xyz.abcd.net is whitelisted (domainlist ID: 2)

Everything seems perfectly fine for my in this test.

No there are no domain-based blocks enabled. To make sure I have deleted all the non-list "Domain management" rules.

@DL6ER I think we might be talking cross purposes. After initially tring to mix domain rules and lists, I am now only using block/allow lists and no individual rules.


Using a fresh container image these are the steps I'm following:

Start a new pihole container (note: podman is a drop-in replacement for docker):

podman run -ti -p 5353:53 --env FTLCONF_dns_upstreams=192.168.1.1 docker.io/pihole/pihole:development-v6

Log into the pihole web interface and delete the default blocklist: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts

Add the blocklist: https://gist.githubusercontent.com/jerrykan/511dd4d90740177f17caf0d08ccd58ab/raw/2ac9b41f6a3082a3f0bfe9e08b310c46d353d153/block.list

Add the allowlist: https://gist.githubusercontent.com/jerrykan/511dd4d90740177f17caf0d08ccd58ab/raw/2ac9b41f6a3082a3f0bfe9e08b310c46d353d153/iview.list

Update Gravity:

[i] Upgrading gravity database from version 18 to 19
  [i] Neutrino emissions detected...
  [✓] Pulling blocklist source list into range

  [✓] Preparing new gravity database
  [✓] Creating new gravity databases
  [i] Using libz compression

  [i] Target: https://gist.githubusercontent.com/jerrykan/511dd4d90740177f17caf0d08ccd58ab/raw/2ac9b41f6a3082a3f0bfe9e08b310c46d353d153/block.list
  [✓] Status: Retrieval successful
  [✓] Parsed 0 exact domains and 1 ABP-style domains (blocking, ignored 0 non-domain entries)

  [i] Target: https://gist.githubusercontent.com/jerrykan/511dd4d90740177f17caf0d08ccd58ab/raw/2ac9b41f6a3082a3f0bfe9e08b310c46d353d153/iview.list
  [✓] Status: Retrieval successful
  [✓] Parsed 5 exact domains and 0 ABP-style domains (allowing, ignored 0 non-domain entries)

  [✓] Building tree
  [i] Number of gravity domains: 1 (1 unique domains)
  [i] Number of exact denied domains: 0
  [i] Number of regex denied filters: 0
  [i] Number of exact allowed domains: 0
  [i] Number of regex allowed filters: 0
  [✓] Swapping databases
  [✓] The old database remains available
  [✓] Cleaning up stray matter

  [✓] Done.

Perform a query from my local host:

$ dig @localhost iview-vod-hls.akamaized.net -p 5353 +tcp

; <<>> DiG 9.19.21-1-Debian <<>> @localhost iview-vod-hls.akamaized.net -p 5353 +tcp
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49143
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;iview-vod-hls.akamaized.net.   IN      A

;; ANSWER SECTION:
iview-vod-hls.akamaized.net. 2  IN      A       0.0.0.0

;; Query time: 47 msec
;; SERVER: ::1#5353(localhost) (TCP)
;; WHEN: Thu Mar 28 21:53:39 AEDT 2024
;; MSG SIZE  rcvd: 72

The associated debug log:

2024-03-28 10:53:39.292 [389/F237] DEBUG_ANY: TCP worker forked for client 10.0.2.100 on interface  with IP 10.0.2.100
2024-03-28 10:53:39.293 [389/F237] DEBUG_ANY: Reopening Gravity database for this fork
2024-03-28 10:53:39.298 [389/F237] DEBUG_QUERIES: Domain suffix is "lan"
2024-03-28 10:53:39.299 [389/F237] DEBUG_QUERIES: **** new TCP IPv4 query[A] query "iview-vod-hls.akamaized.net" from tap0/10.0.2.100#55830 (ID 1, FTL 0, src/dnsmasq/forward.c:2376)
2024-03-28 10:53:39.299 [389/F237] DEBUG_QUERIES: iview-vod-hls.akamaized.net is not known
2024-03-28 10:53:39.301 [389/F237] DEBUG_QUERIES: Checking if "iview-vod-hls.akamaized.net" is in antigravity (exact): yes
2024-03-28 10:53:39.301 [389/F237] DEBUG_QUERIES: Allowing query due to antigravity match (list ID 3)
2024-03-28 10:53:39.302 [389/F237] DEBUG_QUERIES: DNS cache: 10.0.2.100/iview-vod-hls.akamaized.net is not blocked (domainlist ID: -5)
2024-03-28 10:53:39.338 [389/F237] DEBUG_QUERIES: **** forwarded iview-vod-hls.akamaized.net to 192.168.1.1#53 (ID 1, src/dnsmasq/forward.c:2552)
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: **** got upstream reply from 192.168.1.1#53: iview-vod-hls.akamaized.net is (CNAME) (ID 1, src/dnsmasq/rfc1035.c:845)
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: Set reply to CNAME (3) in src/dnsmasq_interface.c:2176
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: FTL_CNAME called with: src = iview-vod-hls.akamaized.net, dst = a1977.dscv.akamai.net, id = 1
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: a1977.dscv.akamai.net is not known
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: Checking if "a1977.dscv.akamai.net" is in antigravity (exact): no
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: Checking if "@@||net^" is in antigravity (ABP): no
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: Checking if "@@||akamai.net^" is in antigravity (ABP): no
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: Checking if "@@||dscv.akamai.net^" is in antigravity (ABP): no
2024-03-28 10:53:39.339 [389/F237] DEBUG_QUERIES: Checking if "@@||a1977.dscv.akamai.net^" is in antigravity (ABP): no
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: Checking if "a1977.dscv.akamai.net" is in gravity (exact): no
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: Checking if "||net^" is in gravity (ABP): no
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: DNS cache: 10.0.2.100/a1977.dscv.akamai.net is gravity blocked
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: Blocking query due to gravity match (list ID 2)
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: Blocking a1977.dscv.akamai.net as a1977.dscv.akamai.net is gravity blocked (domainlist ID: -4)
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: Set reply to CNAME (3) in src/dnsmasq_interface.c:1599
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: Query 1: CNAME iview-vod-hls.akamaized.net ---> a1977.dscv.akamai.net
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: **** got upstream reply: a1977.dscv.akamai.net is blocked during CNAME inspection (ID 1, src/dnsmasq/rfc1035.c:877)
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: Preparing reply for "iview-vod-hls.akamaized.net", EDE: N/A
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES:   Adding RR: "iview-vod-hls.akamaized.net A 0.0.0.0"
2024-03-28 10:53:39.340 [389/F237] DEBUG_QUERIES: **** got cache reply: iview-vod-hls.akamaized.net is 0.0.0.0 (ID 1, src/dnsmasq_interface.c:406)
2024-03-28 10:53:39.341 [389/F237] DEBUG_ANY: TCP worker terminating (client disconnected)

My reading of the debug log is:

  • query for iview-vod-hls.akamaized.net received
  • iview-vod-hls.akamaized.net is allowed due to an antigravity match
  • iview-vod-hls.akamaized.net is a CNAME that points to a1977.dscv.akamai.net
  • a1977.dscv.akamai.net is blocked due to a gravity match
  • this results in iview-vod-hls.akamaized.net essentially being blocked

Okay, thanks, that clears up some confusion here. Based on your debug log, I have traced down that the cause is that we are not explicitly marking a query to be allowed when an antigravity match happened. Such a remark on the query prevents any further inspection and is currently only applied for exact/regex domain matches but not antigravity.

The fix is super simple in theory. Please run

pihole checkout ftl fix/antigravity_mark

and confirm that this fixes the issue you are observing.

@DL6ER Yep, that change in the fix/antigravity_mark branch seem to have done the trick. Thanks for looking into this. I look forward to the fix making its way into the development-v6 branch.

The fix has been merged yesterday into development-v6.

1 Like