Windows will improve user privacy with DNS over HTTPS

[Tommy Jensen (tojens)]

Brought to you by Tommy Jensen, Ivan Pashov, and Gabriel Montenegro

Here in Windows Core Networking, we’re interested in keeping your traffic as private as possible, as well as fast and reliable. While there are many ways we can and do approach user privacy on the wire, today we’d like to talk about encrypted DNS. Why? Basically, because supporting encrypted DNS queries in Windows will close one of the last remaining plain-text domain name transmissions in common web traffic.

Providing encrypted DNS support without breaking existing Windows device admin configuration won't be easy. However, at Microsoft we believe that "we have to treat privacy as a human right. We have to have end-to-end cybersecurity built into technology."

We also believe Windows adoption of encrypted DNS will help make the overall Internet ecosystem healthier. There is an assumption by many that DNS encryption requires DNS centralization. This is only true if encrypted DNS adoption isn’t universal. To keep the DNS decentralized, it will be important for client operating systems (such as Windows) and Internet service providers alike to widely adopt encrypted DNS.

With the decision made to build support for encrypted DNS, the next step is to figure out what kind of DNS encryption Windows will support and how it will be configured. Here are our team's guiding principles on making those decisions:

• Windows DNS needs to be as private and functional as possible by default without the need for user or admin configuration because Windows DNS traffic represents a snapshot of the user’s browsing history. To Windows users, this means their experience will be made as private as possible by Windows out of the box. For Microsoft, this means we will look for opportunities to encrypt Windows DNS traffic without changing the configured DNS resolvers set by users and system administrators.
• Privacy-minded Windows users and administrators need to be guided to DNS settings even if they don't know what DNS is yet. Many users are interested in controlling their privacy and go looking for privacy-centric settings such as app permissions to camera and location but may not be aware of or know about DNS settings or understand why they matter and may not look for them in the device settings.
• Windows users and administrators need to be able to improve their DNS configuration with as few simple actions as possible. We must ensure we don't require specialized knowledge or effort on the part of Windows users to benefit from encrypted DNS. Enterprise policies and UI actions alike should be something you only have to do once rather than need to maintain.
• Windows users and administrators need to explicitly allow fallback from encrypted DNS once configured. Once Windows has been configured to use encrypted DNS, if it gets no other instructions from Windows users or administrators, it should assume falling back to unencrypted DNS is forbidden.

Based on these principles, we are making plans to adopt DNS over HTTPS (or DoH) in the Windows DNS client. As a platform, Windows Core Networking seeks to enable users to use whatever protocols they need, so we’re open to having other options such as DNS over TLS (DoT) in the future. For now, we're prioritizing DoH support as the most likely to provide immediate value to everyone. For example, DoH allows us to reuse our existing HTTPS infrastructure.

For our first milestone, we'll start with a simple change: use DoH for DNS servers Windows is already configured to use. There are now several public DNS servers that support DoH, and if a Windows user or device admin configures one of them today, Windows will just use classic DNS (without encryption) to that server. However, since these servers and their DoH configurations are well known, Windows can automatically upgrade to DoH while using the same server. We feel this milestone has the following benefits:

• We will not be making any changes to which DNS server Windows was configured to use by the user or network. Today, users and admins decide what DNS server to use by picking the network they join or specifying the server directly; this milestone won’t change anything about that. Many people use ISP or public DNS content filtering to do things like block offensive websites. Silently changing the DNS servers trusted to do Windows resolutions could inadvertently bypass these controls and frustrate our users. We believe device administrators have the right to control where their DNS traffic goes.
• Many users and applications that want privacy will start getting the benefits without having to know about DNS. In line with principle 1, the DNS queries become more private with no action from either apps or users. When both endpoints support encryption, there’s no reason to wait around for permission to use encryption!
• We can start seeing the challenges in enforcing the line on preferring resolution failure to unencrypted fallback. In line with principle 4, this DoH use will be enforced so that a server confirmed by Windows to support DoH will not be consulted via classic DNS. If this preference for privacy over functionality causes any disruption in common web scenarios, we’ll find out early.

In future milestones, we'll need to create more privacy-friendly ways for our users to discover their DNS settings in Windows as well as make those settings DoH-aware. This will give users, device admins, and enterprise admins the ability to configure DoH servers explicitly. 

Why announce our intentions in advance of DoH being available to Windows Insiders? With encrypted DNS gaining more attention, we felt it was important to make our intentions clear as early as possible. We don’t want our customers wondering if their trusted platform will adopt modern privacy standards or not.

