1852752 - [meta] Allow resolving HTTPS (or arbitrary record types) RR with native DNS (without TRR)

Status: NEW

(Core :: Networking: DNS, task, P3)

Description

[Valentin Gosu [:valentin]]

Considering how useful HTTPS records are, and that a lot of users don't have DoH enabled, we want to allow resolving HTTPS records with the native resolver.

Comment 1

[Valentin Gosu [:valentin]]

Windows

On all platforms, we use getaddrinfo to resolve A and AAAA requests, but on Windows we also use DnsQuery_A to perform a second DNS resolution in order to get the TTL of the DNS record.
This same DNS_QueryA method can be used to resolve HTTPS records on windows
Linux

res_nquery
https://man7.org/linux/man-pages/man3/resolver.3.html

OSX

res_query
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/res_query.3.html

Android

Theoretically we should be able to use the same linux implementation for Android too. However, as a follow-up we may want to look into using the available Android (Java) DNS APIs as we've determined that getaddrinfo sometimes hangs for an unexpected amount of time, so we need to check if that's also the case for this function as well.

Comment 2

[Thayne]

Another possibility at least on unix is the ldns library.

And on linux when systemd-resolved is used, then the org.freedesktop.resolve1 dbus api could be used.

Comment 3

[Ben Bucksch (:BenB)]

With "HTTPS records", I assume you mean RFC 9460 https://www.rfc-editor.org/rfc/rfc9460.html ?

On Linux, it's difficult to depend on certain applications (like systemd or a commandline app) to be installed. "Linux Standard Base" (LSB) might be a helpful starting point.

• https://www.wikiwand.com/en/Linux_Standard_Base
• https://refspecs.linuxfoundation.org/lsb.shtml

Comment 4

[Thayne]

With "HTTPS records", I assume you mean RFC 9460

Yes.

On Linux, it's difficult to depend on certain applications (like systemd or a commandline app) to be installed

Well, what I was envisioning is that at runtime firefox would detect if the org.freedesktop.resolv1 dbus interface is available, and if it is, use that, and if not fall back to something else. Although, I suppose that would probably add some complexity, and would still need something to fall back to.

Comment 5

[Valentin Gosu [:valentin]]

This feature will be riding the trains in Firefox 127 - see bug 1890999.

Comment 6

[uk.damien]

Is network.dns.native_https_query intended to be true by default as of Firefox 127? (MacOSX)

That appears to be the intent behind bug 1890999 but that's not my current experience. (Setting is present, but is false)

Can you confirm if it's intended to be enabled by default, or just rolled out as an experimental feature for now?

Comment 7

[Emanuel Czirai]

I'd just like to note that some people using dnsmasq (2.90) may or may not need to use --cache-rr=ANY (or --cache-rr=HTTPS ? untried) to have those [HTTPS] dns queries cached and not forwarded to upstream DNS servers, or of course set network.dns.native_https_query to false to not issue them at all.

Was true for me on Gentoo(I put cache-rr=ANY in /etc/dnsmasq.conf manually, else only [A] and [AAAA] were cached), but maybe I changed some defaults(unsure) since the first dnsmasq install(years ago), certainly not true for all people like those using Pi-hole, as per: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2023q4/017363.html

For me it was kinda spammy, even 2 requests per second on ideogram.ai website, that is, two sets of these (per sec):

Aug 13 17:38:45 dnsmasq[26811]: 524 127.0.0.1/42603 query[HTTPS] ideogram.ai from 127.0.0.1
Aug 13 17:38:45 dnsmasq[26811]: 524 127.0.0.1/42603 forwarded ideogram.ai to 45.90.30.0
Aug 13 17:38:45 dnsmasq[26811]: 524 127.0.0.1/42603 reply ideogram.ai is <HTTPS>