Should cloaked domains also cloak HTTPS records?

[TonyDC]

I've observed an interesting behaviour when using Google Chrome for cloaked domain names. I use cloaking rules for hardcoding names on my LAN. Whenever a page for a cloaked domain is visited, an additional query for an HTTPS record is triggered.

For example, this is one of the entries in cloaking-rules.txt:

example.foo.bar 192.168.6.3

192.168.6.3 is a machine that exposes a server with Docker using the image assemblyline/ok. When the query logs are checked after visiting the page, the following entries are present:

[2022-10-07 19:42:38]	192.168.6.1	example.foo.bar	A	CLOAK	0ms	-
[2022-10-07 19:42:38]	192.168.6.1	example.foo.bar	HTTPS	NXDOMAIN	97ms	dnscrypt.eu-nl

The resolver will always return NXDOMAIN since the domain does not exist.

Is this an expected behaviour? According to the documentation (https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Cloaking), no queries are send to the DNS resolver. Should the same thing also happen to HTTPS records?

Interestingly enough, if one uses Firefox to visit the same page, it does not perform the lookup for the HTTPS record.

dnscrypt-proxy version: 2.1.2
Google Chrome version: 106.0.5249.103
Firefox version: 105.0.2

[ignoramous]

Looks like code changes may be needed:

dnscrypt-proxy/dnscrypt-proxy/plugin_cloak.go

Line 140 in df3fb0c

(question.Qtype != dns.TypeA && question.Qtype != dns.TypeAAAA && question.Qtype != dns.TypePTR) {

Interestingly enough, if one uses Firefox to visit the same page, it does not perform the lookup for the HTTPS record.

I don't think Firefox uses HTTPS/SVCB queries yet. Chrome and Safari do.

[TonyDC]

First of all, thanks for you reply!

---

I don't think Firefox uses HTTPS/SVCB queries yet. Chrome and Safari do.

Indeed, I can confirm the same behaviour is happening with Safari. Also, that explains why Firefox does not trigger the query.

---

Looks like code changes may be needed:

Do you think it makes sense to just return an empty response to HTTPS queries or to do something similar to what's being done with blocked AAAA queries? Here's an example:

;; ANSWER SECTION:
example.foo.bar.	86400	IN	HINFO	"HTTPS queries are not supported for cloaked entries by dnscrypt-proxy"

Or something else entirely?

[ignoramous]

Do you think it makes sense to just return an empty response to HTTPS queries or to do something similar to what's being done with blocked AAAA queries? Here's an example:

HTTPS/SVCB can have a number of records (it essentially is a list of key-value records) that may contain many different things (ECH parameters, IPv6 hints, service discovery etc). So emptying it outright may not be the "cleanest" thing to do... but since we are talking about black-holing traffic here, one can't argue against throwing away the entire HTTPS/SVCB response, anyway.

[jedisct1]

Yeah, that makes sense. In fact, when cloaking, we should probably return an empty response for anything that's not A or AAAA.

[ignoramous]

serverless-dns (which I co-develop) inherited this logic (of only blocking A, AAAA, CNAME) from dnscrypt-proxy ;) Though we did add HTTPS, SVCB a while back to it (code)... serverless-dns must in fact, as you point out, empty out all record types and not just these five.

[TonyDC]

we should probably return an empty response for anything that's not A or AAAA.

I believe that can be achieved by removing the condition pointed out by @ignoramous and let the code execute as usual:

dnscrypt-proxy/dnscrypt-proxy/plugin_cloak.go

Line 140 in df3fb0c

(question.Qtype != dns.TypeA && question.Qtype != dns.TypeAAAA && question.Qtype != dns.TypePTR) {

However, that can cause an interesting behaviour. In example-cloaking-rules.txt, there is this example:

www.youtube.com             restrictmoderate.youtube.com

With the current release, if the cloaking rules are activated, dnscrypt-proxy will cloak any A , AAAA or PTR queries for YouTube and keep the HTTPS ones untouched. If the aforementioned change is applied, any HTTPS queries will have an empty response, even though there's a HTTPS record. Is this the appropriate behaviour?

It seems there are two cases that are tried to be covered with cloaking rules:

• cloaking an existing domain name (e.g. Google, Bing, Youtube): the domain name that is being cloaked might contain extra records (other than A or AAAA) that (probably?) should be returned
• cloaking a non-existing domain name (e.g. example.com): since the domain is only valid within the context of dnscrypt-proxy, no recursive resolver will be able to successfully reply to the query

[Lanius-collaris]

When DoH is enabled, firefox also performs the lookup for HTTPS record.
Go to about:networking#dnslookuptool, type cloudflare.com, click "Resolve"

IPs

2606:4700::6810:84e5
2606:4700::6810:85e5
104.16.132.229
104.16.133.229

HTTP RRs

1 cloudflare.com (alpn="h3,h3-29,h2" ipv4hint="104.16.132.229, 104.16.133.229" ipv6hint="2606:4700::6810:84e5, 2606:4700::6810:85e5" )