If you are interested in joining the larger industry conversation about encrypting the DNS, check out one of the IETF working groups working with DNS (ABCD, Apps Doing DNS, DNSOP, DPRIVE) or the new Encrypted DNS Deployment Initiative.

Do you have questions or feedback for us regarding the Windows plan to adopt encrypted DNS? We’d love to hear from you! Feel free to comment below.

[NetAssurity]

DoH is a good start. We will wait for DoT as its a better route.

[j0hnj0nes]

Please Support DNSSEC 

(you only support it in the server deployed on site and it needs to be on the client, office365 and azure)

this can be done regardless of DoH or DoT it verifies the answers are correct 

Microsoft documentation:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn...

administrators requesting this for office365:

https://office365.uservoice.com/forums/289138-office-365-security-compliance/suggestions/32360299-dn...

azure networking request :

https://feedback.azure.com/forums/217313-networking/suggestions/13284393-azure-dns-needs-dnssec-supp...

please Tommy Jensen, Ivan Pashov, and Gabriel Montenegro. trust but verify  

microsoft windows platform deserves better, windows 10 needs DNSSEC  

[Joseph Zollo]

Do your future plans include allowing Windows DNS Server to communicate to upstream DNS servers using DNS over HTTPS/TLS?

Internally you'd have clients making unencrypted DNS queries to their local DNS server (53), then said DNS server would forward queries upstream - over HTTPS/TLS (443). Or - even better, allowing Windows DNS Server to answer queries over HTTPS for a true end-to-end encrypted flow.

Also, echoing the need for DNSSEC on Windows Client!

[cpuprohky]

I'll be the stick in the mud here.

We don't only need DOT and DOH, we need granular control over what is and what is not allowed through those DNS servers, or our clients are going to be inundated by new forms of malware, spyware, etc from advertisers and hacking groups who simply buy a SSL cert for .00000001 bitcoins, and flood the "secure" DNS with the same intrusive ads and garbage that make the internet a virtual nightmare of scams, garbage and malicious links.  

[wolrah]

@cpuprohky you seem to have a serious misunderstanding of what DNS-over-HTTPS is and what is happening here.  This change will not override your own manually configured local DNS servers, it will only matter if a client is configured to use a well-known DNS server that support DoH, for example Cloudflare's 1.1.1.1 or Google's 8.8.8.8.  Clients configured to use those or other similar public DNS servers will be automatically upgraded to DoH, those set to private servers or public services not known to support DoH will not be changed.

Also, if you want to run your own DNS server that monitors and/or modifies traffic you can still do so with DoH.  It's just a different protocol between the client and the chosen resolver, everything else works the same as it always has.

The only thing this actually affects is transparently intercepting DNS traffic and redirecting it to somewhere the client did not want.  Protecting against this is a good thing.  Those who legitimately control the machines they're monitoring can configure them appropriately for their needs rather than relying on dirty tricks.

It won't change a thing as far as malware or ads are concerned.

[cpuprohky]

https://www.reddit.com/r/pihole/comments/dy4b3b/windows_will_improve_user_privacy_with_dns_over/

How does this impact the use of a PiHole? Do you lose some control on some closed source devices?

If a device or computer is using DNS over HTTPS, their DNS lookups will look like regular HTTPS requests, so they won't even hit the pihole at all.

It will be a 'good' way for systems to bypass ad filters or tracking filters like the pihole.

As long as you point devices you control to the pihole as a dns server then the endpoint will still be there, right?

This will be a problem for devices like the chrome cast that have servers hard coded and don't allow the end user to modify them.

Not necessarily. If the device or computer or the browser, for example, are configured to use DNS over HTTPS then your pihole is completely out of the loop. Some will allow you to turn off DoH (for now) but some won't.

[Polymathic]

There is guidance up now on the PiHole site for the integration of the "cloudflared" service on a PiHole. 

I am interested in seeing the low-level flow of the nameserver selection logic. It sounds like MS is making some reasonable choices with respect to not arbitrarily undoing user configurations for client nameservers.  That having been said, the interoperability is in the details. 

[alexatkinuk]

@cpuprohkyYou are correct that something like a Chromecast where you might by redirecting DNS traffic via your router to the PiHole would no longer be possible.

The thing is though, Google could do this today as Google DNS already supports DoH and Chromecast has nothing to do with Windows.  So I'm not sure why you are posting about it on here as its nothing to do with what Microsoft are doing.

[GLaDOS]

Hello,

I agree that privacy is something that is VERY important, especially in our modern age.  However Privacy from our ISP is nice, but Microsoft still has their own tracking in windows, As I (and others) have asked for in many places, PLEASE LET US DISABLE ALL MICROSOFT SPYWARE, AND CRAPWARE IN WINDOWS 10.  

