Closed Bug 1590746 Opened 5 years ago Closed 2 years ago

ESNI doesn't work when we use DOH on the router (synology)

Categories

(Core :: Networking: HTTP, defect, P3)

72 Branch
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: athena, Unassigned)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

We activate esni in the browser, we do NOT enable DOH in the browser but on the router (synology router and other and other).

Restart the browser and/or the computer

Check if DNSSEC is fonctionnal response : yes
Check if dns over https is detected response : yes

Go to https://www.cloudflare.com/ssl/encrypted-sni/ and do the test

Actual results:

All green but esni red not work

Expected results:

All green esni too (since DOH and DNSSEC is enabled on the router)

(in previous version of firefox if we activated trr in shadow mode (only recuperate information and OS do the request) esni worked in this configuration).

Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Summary: Esni doesn't work when we use DOH on the router (synology) → ESNI doesn't work when we use DOH on the router (synology)

It looks like DNS lookup is done by the synology router, so I think this is not a Firefox issue? Or do I misunderstand something?
As far as I know, enabling trr is the only to make Firefox support ESNI.

Flags: needinfo?(athena)

It's a potential bug for Firefox because ESNI worked with this configuration (when shadow mode of TRR was functional).

Firefox must be able to run ESNI WITHOUT the TRR if it wants to continue to be used in the company, because companies filter the dns requests.
So ESNI not work with DOH on router it's a bit problem for Firefox.

Flags: needinfo?(athena)

(in previous version of firefox if we activated trr in shadow mode (only recuperate information and OS do the request) esni worked in this configuration).

You can try the https://mozilla.github.io/mozregression/ to find the regression range.

TRR shadow mode is removed in bug 1552438.

I'd like to set this to P3 for now. We are still working to roll out ESNI.

Priority: -- → P3
Whiteboard: [necko-triaged]

yes, I just wanted to draw attention to the possibility of companies that will use DOH on a router to filter the dns before the final release of the ESNI

Is this going to be handled with the new ECH work?

Severity: normal → S3

If companies want to filter DNS and so disable DoH, ECH doesn't provide any value, since the company can see the domains in the DNS Lookup. So I don't think this request makes sense. If I've misunderstood, please feel free to clarify.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX

I disagree. It's a perfectly valid case to deploy your own DoH server in your own network if you want to secure your DNS requests inside the network but don't trust any 3rd paty DoH provider.

Also, DoH is not the only method. Alternatives include DNSCrypt, DoT, DoQ (QUIC), DNS-over-Tor, SOCKS5, VPNs or just iterative resolve and cache DNS queries yourself. You can not make any assumption about the environment and thread model of users. IMHO it's a better choice to allow ECH anyway than assuming that someone may not benefit from it.

Flags: needinfo?(djackson)

Then it sounds like you're asking for OS Resolver support for ECH, i.e. bug 1500289.

Flags: needinfo?(djackson)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: