Closed
Bug 1648147
Opened 4 years ago
Closed 4 years ago
Maybe don't RES_DISABLE_TRR when the TRR server returns 0.0.0.0
Categories
(Core :: Networking, task, P2)
Core
Networking
Tracking
()
RESOLVED
FIXED
83 Branch
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: valentin, Assigned: valentin)
References
(Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged][trr])
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Peter Saint-Andre:
According to https://wiki.mozilla.org/Trusted_Recursive_Resolver#network.trr.mode, mode 2 should fallback "if the name resolve fails", which one would assume means a timeout or a SERVFAIL?It seems to currently fallback when the answer is 0.0.0.0 or :: (used by blocking resolvers). This seems counter-intuitive as this is not a failure, especially when the user manually chose to set a blocking resolver as DNS (malware, privacy or parental control).
I think what happens here is that we accept the IP, try to connect, it fails, so for following connections we don't use TRR because it previously failed
Assignee | ||
Comment 1•4 years ago
|
||
Pushed by valentin.gosu@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/33538d2ae096
Don't retry the connection with RES_DISABLE_TRR when the TRR server returns 0.0.0.0 r=dragana,necko-reviewers
Comment 3•4 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox83:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•