As for @cpuprohky, good point, and @alexatkinuk  Pihole is a DNS server based adblocker, and this article is directly about DNS. as for Chromecast, people like ME, use Google Chromecasts with our windows PC's.  As DNS is one of the backbones of the Internet, It does directly effect the use of devices like PiHole and Chromecasts, furthermore it effects anything that needs to resolve a name to IP.  As your statement indicates a lack of knowledge on what DNS is, and how the internet works, I would advice studying the topic.  If you would like, I can provide the names of some good resources.

Now to answer @cpuprojky's question:

as for PiHole, It already supports DNS over HTTPS, below is a link from PiHole explaining how to set it up.

https://docs.pi-hole.net/guides/dns-over-https/

Chromecast's should not be affected (depending on what your doing) As screen casting is a intranet matter, and video streaming the chromecast connects to it's own DNS servers, (your computer functions only as the remote, the device works 'mostly' on it's own).

[alexatkinuk]

@GLaDOSI think it may be you who doesn't understand the potential issues with DoH.

With normal DNS we can easily redirect it at the router by catching all outgoing traffic on the DNS port and sending it to our PiHole.

With DoH, we would need a rule that catches the actual IP addresses of every single possible DoH server our clients might hit, as its indistinguishable from normal HTTPS traffic so cannot be simply redirected by port.  Either that or we'd need to redirect all HTTPS traffic via a proxy server and spoof it there somehow.  This would have the annoying drawback of having ALL HTTPS traffic going via the proxy, needing much beefier hardware and potential for problems occuring.

[Dave_Champagne]

I don't consider DoH or DoT an upgrade as this is just a brand new attack vector for attackers that will be able to hide their DNS traffic from the prying eyes of enterprise security.

[alexatkinuk]

I somewhat agree, as the way I use it at home is to catch all DNS traffic at the router, forcing it to use my local DNS cache which THEN uses DoT to perform uncached lookups with Cloudflare.

If the clients bypass this, they are exposed to all the security risks I'm blocking at the firewall.

Plus how do you handle Intranet DNS lookups?  Will this be something you can suddenly only do with Windows Enterprise editions?

[GPARRA650]

People complaining that this will allow uses to bypass a DNS router forwarding to a PiHole are a little bit too naive... I would never trust a solution that implies the users are clueless and only use Windows.

With this, Microsoft is just making it easier for users to have DNS security with OS support DoH but users can already do this anyway in many multiple ways: it is quite easy to install a DNS forwarder that uses DoH and DoT which will already bypass yous "Secure" DNS PiHole solution, even browsers are now able to do this directly and bypass the Windows configured DNS servers, other OSs already have this and Android 10 allows you to do this as well with a simple configuration check.

Do not be naive, your PiHole solution was already quite broken way before this announcement...

[MikeDiack]

A few questions to the implementation team:

1) Are there any guesses/indications which version of Windows 10 this will first come in?

2) Is it likely to get retrofitted to older but still supported Windows systems (i.e. 8.1)?

3) I'm guessing you will introduce it in one of the Windows 10 updates (e.g. 20H2 etc), but not as a retrofitted patch for older builds (e.g. 1903, 1909 etc) via a cumulative update? Is that correct. (Obviously with Windows 8.1 its a different story, as there's only one supported branch of the 8.1 OS code, and thus a backport (speaking as a developer myself), might be feasible).

[Ben Thomas]

Definitely agree with Joseph Zollo  that there needs to be full support in the ecosystem, with Windows Server DNS Servers being able to talk to upstream DoH servers and also serve DoH to clients. Because in any enterprise environment, clients will talk to central internal DNS servers, not directly to a public DNS provider.

[InnocentBystander]

Are there any plans to add DoH server functionality to Windows Server?

The reason I ask is that without it, the added DoH functionality in the client will be of very limited use in an enterprise environment based on Windows Server based DNS servers.

What would be really useful is a DoH server which uses certificates for access authentication. In that way we could make our internal (filtered) DNS available to our corporate computers even when they are outside of our network (and not on VPN).

[joachiml]

in order to really improve the situation, I believe there have to be new options  in DHCP for DoT that specifieds the server name for, and URL for DoH to connect to.

Most clients I run - and I asssume this is the case in most organizations - roam networks - home, organization, mobile - and as I don´t want to manually configure clients on the road, DHCP is used. Of course we can argue how secure DHCP is, but I don´t see this to go away soon. If there were a new option specifying name/URL, standard server authentication could be used, and Windows could actually warn when connecting to networks not supporting DoT/DoH or fall back to a well known server configured rather than the one offered by DHCP.

Best Regards, Joachim

[Conchobar]

.