1893944 - Resolving any .local domain takes at least 10 seconds

Status: RESOLVED FIXED

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

Description

[Àlex Fiestas]

Attachment: log.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:127.0) Gecko/20100101 Firefox/127.0

Steps to reproduce:

Access any .local sites such as homeassistant.local

Actual results:

The browser tab will be in a loading state for 10 seconds, afterwards the site will load instantly.

Expected results:

The site should load fast since the .local domain resolves almost instantly when queried for A/AAA records.

I've done some digging, attached you can find the log with the Network preset + GetAddrInfo.

It seems that the tab is stuck at loading while TYPE65 record is looked up.

2024-04-29 07:31:52.73349 starts the TYPE65 dns record
10 seconds afterwards
2024-04-29 07:32:02.740798 the lookup finishes with a fail status

It might be technically possible to have HTTPS records in mdns but as far as I know it is not widely used.

Perhaps .local domains should be skipped from TYPE65 lookups or perhaps firefox should load the site the moment either A or TYPE65 lookup is obtained.

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

[Kershaw Chang [:kershaw]]

I think we have some options here:

1. Don't force transaction to wait for the result of HTTPS record.
2. Use a shorter timeout for HTTPS RR lookup.
3. Don't resolve HTTPS RR for some domains, e.g., *.local, DNS suffix list, etc/hosts.
4. Use NetworkConnectivityService to check if HTTPS RR is available. If not, turn it off.

Valentin, what do you think?
Thanks.

Comment 3

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

(In reply to Kershaw Chang [:kershaw] from comment #2)

I think we have some options here:

1. Don't force transaction to wait for the result of HTTPS record.
2. Use a shorter timeout for HTTPS RR lookup.
3. Don't resolve HTTPS RR for some domains, e.g., *.local, DNS suffix list, etc/hosts.
4. Use NetworkConnectivityService to check if HTTPS RR is available. If not, turn it off.

I think what we need is a combination of all these things.
3 and 4 are something we should do right away. From talking to djackson, we don't need to wait for the HTTPS record when using native DNS, since the domain name is advertised to the network - so we should only wait for it when using TRR (on the other hand, it would mean we wouldn't always use HTTP/3).
Regarding 2 - the timeouts are enforced at the OS level - though we could also add one at the level of the DNS service, so the performance profile is closer to what we see with TRR.

I see the priority of our options as 3, 4, 1 then 2 (maybe)

Comment 4

[Àlex Fiestas]

Just in case somebody else is affected (my understanding is that only nightly users are)

network.dns.native_https_query is the toggle to turn off until the related bugs are fixed (as seen in https://bugzilla.mozilla.org/show_bug.cgi?id=1893970).

Thanks for the quick response and let me know if I can be of more help.

Comment 5

[Kershaw Chang [:kershaw]]

Attachment: Bug 1893944 - Don't resolve HTTPS RR for local domains, r=#necko

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ab3e5537929a
Don't resolve HTTPS RR for local domains, r=necko-reviewers,jesup

Comment 8

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/ab3e5537929a