Ftl: BLOCKINGMODE is not honored for Deep CNAME inspection.

[DarkDimius]

Versions

Pi-hole version is v5.2.1 (Latest: v5.2.1)
AdminLTE version is v5.2.1 (Latest: v5.2.1)
FTL version is v5.3.2 (Latest: v5.3.2)

Platform

Ubuntu 18.04.5 LTS

LXC container(but it shouldn't matter)

Expected behavior

dig link.generalassemb.ly

; <<>> DiG 9.10.6 <<>> link.generalassemb.ly
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28352
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
link.generalassemb.ly.          2   IN  A   0.0.0.0

;; Query time: 14 msec
;; SERVER: 192.168.8.6#53(192.168.8.6)
;; WHEN: Sat Dec 19 18:39:40 PST 2020
;; MSG SIZE  rcvd: 50

Actual behavior / bug

Instead of using the BLOCKINGMODE=null it uses response as-it if was configured with NODATA mode for queries blocked using deep domain inspection.

; <<>> DiG 9.10.6 <<>> link.generalassemb.ly
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28352
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;link.generalassemb.ly.     IN  A

;; Query time: 14 msec
;; SERVER: 192.168.8.6#53(192.168.8.6)
;; WHEN: Sat Dec 19 18:39:40 PST 2020
;; MSG SIZE  rcvd: 50

Dec 20 02:33:42 dnsmasq[334]: query[A] link.generalassemb.ly from 192.168.8.191
Dec 20 02:33:42 dnsmasq[334]: forwarded link.generalassemb.ly to 127.0.0.1
Dec 20 02:33:42 dnsmasq[334]: reply link.generalassemb.ly is <CNAME>
Dec 20 02:33:42 dnsmasq[334]: reply cb.sailthru.com is blocked during CNAME inspection

Steps to reproduce

Steps to reproduce the behavior:

1. Make sure you have cb.sailthru.com blocked, either via one of lists or via dirrectly adding it to blocklist
2. do dig link.generalassemb.ly (which is actually a CNAME to cb.sailthru.com)

Debug token

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

(edited, original version incorrectly mentioned NXDOMAIN response, thank you to @.dschaper for catching that)

[DarkDimius]

Why this matters: the network in question gives clients a local domain prefix via dhcp. Having link.generalassemb.ly fail resolution makes some clients attempt to find it at link.generalassemb.ly.<local_domain>(which resolves) and thus leads to surprises

[dschaper]

The response is NOERROR not NXDOMAIN.

[DarkDimius]

Agreed, still, the expected response under this configuration (BLOCKINGMODE=null) should be resolving to 0.0.0.0, right?

[dschaper]

Possibly, but I think the bigger problem is the fact that link.generalassemb.ly.<local_domain> actually resolves.

[dschaper]

What does ping link.generalassemb.ly show as a response?

[DarkDimius]

Possibly, but I think the bigger problem is the fact that link.generalassemb.ly. actually resolves.

Yeah, it's unfortunate, but I don't think I'd be able to change that. This network has a wildcard dns A record.

What does ping link.generalassemb.ly show as a response?

$ ping link.generalassemb.ly
PING link.generalassemb.ly.<local_domain_redacted> (REDACTED_IP) 56(84) bytes of data.
64 bytes from REDACTED_IP (REDACTED_IP): icmp_seq=1 ttl=64 time=2.78 ms

where REDACTED_IP is address that wildcard A record points to.

[dschaper]

Also, can you go to your admin interface, under the Query Log, do a search for link.generalassemb.ly and show what the output is for status?

[dschaper]

So, anything that doesn't return an IP address from Pi-hole is automatically returned an IP from unbound?

[DarkDimius]

Also, can you go to your admin interface, under the Query Log, do a search for link.generalassemb.ly and show what the output is for status?

yes, more than happy to!

So, anything that doesn't return an IP address from Pi-hole is automatically returned an IP from unbound?

yes. It's an unfortunate implication of how the network is setup.

[dschaper]

Thanks, I'll ask @DL6ER to take a look. He's extremely busy right now so it may take a bit for his review.

[DarkDimius]

Thank you. No rush, I'll disable deep cname inspection for now, but will be looking forward to re-enable it.

is actually a better demo

[DL6ER]

Thanks for your report. What you observe is due to a technical limitation (mentioned here but arguably difficult to find). To fix this, it may be necessary to rewrite a lot of code. Further investigations ongoing. And we'll have to check if that's at all possible without changing too much of dnsmasq's code.

The problem here is the entire reply to a CNAME query comes all in one big batch from upstream and they are directly stream to the requesting client. The window for interventions is basically non-existent and we barely manage to make the reply a NODATA one.

[DL6ER]

@DarkDimius Please try

pihole checkout ftl tweak/cname_inspection_blocking

It should implement blocking CNAME replies with the configured blocking mode. I have only been able to do very limited testing on this (I'm in the middle of moving/relocating and my development environment has only partially moved so far), so anything you can do to test it is highly appreciated. There are two (new) technical limitations here, however, I will list them more for completeness than anything else, because they shouldn't matter for our purpose (blocking a query).

1. We do not return a CNAME but, instead, create an artificial A record instead to be sent to the querying client.
   The reason for this simplification is that it is seems unnecessarily complicated to create an entire CNAME-structure here when the goal is really only to block the queries.

   Normal query (nothing is blocked)

   ```
   ;; QUESTION SECTION:
   ;link.generalassemb.ly. IN A

   ;; ANSWER SECTION:
   link.generalassemb.ly. 28750 IN CNAME cb.sailthru.com.
   cb.sailthru.com. 10 IN CNAME ha-link.sailthru.com.
   ha-link.sailthru.com. 10 IN A 162.208.117.53
   ha-link.sailthru.com. 10 IN A 3.226.166.212
   ```

   Blocked query (cb.sailthru.com is blocked, the client cannot see this)

   ```
   ;; QUESTION SECTION:
   ;link.generalassemb.ly. IN A

   ;; ANSWER SECTION:
   link.generalassemb.ly. 2 IN A 0.0.0.0
   ```

2. We always mock A replies. Even when clients requests AAAA (or whatever else) records, the reply will be an A query. This simply avoids us having to go back to the original request and check what the question was.

[yubiuser]

Can confirm working, tested with blocking mode NULL and IP

dig fonts.gstatic.com

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> fonts.gstatic.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40023
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fonts.gstatic.com.     IN  A

;; Query time: 24 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Sun Dec 20 20:37:41 CET 2020
;; MSG SIZE  rcvd: 35

dig fonts.gstatic.com

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> fonts.gstatic.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5746
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fonts.gstatic.com.     IN  A

;; ANSWER SECTION:
fonts.gstatic.com.  2   IN  A   0.0.0.0

;; Query time: 6 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Sun Dec 20 20:38:25 CET 2020
;; MSG SIZE  rcvd: 51

dig fonts.gstatic.com

; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> fonts.gstatic.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15956
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fonts.gstatic.com.     IN  A

;; ANSWER SECTION:
fonts.gstatic.com.  2   IN  A   10.0.1.5

;; Query time: 6 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Sun Dec 20 20:59:25 CET 2020
;; MSG SIZE  rcvd: 51

[DarkDimius]

Seems to be working perfectly for me too: but so far I haven't seen any issues! Thank you, @.DL6ER , I'll continue running it and will report if it causes any issues.

[DL6ER]

Thanks for your testing. Meanwhile, I worked on an improved DNS header question parsing to determine the type of the original request. This resolves my technical limitation no. 2 above, i.e. a blocked reply for an AAAA query will now also be a AAAA record.

In other words:

• Before: dig AAAA blocked.cname -> 0.0.0.0
• Now: dig AAAA blocked.cname -> ::

Why did I add this? Well, mostly because I just like clean solutions without any internal hackyness :-)

[dschaper]

I think there's a big OS that queries AAAA first anyways, so it's good to have both AAAA and A return null.

[DL6ER]

The next version of FTL has been released. Please update and run

pihole checkout master

to get back on track. Thanks for helping us to make Pi-hole better for us all!

If you have any issues, please either reopen this ticket or (preferably) create a new ticket describing the issues in further detail and only reference this ticket. This will help us to help you best.