logincdn.msauth.net fails to resolve if network.trr.mode=3
Categories
(Core :: Networking: DNS, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox78 | --- | fixed |
People
(Reporter: kevin, Assigned: valentin)
References
()
Details
(Whiteboard: [necko-triaged][trr])
Attachments
(4 files)
Using Firefox 75.0 on Debian x64, Nightly 78.0a1 (2020-05-05) on Debian x64, and Nightly 78.0a1 (2020-05-05) on Windows 10.0.18363, with network.trr.mode=3 (with or without network.trr.bootstrapAddress=104.16.249.249) in about:config, attempting to visit any https://logincdn.msauth.net/ URL (used by Microsoft SSO) fails with "We can’t connect to the server at logincdn.msauth.net". On about:networking#dnslookuptool domain logincdn.msauth.net shows NS_ERROR_UNKNOWN_HOST.
curl --doh-url https://mozilla.cloudflare-dns.com/dns-query https://logincdn.msauth.net/ works. https://dohjs.org/ shows a response for A logincdn.msauth.net using https://mozilla.cloudflare-dns.com/dns-query with the following chain:
logincdn.msauth.net IN CNAME lgincdn.trafficmanager.net
lgincdn.trafficmanager.net IN CNAME lgincdnmsftuswe2.azureedge.net
lgincdnmsftuswe2.azureedge.net IN CNAME lgincdnmsftuswe2.afd.azureedge.net
lgincdnmsftuswe2.afd.azureedge.net IN CNAME afd.t-0001.t-msedge.net
afd.t-0001.t-msedge.net IN CNAME t-0001.t-msedge.net
t-0001.t-msedge.net IN CNAME Edge-Prod-WSTr3.ctrl.t-0001.t-msedge.net
Edge-Prod-WSTr3.ctrl.t-0001.t-msedge.net IN CNAME standard.t-0001.t-msedge.net
standard.t-0001.t-msedge.net IN A 13.107.246.10
From the log (attached) it appears that Firefox was only able to follow the response up to Edge-Prod-WSTr3.ctrl.t-0001.t-msedge.net before failing. (But I could be misreading it.)
|
Assignee | |
Comment 2•5 years ago
|
||
Hi,
Thanks for the report and the excellent logs.
It does seem to indicate a bug in Firefox; kinda.
So, when Firefox follows the CNAME chain, it requests the domain with capital letters, as encountered in the chain, but the response is lower-cased, so we ignore it because it doesn't match what we requested.
2020-05-05 20:32:46.694619 UTC - [Parent 1490133: TRR Background]: D/nsHostResolver TRR asked for Edge-Prod-WSTr3.ctrl.t-0001.t-msedge.net data but got edge-prod-wstr3.ctrl.t-0001.t-msedge.net
I guess we should normalize the domain at some point.
|
Reporter | |
Comment 3•5 years ago
|
||
Thanks Valentin! Good catch. Very interesting.
For reference, the DoH response shown by dohjs has consistent capitalization, so it may be getting normalized to lower-case somewhere in the code.
I also took a peek at glibc to see what it's doing. Looks like all CNAME matching is done with strcasecmp (most via ns_samename): https://sourceware.org/git/?p=glibc.git;a=blob;f=resolv/ns_samedomain.c;h=5d1bf39fc7#l190
|
|
Assignee | |
Comment 4•5 years ago
|
||
|
|
Assignee | |
Comment 5•5 years ago
|
||
Depends on D75078
|
|
Assignee | |
Comment 6•5 years ago
|
||
This is according to RFC 4343 : Domain Name System (DNS) Case Insensitivity Clarification
Depends on D75079
|
||
Comment 8•5 years ago
|
||
Backed out 3 changesets (bug 1635566) for XPCShell in netwerk/test/unit/test_trr_case_sensitivity.js. CLOSED TREE
Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=302313767&repo=autoland&lineNumber=2755
Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=873f7e079fd85c95cc50c6e755d4efbf8ab3d31e
Backout:
https://hg.mozilla.org/integration/autoland/rev/27e67cf0100024d4c07c2556073550093d9f480e
|
||
Comment 10•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/24e4d55fdbb8
https://hg.mozilla.org/mozilla-central/rev/c04bd90516d5
https://hg.mozilla.org/mozilla-central/rev/84dceb22a31d
|
|
Assignee | |
Updated•5 years ago
|
|
|
Reporter | |
Comment 11•5 years ago
|
||
I can confirm that the issue appears to be fixed on the latest nightly (78.0a1 2020-05-27). Thank you!
Is the fix likely to be applied to 77 or 68ESR?
If it makes a difference for prioritization, there are other affected microsoft.com subdomains (e.g. https://dotnet.microsoft.com/platform/support/policy).
|
|
Assignee | |
Comment 12•5 years ago
|
||
(In reply to Kevin Locke from comment #11)
I can confirm that the issue appears to be fixed on the latest nightly (78.0a1 2020-05-27). Thank you!
Is the fix likely to be applied to 77 or 68ESR?
If it makes a difference for prioritization, there are other affected microsoft.com subdomains (e.g. https://dotnet.microsoft.com/platform/support/policy).
Most likely not going to be uplifted.
ESR68 has other issues.
77 will hit release in one week, so there's not enough time for testing if we do uplift.
|
|
Reporter | |
Comment 13•5 years ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #12)
Most likely not going to be uplifted.
Oh well. Thanks for the info. (And the fix!) I'll look forward to it in 78.
Description
•