Unable to whilelist domain without whitelisting downstream CNAME records

[cbcoutinho]

I'm trying to whitelist a domain that comes from clicking a link through an email (link.newyorker.com), but it gets blocked because it's actually a CNAME to some other links on the standard blocklists.

There seems to be other topics similar to this one, but I wasn't able to solve my problem by reading them. If I understand it correctly, I should be able to whiltelist link.newyorker.com alone and reach the other CNAME domains without a problem. I only want to allow the underlying CNAME records when they originate from queries in my whitelist

Inconsistent CNAME blocking?

What browser do you use, apparently Edge is regularly trying to connect to www.msn.com. That's why I have so many hits on the domain. In my config (using a lot of lists) pihole reports: pihole -q www.msn.com [i] No results found for www.msn.com within the block lists but the CNAME is on my personal list pihole -q a-0003.a-msedge.net Match found in http://localhost/mylist.txt: a-0003.a-msedge.net You can create a local list (your personal entries) by: creating a file in /var/www/html…

CNAME Replies Not Being Blocked

Problem with Beta 5.0: I just updated to version 5.0 today. CNAME replies in the query log are not showing as being blocked. The A and AAA records are blocked but not the CNAME reply. Is this the expected behavior? [Pi-Hole-CNAME]

<snip>
Feb 18 21:49:25 dnsmasq[29782]: query[A] link.newyorker.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: forwarded link.newyorker.com to 127.0.0.1
Feb 18 21:49:25 dnsmasq[29782]: query[AAAA] link.newyorker.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: forwarded link.newyorker.com to 127.0.0.1
Feb 18 21:49:25 dnsmasq[29782]: reply link.newyorker.com is <CNAME>
Feb 18 21:49:25 dnsmasq[29782]: reply cb.sailthru.com is <CNAME>
Feb 18 21:49:25 dnsmasq[29782]: reply ha-link.sailthru.com is NODATA-IPv6
Feb 18 21:49:25 dnsmasq[29782]: query[SOA] newyorker.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: forwarded newyorker.com to 127.0.0.1
Feb 18 21:49:25 dnsmasq[29782]: reply link.newyorker.com is <CNAME>
Feb 18 21:49:25 dnsmasq[29782]: reply cb.sailthru.com is <CNAME>
Feb 18 21:49:25 dnsmasq[29782]: reply ha-link.sailthru.com is 3.226.166.212
Feb 18 21:49:25 dnsmasq[29782]: reply ha-link.sailthru.com is 162.208.117.53
Feb 18 21:49:25 dnsmasq[29782]: query[DS] newyorker.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: forwarded newyorker.com to 127.0.0.1
Feb 18 21:49:25 dnsmasq[29782]: query[AAAA] cb.sailthru.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: gravity blocked cb.sailthru.com is ::
Feb 18 21:49:25 dnsmasq[29782]: query[A] cb.sailthru.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: gravity blocked cb.sailthru.com is 0.0.0.0
Feb 18 21:49:25 dnsmasq[29782]: query[SOA] cb.sailthru.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: gravity blocked cb.sailthru.com is 0.0.0.0
Feb 18 21:49:25 dnsmasq[29782]: query[DS] cb.sailthru.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: gravity blocked cb.sailthru.com is 0.0.0.0
Feb 18 21:49:25 dnsmasq[29782]: query[SOA] sailthru.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: forwarded sailthru.com to 127.0.0.1
Feb 18 21:49:25 dnsmasq[29782]: query[DS] sailthru.com from 192.168.2.11
Feb 18 21:49:25 dnsmasq[29782]: forwarded sailthru.com to 127.0.0.1
<snip>

$ dig link.newyorker.com @8.8.8.8

; <<>> DiG 9.16.11 <<>> link.newyorker.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10430
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;link.newyorker.com.            IN      A

;; ANSWER SECTION:
link.newyorker.com.     229     IN      CNAME   cb.sailthru.com.
cb.sailthru.com.        59      IN      CNAME   ha-link.sailthru.com.
ha-link.sailthru.com.   59      IN      A       3.226.166.212
ha-link.sailthru.com.   59      IN      A       162.208.117.53

;; Query time: 27 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: do feb 18 21:51:39 CET 2021
;; MSG SIZE  rcvd: 127

If I whitelist all the domains that link.newyorker.com resolves to I am able to get through, but I want to selectively whitelist sailthru for just queries that originate from link.newyorker.com.

Via the UI it looks like the queries are successful (to newyorker.com) but my browser still shows a black screen, and dig shows that the CNAME record for sailthru is blocked.

$ dig link.newyorker.com

; <<>> DiG 9.16.11 <<>> link.newyorker.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48475
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;link.newyorker.com.		IN	A

;; ANSWER SECTION:
link.newyorker.com.	59	IN	CNAME	cb.sailthru.com.
cb.sailthru.com.	2	IN	A	0.0.0.0

;; Query time: 7 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: do feb 18 21:59:29 CET 2021
;; MSG SIZE  rcvd: 89

How do I whitelist link.newyorker.com without whitelisting the other sailthru links? Is this possible?

[DanSchaper]

@cbcoutinho

If I whitelist all the domains that link.newyorker.com resolves to I am able to get through, but I want to selectively whitelist sailthru for just queries that originate from link.newyorker.com.

You can't. You'll have to whitelist link.newyorker.com and only link.newyorker.com will be allowed.

Check your Unbound instance to see what is going on. The last screenshot shows link.newyorker.com is not being blocked by Pi-hole.

[cbcoutinho]

Thanks for the response @DanSchaper

I flushed my DNS caches on both my client and the Pi-Hole. It looks like newyorker.com is getting through, but the subsequent to sailthru queries are blocked

[jfb]

Please generate a debug log, upload it when prompted and post the token here.

[DanSchaper]

You wouldn't see two separate queries in a CNAME chain. Those are two separate queries.

This is on a stock install.

 $ dig link.newyorker.com

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> link.newyorker.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59025
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;link.newyorker.com.            IN      A

;; Query time: 188 msec
;; SERVER: 192.168.88.2#53(192.168.88.2)
;; WHEN: Thu Feb 18 13:21:23 PST 2021
;; MSG SIZE  rcvd: 47

[DanSchaper]

Your setup is a bit odd, there are queries for DS and SOA records, which shouldn't happen with a client. The resonse from an A/AAAA is "N/A" and not IP. I really think you have a problem with your upstream and that's where you need to tail logs to find out.

[cbcoutinho]

I'd be happy to: https://tricorder.pi-hole.net/isvsb5m1d4

The only thing non-standard on this install that I can remember is that I'm using unbound as the upstream DNS resolver

Unbound config:

server:
    # If no logfile is specified, syslog is used
    logfile: "/var/log/unbound/unbound.log"
    verbosity: 2

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

[cbcoutinho]

I found the problem. I have a split DNS setup on the (Linux) client in question, which is managed by systemd-resolved and its own DNS 'stub'. The stub is doing a bunch of its own resolving which is why you see all the SOA and DS queries on the pihole logs.

Another client without this setup works as expected. I'll have to see if I can figure it out on the systemd side as this doesn't seem to be an issue with pi-hole