The point presented by the post is plain wrong, people were using non-ISP recursors for a long time already and this was not problem due to the fact that EDNS Client Subnet has been a thing for a while now.
The problem mentioned in the post is specific to Cloudflare, as they do not support EDNS Client Subnet anyway, even over plain UDP53
First results: https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-... "The results were strong! Like our previous studies, DoH had minimal impact or clearly improved the total time it takes to get a response from the resolver and fetch a web page."
That's valid, but it's also why HTTP/3 is being pushed for 1-RTT and 0-RTT connections (0-RTT is most likely going to be enabled for their DoH if it isn't already)
The DoH server gets to track users if they use a resumption method, yes. As I understand it Firefox puts extra work in to ensure that it doesn't share the backend cache between your HTTPS service and the DNS resolver so there's no risk that if the DNS service and the HTTPS site you're visiting are owned by the same people they can correlate that, but they would be able to see that it's the same browser asking for say, camelporn.example and visit-arabia.example
If you disabled resumption you could get rid of this issue at a cost of one extra round trip per DNS lookup.
Nobody else gets to track users this way (at least in TLS 1.3 and I'd assume DoH implementers will use TLS 1.3 since they are of similar vintage) because the keys aren't re-used so the identifier for the key will just appear to be random noise each time.
That is resumption. So you still have the overhead for the first connection. Assuming that you don't DNS query every few seconds you are gonna suffer.
On a side note, last I checked Quad9 and Cloudflare (need to recheck that) almost immediateley close the connection once you finished your query. Tested with DoT but the same TLS handshake is required for that.
I think you're confused. You're correct that the first connection is 1-RTT but the resumption is a new connection and is 0-RTT using a resumption PSK.
Let's say your browser was left open when you went to work, you get home, click the bookmark for your preferred porn site, and now the browser needs to resolve the FQDN for that site. How fast is that?
So if you have TCP fast open and 0-RTT TLS 1.3 that's exactly one round trip for your answer, just like traditional unencrypted DNS.
The DNS query gets wrapped as an HTTP request, which gets wrapped as a TLS plaintext, which gets sent as TLS 1.3 early data, which all goes in the Fast Open TCP packet.
The server checks the Fast Open cookie, opens the TCP connection, matches the PSK, unwraps the early data, unwraps the HTTP request, unwraps the DNS query
The server finishes the TLS handshake on the now open TCP connection, and using the now encrypted channel it sends back the HTTP response, which wraps a DNS answer and that goes back as the first TCP packet the other way.
Same number of round trips and packets as for DNS. It's very ugly and QUIC in particular will tidy this up considerably, but it's secure and fast.
But the original post makes not mention of anything other than non-optimal answers.
Before comparing various methods of contacting a recursor you have to decide what your threat model is; does it include your ISP snooping on you? If so then an encrypted transport of your dns queries is mandatory. If it doesn’t, stick with DNS53.
DoH can use UDP, but most dont, Also most people's local DNS (Here in America) Provided by their ISP is pretty shit. In my experience working at a MSP, having a local DNS server is always best
- Opaque and uncommon/needlessly-unfamiliar command-line management toolkit (seriously, what is so difficult about 'output text, receive text as input' in 2017?)
- I cannot, yet, fully manage a Microsoft host from the CLI. What I consider to be 'fully managed' revolves around: installing software, updating software, adding/removing/'managing' users, setting up basic server-like features such as simple firewall rules, viewing common log-files ('user X logged in', 'software Y tried to execute Z task, the result was A'), starting/stopping/troubleshooting daemons, etc
^^^ Solved by PowerShell (You can even install a GUI-less version of WS2016 and all these will work.)
- Pick a major config-management system (my direct experience is with Puppet/Chef/Ansible/Salt). Configuring them to play nice with Windows-anything is an order of magnitude more difficult than even the most baroque *nix-like operating system.
^^^ I use Ansible Tower to manage a mixed WS and Linux fleet with great success, I only need to run `kinit` once every day to obtain a ticket, all logins afterwards are passwordless.
Exactly that, we too suffered a power loss at our DC that was due to faults in the power supervising and switch-over circuits; we test both generators weekly.
How quickly can one build and how quickly can it scale ? - Speed is the name of the game - is it not this rule which holds true when building things on internet.
Or else, most of top internet apps are just going to be php,rails,node web-apps
The compiler can do it within the compilation unit, randomizing the order of the blocks and globals.
The basic linker just quickly concatenates compilation units, but randomizes the order that it concatenates the units and randomizing the GOT and PLT order.
A link-time-optimizing linker can actually randomize the order of the blocks and globals and the compiler wouldn't need to be involved.
On the Mill CPU project we plan to randomize the order of everything each time we 'specialize'; kernels and user-space will have randomized GOT and block order on every installation, and it also helps smoke out bugs :)
You may wish to look into the workable form, the 'Were you referred by a Gitlab employee' field is marked as mandatory.
(It kept throwing "can't be blank")
Hey There! Thanks for the note! We do wish that field to be mandatory, but we can definitely add "if not please insert N/A" Thanks so much for the heads up on that and glad to see you've applied :D
hamishtaplin; unfortunately coverage is not fully global yet; I think we have about 372 cities in there at the moment. This draws from Numbeo.com's data set on rent indices. But if your city is not listed, our default solution is the following "If you live outside a metro region we base our offer upon the lowest rent index number of any metro region in your country (or state, in the case of the USA), if your country is listed"
The problem with opportunistic TLS is that while it protects from wide-scale DPI it doesn't protect against MITM. Personally I think that the effort that would be put to implementing opportunistic TLS in all web servers and browsers would be better put to migrating all web applications to HTTPS only.
The problem mentioned in the post is specific to Cloudflare, as they do not support EDNS Client Subnet anyway, even over plain UDP53
more reading: https://www.samknows.com/blog/dns-over-https-performance