HTTPS record filtering

[ExternalDatabase]

Prerequisites

• I have checked the Wiki and Discussions and found no answer

• I have searched other issues and found no duplicates

• I want to report a bug and not ask a question or ask for help

• I have set up AdGuard Home correctly and configured clients to use it. (Use the Discussions for help with installing and configuring clients.)

Platform (OS and CPU architecture)

FreeBSD, AMD64 (aka x86_64)

Installation

Docker

Setup

On one machine

AdGuard Home version

v0.107.35

Action

nslookup -debug -type=a 'www.example.com' '$YOUR_AGH_ADDRESS'

/opt/adguardhome/work # nslookup -debug -type=a 'meetings.hubspot.com' '192.168.0.94'
Server: 192.168.0.94
Address: 192.168.0.94:53

Query #0 completed in 4ms:
Non-authoritative answer:
Name: meetings.hubspot.com
Address: 0.0.0.0

Expected result

return 0.0.0.0 or NXDOMAIN
AND
don't ask upstream server

Actual result

returned 4 times 0.0.0.0 and 1 time the request has been passed to upstream DNS server

that domain is just an example - it happens for other domains too randomly
most requests of blocked domains are resolved as 0.0.0.0 locally and AGH doesn't ask upstream for resolve them

Additional information and/or screenshots

From AGH:

From upstream DNS server:

[fernvenue]

So what is your block rule for this domain?

[ExternalDatabase]

that domain is listed within StevenBlack/hosts, so it should be blocked
in AGH settings blocking mode is set to return 0.0.0.0 (Null IP)

when the Client asks AGH for that domain type 'A' record - it is blocked
when the Client asks AGH for that domain type 'https' record - AGH resolve it as normal (not listed) domain

SOA, CNAME, NS, TXT requests are processed too (answer blocked by the upstream dns server):
`/opt/adguardhome/work # nslookup -debug -type=soa 'meetings.hubspot.com' '192.168.0.94'
Server: 192.168.0.94
Address: 192.168.0.94:53

Query #0 completed in 21ms:
Non-authoritative answer:

/opt/adguardhome/work # nslookup -debug -type=ns 'meetings.hubspot.com' '192.168.0.94'
Server: 192.168.0.94
Address: 192.168.0.94:53

Query #0 completed in 25ms:
Non-authoritative answer:

/opt/adguardhome/work # nslookup -debug -type=cname 'meetings.hubspot.com' '192.168.0.94'
Server: 192.168.0.94
Address: 192.168.0.94:53

Query #0 completed in 19ms:
Non-authoritative answer:

/opt/adguardhome/work # nslookup -debug -type=txt 'meetings.hubspot.com' '192.168.0.94'
Server: 192.168.0.94
Address: 192.168.0.94:53

Query #0 completed in 21ms:
Non-authoritative answer:
`

[fernvenue]

when the Client asks AGH for that domain type 'https' record - AGH resolve it as normal (not listed) domain

That's why I asked for your block rules, and you said:

that domain is listed within StevenBlack/hosts, so it should be blocked

Actually this is a duplicate issue for #5124, as @RainmakerRaw said:

If you look at the request types, it's processing HTTPS queries, not IP records. These will not resolve to an IP for the purposes of connecting to the server in question. In that sense, there's nothing to rewrite/block. Only A and AAAA record lookups need rewriting to 0.0.0.0 here, which prevents your client(s) from connecting to the domain in question. The HTTPS lookup is simply asking for information about the domain. See here.

So AdGuardHome's behavior here is actually expected and there is no error, and you can add this file as a separate filtering rule list instead, which will block all types of queries.

[ainar-g]

Safari is starting to use the ipv[46]hints for DNS resolving, though, so I feel like we should handle these better.

@Mizzick, please add DNS HTTPS record filtering to AdGuard Home.

[Mizzick]

Please have a look, we have implemented the requested changes.
The new build version v0.108.0-a.646+1e939703 has been just published to the edge channel.

[ainar-g]

We'll close this issue. Feel free to reopen if the filtering doesn't work for you.