Re:1.1.1.1: Fast, privacy-first consumer DNS service
by chimera77 on Sunday April 01, 2018 @11:21AM
(#16728709)
One of the use cases for DNS-over-HTTPS given in the draft was to allow web applications access to DNS directly via existing browser APIs.
[ Parent
| on HN ]
Re:1.1.1.1: Fast, privacy-first consumer DNS service
by ori_b on Sunday April 01, 2018 @06:48PM
(#16730969)
I've implemented DNS before. Doing this saves an entire 300 lines of code. At the same time, it makes the DNS server much more complicated. On top of that, implementing a compliant posix libc will now either use a completely different code path, or pull in a huge amount of code to implement HTTP, HTTP/2, and QUIC. If the simpler, cleaner, and more performant route is taken, it willgbreak when someone screws up "legacy" dns without noticing, because it works in the browser.
It's not worth the complexity of multiple protocols that do the same thing. And it's not worth making the base system insanely complicated so that the magic 4 letters 'http' can show up.
TLS? Yeah, since the simpler secure DNSes failed, we might as well use that. But let's try to keep http complexity contained.
Re:1.1.1.1: Fast, privacy-first consumer DNS service
by azinman2 on Sunday April 01, 2018 @12:42PM
(#16729151)
Ok that’s actually pretty cool.
Re:1.1.1.1: Fast, privacy-first consumer DNS service
by codetrotter on Sunday April 01, 2018 @01:55PM
(#16729540)
Wonder if this will pave the way for other protocols over HTTPS.
Re:1.1.1.1: Fast, privacy-first consumer DNS service
by gsich on Sunday April 01, 2018 @05:03PM
(#16730413)
Hopefully not. One needs to stop working around crappy setups from crappy networks. Which X-over-HTTPS really is all about.
Re:1.1.1.1: Fast, privacy-first consumer DNS service
by 18pfsmt on Tuesday April 03, 2018 @04:16PM
(#16748664)
It seems like crappy networks are the norm nowadays, and the preference of the ISPs is to offer the web only. You need a middle box just to access the internet at-large (e.g Tor). Masquerading traffic as web traffic appears to be a good tactic, though inefficient/sloppy.