Custom Filtering Rules & fake-for-negative-caching.adguard.com

[WildByDesign]

Recently, I have noticed that if you have dnsrewrite rules pointing to NXDOMAIN in Custom Filtering Rules, clients do not receive a response with fake-for-negative-caching.adguard.com included with the NXDOMAIN response.

However, if you have those same rules included with a filter rule list, clients do properly receive the fake-for-negative-caching.adguard.com included with the NXDOMAIN response.

Example Rules:

||mask.icloud.com^$dnsrewrite=NXDOMAIN;;
||mask-h2.icloud.com^$dnsrewrite=NXDOMAIN;;
||mask-canary.icloud.com^$dnsrewrite=NXDOMAIN;;

I figured that I should ask about this in Discussions first to see if this is a bug or intended behavior before filing a bug report.

Is this a bug?
Should I file a bug report?

Thank you.

[ainar-g]

As the domain name suggests, it's a fake SOA record to enable caching of negative responses. Basically its only function is to carry a TTL value.

[WildByDesign]

Thank you for your response. That was my understanding.

But what I didn’t understand was why it does not show the fake SOA for Custom Filtering Rules. Since it does show it if those same rules are included in a filter list.

[ainar-g]

(Please use replies instead of new threads.)

That depends on which blocking mode you're using. The default one adds records with a TTL of their own, so a SOA record isn't necessary to make the response cacheable.

[WildByDesign]

Sorry about that. I wasn't very familiar with discussions here. I will make sure to use replies.

I have my blocking mode set to NXDOMAIN lately because I have been testing blocking iCloud Private Relay and other Apple-related sneaky behavior. Generally I keep it on Default though.

I guess I had the impression that maybe it wasn't caching since I wasn't getting the SOA with the one method, but was getting it with the other.

Clearly, my impression and understanding was wrong. Thank you for clearing that up for me.