1869075 - Firefox doesn't follow RFC9460 HTTPS AliasMode TargetName

Status: NEW

(Core :: Networking: DNS, defect, P2)

Description

[Jan Schaumann]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

Firefox does not appear to honor or follow through to a TargetName if the DNS RFC9460 HTTPS record for a domain name is in AliasMode.

E.g., try to visit alias-mode.https.dotwtf.wtf:

$ dig +short https alias-mode.https.dotwtf.wtf
0 www.dotwtf.wtf.
$

Actual results:

Firefox correctly performs the HTTPS record lookup, together with A and AAAA records for the name, but does not perform a lookup of the TargetName and instead yields an error:

Firefox can’t protect your request for this site’s address through our trusted DNS resolver. Here’s why:
This website wasn’t found by mozilla.cloudflare-dns.com.

yielding TRR_NO_ANSWERS:
https://firefox-source-docs.mozilla.org/networking/dns/trr-skip-reasons.html#trr-no-answers

Expected results:

Firefox should have understood the AliasMode and continued with a lookup of 'www.dotwtf.wtf', which would have yielded IP addresses to connect to.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Valentin Gosu [:valentin] (he/him)]

So the problem is that we don't get any response to the A and AAAA requests to alias-mode.https.dotwtf.wtf
We do follow the HTTPS alias mode, but only for the HTTPS request.
I'm not sure what the RFC says we should do instead, but I'm not convinced this is a bug.

Comment 3

[Kal]

I believe this is not the correct interpretation of the RFC. If a client encounters an AliasMode record then it needs to resolve the TargetName, including the TargetName's A/AAAA records if TargetName does not have SVCB records. Section 3 of the RFC (https://www.rfc-editor.org/rfc/rfc9460.html#name-client-behavior) covers this although the wording is tough to read IMO.
Attempting to include A/AAAA records from the same owner label within the client's resolution logic is incorrect and may result in interoperability issues. This is the distinction between ServiceMode and AliasMode, which appears to have been conflated in current Firefox behaviour.
I recommend following the RFC for AliasMode or explicitly disabling AliasMode so as to avoid confusion.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Should this remain in Next? Is the reporter's comment about the spec correct?

Comment 5

[Erik]

This does sound like a bug. The client (Firefox) is free to resolve A/AAAA records in-parallel with the HTTPS records both as an optimization and also as a fallback. But if the A/AAAA records aren't present for the initial name and it only has HTTPS RRs (either AliasMode or ServiceMode with a TargetName to a name that does have A/AAAA records) then that the HTTPS RR should be used.

What is not allowed is mix-and-match of A/AAAA records with an HTTPS RR without the HTTPS RR explicitly referencing the name with the A/AAAA records via a TargetName.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Valentin, is this a reasonable points/rank? Thanks

Comment 8

[Valentin Gosu [:valentin] (he/him)]

Seems about right. This is something I may take on in the near future as I've had multiple people requesting it.

Comment 9

[Dusk Banks [:bb010g]]

I believe this blocks Bug 1634793 (httpssvc).