5 ms·
I wonder if the best approach might be to specify the precise request format required for DoH and actively deny requests with extra information. 'Thou shalt pr
by desc 7y ago
I wonder if the best approach might be to specify the precise request format required for DoH and actively deny requests with extra information.
'Thou shalt provide exactly this, no more and no less'
Depends on whether we want to consider later 'improvements' to be silent extensions or an entirely new protocol version. Given how easily abused HTTP headers have been in the past, might be worth the inertia to limit extensibility by design in order to limit MITM tracking.
But MITM middleboxes will of course start to rely on that...
I suppose that if TLS is broken for this part of the system you're rather screwed anyway, but defence in depth is always worth considering.
- anoncake 7y agoWhat's the point of using HTTP for DNS if you aren't going to use its abilities?
- mantap 7y agoThe point, iirc is to run it on port 443 so that it doesn't get blocked.
- anoncake 7y agoThat would explain DNS over TLS on port 443, no HTTP needed.
- anticensor 7y agoYes but initial hanshakes would look foreign compared to regular port 443 traffic.
- CiPHPerCoder 7y agoTo stop people from blocking DNS over HTTPS.
- Someone1234 7y agoIts raison d'être is largely to mitigate the issues that limited DoT's (DNS over TLS) widespread adoption, specifically "Middlebox Bypass." Meaning if you connect to a public WiFi network, many will only allow captive DNS and block other protocols including DoT. DoH is difficult to distinguish from other HTTPS traffic and is more likely to successfully resolve (since they cannot block HTTPS and still be useful). Therefore you've created a secure, flexible, and reliable DNS replacement with only mild technical downsides on modern hardware (a lot of the complaints are ideological or relate to specific incompatibilities with existing solutions like the lack of HOSTS file support in the initial offerings). So I guess, everything I just said is "the point." Rather than trying to use every single possible combination of HTTP headers.
- ocdtrekkie 7y agoDoH as a protocol has no issues with HOSTS files. The issue is browsers implementing DoH instead of operating systems. If browsers stayed in their lane, and let operating systems implement DoH, compliant with corporate IT design and systems like the HOSTS file, everything would be fine. Microsoft has already committed to implement DoH in Windows itself. Browsers just need to stop trying to be their own DNS clients.
- PenguinCoder 7y agoSpot on. This needs to be supported and implemented at the OS layer, not the application
- baroffoos 7y agoOSs didn't implement it though. And they never would unless browsers forced it on them. The right approach is for browsers to bring it in and then when the OS supports it, default to the OS version. But right now I don't know of any OS other than I think android that supports it.
- PenguinCoder 7y ago
- em-bee 7y agothe user-agent header was a mistake from the very beginning. it was meant to help servers cater to different browser capabilities, but it ended up being misused to segregate the net and drive non-standard features. without the user-agent header, browsers would have been forced to standardize earlier.
- pg_is_a_butt 7y ago> without the user-agent header, browsers would have been forced to standardize earlier. Or, we'd all still be using WorldWideWeb 1.0