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.
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
- 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.
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")
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.
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.