Categories
Deploy360 DNS Privacy Domain Name System (DNS) Improving Technical Security Security

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions, and mentioned some of the protocols that have been recently developed to improve user privacy.

To complement this, we are publishing our DNS Privacy Frequently Asked Questions (FAQ). This highlights and provides answers to the most important aspects of DNS privacy.

Please also check our DNS Privacy page for more information!

Further Information

Categories
Deploy360 DNS Privacy Improving Technical Security

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map a human-friendly domain name to a set of IP addresses that can be used to deliver packets over the Internet. DNS transactions can therefore be correlated to the applications we use, the websites we visit, and sometimes even the people we communicate with.

While the domain name information itself is public, the transactions performed by the hosts are not. Unfortunately, the DNS does not inherently employ any mechanisms to provide confidentiality for these transactions, and the corresponding information can therefore easily be logged by the operators of DNS resolvers and name servers, as well as be eavesdropped by others.

So we are publishing our Introduction to DNS Privacy to raise awareness of the privacy implications of the DNS, and the mechanisms that have been recently developed to improve user privacy.

Please also check our DNS Privacy page for more information!

Further Information

Categories
Deploy360 Domain Name System (DNS) Improving Technical Security

DNS-over-TLS in Linux (systemd)

Whilst we were putting together some content about DNS privacy recently, we learned that recent distributions of Linux ship with support for making DNS queries over TLS. We therefore decided to give Ubuntu 18.10 a try on a laptop.

More recent versions of Ubuntu employ a special service for name resolution called ‘system-resolved.service(8)’. The configuration file ‘resolved.conf(5)’ specifies most of the details for name resolution, including which protocols and resolvers should be employed, whilst the ‘/etc/systemd/network/*.network’ configuration files (see ‘systemd.network(5)’ for details) of the ‘systemd-networkd.service(8)’ specify any per-link specific settings.

The default configuration of ‘systemd-resolved’ is selected at compile time, and ‘/etc/systemd/resolved.conf’ normally contains commented-out lines describing such defaults. For example, the contents of the aforementioned file on a fresh Ubuntu 18.10 installation are:

As may be inferred from the file, DNS-over-TLS (DoT) is supported, but disabled by default. At the time of  writing, only opportunistic DoT is supported according to the manual, which means that the resolver will first try resolution using DoT before falling back to traditional DNS in the event of failure – thus allowing for downgrade attacks where an attacker intentionally causes a DoT failure in order to cause name resolution to downgrade to traditional DNS.

We decided to give DoT at try by changing three configuration variables in ‘/etc/systemd/resolved.conf’:

  • Set ‘DNS’ to the IP address of the DoT server
  • Set ‘DNSOverTLS’ to ‘opportunistic’
  • Set ‘Domains’ to ‘~.’

The ‘DNS’ variable contains the list of IP addresses that correspond to the DoT recursive resolver (you can find a list of public recursive resolvers here).

Setting ‘DNSOverTLS’ to ‘opportunistic’ enables DoT in opportunistic mode – this means that DoT will be employed if possible, but the stub resolver will fall back to traditional DNS if it fails.

Finally, setting ‘Domains’ to ‘~.’ instructs ‘systemd-resolved’ to prefer the specified nameserver over any per-link DNS server that may be available. This is an important setting as otherwise a non-DoT per-link DNS resolver could take precedence over the DoT resolver.

Our resulting configuration therefore becomes:

Once these changes have been applied, you need to make them take effect by executing the command:

sudo systemctl restart systemd-resolved

With this done, we then decided to double-check that DoT rather than traditional DNS was being employed. So we simply ran a sniffer on the Ubuntu laptop, and did a DNS query for ‘fgont.go6lab.si’ which revealed:

Our query generated both traditional DNS and DoT traffic in parallel. In fact, when we later ran a sniffer on the authoritative nameserver itself, it confirmed that both the local resolver on our network (192.168.3.1) and Cloud-flare’s resolver were issuing queries for the above domain.

In response to this finding, we tried to figure out why we were seeing traditional DNS traffic in parallel, instead of just DoT traffic, or at least DoT traffic followed by traditional DNS traffic on the assumption that DoT failed? In addition, why was the local resolver being employed for DNS resolution even when the ‘Domains’ variable instructs ‘systemd-resolved’ to employ the specified DoT resolver over any other resolver.

It would seem that the ‘systemd-resolved’ implementation for opportunistic DoT does not employ traditional DNS only as a result of DoT failures, but rather in parallel to DoT queries. On the other hand, a discussion on the GitHub repository for ‘systemd’ notes that the documentation for the ‘Domains’ variable is actually incorrect and simply specifies that the DoT resolver should be employed for domains matching the specified suffix (“.”, in our case), which does not mean this resolver should be the only one employed for resolving matching domains.

Conclusion

Based on the tests we’ve carried out, we can only conclude that there is a flaw in the DoT implementation of ‘systemd-resolved’. Quite clearly using a DoT resolver only makes sense if DNS queries are sent exclusively over an encrypted channel, or at the very least, traditional DNS is only employed in response to DoT failures (and possibly after acknowledgment from the user that traditional DNS should be employed).

We therefore currently recommend that if DoT needs to be employed, alternative implementations such as Stubby should be used until this issue is resolved with ‘systemd’.

Acknowledgements

We would like to thank Sara Dickinson for her help in debugging these issues.

Further Information

Categories
Deploy360 Domain Name System (DNS) IETF

DNS Security & Privacy discussed at e-AGE18

The Internet Society continued its engagement with Middle East networking community by participating in the e-AGE18 Conference, where we took the opportunity to promote the importance of DNS Security and Privacy. The conference was held on 2-3 December 2018 at the Marriott Hotel in Amman, Jordan and was organised by the Arab States Research and Education Network (ASREN) and co-sponsored by the Internet Society.

Kevin Meynell from the Internet Society’s Middle East Bureau, highlighted the importance of implementing DNSSEC which allows DNS resolvers to authenticate the origin of data in the DNS through a verifiable chain-of-trust. This reduces the possibility of spoofing where incorrect or corrupt data is introduced into a resolver, or a man-in-the-middle attack whereby DNS queries are re-directed to a name server returning forged responses.

Unfortunately, only the Saudi Arabia ccTLD (.sa) has operationally deployed DNSSEC in the Middle East region at the present time, although Iran (.ir) and Iraq (.iq) have deployed it on an experimental basis. On the positive side, around 18% of DNS queries originated from Middle East countries are being validated compared to 12% globally, with Yemen (45.1%), Saudi Arabia (32.1%), Iraq (30.6%), Bahrain (23.2%) and Palestine (22.5%) leading the way. This is possibly because there is a greater prevalence of the use of third-party DNS resolvers (e.g. Cloudflare, Google, Quad9 in the region.

Of course, whilst DNSSEC ensures that DNS records have not been modified without the owner’s consent, it does not keep the queries themselves confidential. DNS queries reveal what site a host is communicating with, and as they are (by default) sent in clear text, they can easily be eavesdropped.

The IETF DNS Private Exchange (DPRIVE) Working Group has therefore recently developed mechanisms to encrypt queries and responses to/from resolvers and therefore provide some confidentiality of DNS transactions. These include DNS-over-TLS (DoT), DNS-over-DTLS (DoD) and DNS-over-HTTPS (DoH), and with the exception of DoD, there are already several public DNS resolvers (Cloudflare, Quad9 & CleanBrowsing) and a few clients (Stubby 1.3+, Unbound 1.6.7+, Knot 2.0+, Mozilla Firefox 62+ and Android 9 Pie) that support these mechanisms.

It should be pointed out that clients and resolvers need to be upgraded to support DoT and DoH, and all these mechanisms currently only encrypt DNS communications between client (stub-resolver) and recursive resolver, not between recursive resolver and authoritative DNS servers. Support for the latter would require all authoritative DNS servers to be upgraded to support DoT and DoH, and there are concerns about the increased computing requirements that would required on the more heavily name servers to initiate the encrypted connections.

In addition, providers of the recursive resolver are in the position to monitor and log queries and responses, so need to be trusted. Nevertheless, these are important developments towards improving the security and confidentiality of the DNS.

Last but certainly not least, attention was drawn to DNS Flag Day which is important to be aware of. DNSSEC and other extended features of the DNS require EDNS0 (Extension Mechanisms for DNS – RFC 6891), and properly implemented name servers should either reply with an EDNS0 compliant response, or provide a regular DNS response if they don’t understand.

However, a lot of name server software is not implemented properly which has meant resolvers have had to incorporate workarounds when name servers don’t respond correctly, but these cause unnecessary retries, delays, and prevent the newer features of the DNS being used. The vendors of the most commonly used DNS software (BIND, Ubound, PowerDNS and Knot) are therefore removing these workarounds as of 1 February 2019, with the consequence is that hostnames served by broken DNS implementations will no longer be resolved. So please check whether your domain is affected!

ASREN is a non-profit association of National Research and Education Networks in the Middle East that aims to connect institutes to enable access to services, applications and computing resources within the region and around the world, and to boost scientific research and cooperation amongst its members. Its mandate covers 22 countries, and it has partnered with the major regional R&E networking initiatives elsewhere in the world, including GÉANT (Europe), Internet2 (United States), CANARIE (Canada), WACREN (West Africa) and RedCLARA (Latin America). International connectivity is supported by the EU-funded EUMEDConnect3 project.

Deploy360 can also help you deploy DNSSEC, so please take a look at our Start Here page to learn more.

Further Information

Categories
Deploy360 Transport Layer Security (TLS)

DNS privacy in new Android 9

I recently enrolled in the Android developer preview programme and got hold of the Android P (9 beta) OTA image for my Nokia 7 Plus phone, and while discovering what’s new, I found a new advanced option under network settings called ‘Private DNS’ that got my attention. This led to me finding an article from Erik Kline describing this new feature in Android 9, which to my surprise supports DNS-over-TLS (RFC 7858).

Last year we wrote about the experiments in the Go6lab with DNS-over-TLS where we set up a recursive DNS resolver listening on port 853 and serving DNS answers to queries encrypted with TLS. This setup was useful if your local DNS resolver was Unbound or Stubby, and since then I’ve been using Stubby as my local DNS client on MacOS with the Unbound DNS server at the Go6lab (privacydns.go6lab.si) as a recursive resolver for encrypted DNS queries without any issues.

So armed with the information from Erik, I decided to test out the Android implementation.

First thing was to turn on the setting and test it with the ‘privacydns.go6lab.si’ server which worked fine. Enabling ‘log-queries’ on the Unbound server quickly revealed that DNS queries are reaching the server and being properly resolved. Since ‘privacydns.go6lab.si’ port 853 is openly reachable from the Internet – you can test it as well.

Encouraged with this success, I thought of adding this functionality to the Go6lab recursive resolvers that I use on a daily basis, but this time it needs to listen on the standard DNS port 53 and as well as port 853 for DNS-over-TLS queries. Since we are running recursive resolvers in Go6lab on Unbound software, this was not a difficult task.

I had to install certbot, obtain a Let’s Encrypt certificate for the host, and add 5 new lines of configuration to unbound.conf…

interface: 0.0.0.0@853
interface: ::0@853
interface: 0.0.0.0@53
interface: ::0@53

ssl-service-key: “/etc/letsencrypt/live/recursive1.go6lab.si/privkey.pem”
ssl-service-pem: “/etc/letsencrypt/live/recursive1.go6lab.si/fullchain.pem”
ssl-port: 853

To make sure it’s also listening on port 53, I added the two lines ending with @53 as a precaution.

After rebooting the Unbound server, setting the ‘Private DNS’ setting on my phone to ‘recursive1.go6lab.si and briefly setting the ‘log-queries’ setting to ‘yes’, the first queries started to appear in the query log.

I was not sure whether queries were coming in over port 53 or 853, and therefore whether they were encrypted or not, so I used tcpdump to capture the traffic from the IPv6 address of my phone.

As we can see, traffic is flowing to and from port 853, indicating that our DNS traffic is being encrypted. Examining the tcpdump capture file with Wireshark reveals this is actually TLS 1.2 traffic and that the content of the packets is encrypted.

Most excellent I thought, but the problem is that with a pre-set ‘Private DNS’ server I would have issues when outside of the Go6lab network (or without a VPN connection back into it) as our DNS recursive resolvers are not reachable from outside to prevent DDOS attacks.

Well there’s a setting in ‘Private DNS’ that says ‘Automatic’ which is pretty opportunistic, and after switching this on, the phone tries to send the DNS query to port 853 and falls back to port 53 if there’s no answer. Observing this through tcpdump confirmed the automatic setting does exactly what is expected – it figures out whether DNS-over-TLS is working on our recursive resolvers and starts using it. This option doesn’t validate server names or hashes, but it makes sure it can negotiate TLS 1.2 (and probably also validates the certificate chain that’s provided). However, in ‘Strict Mode’, the system does additionally validate the hostname where this is entered.

The great aspect of automatic mode is that it does not lock you into one pre-set DNS resolving server, but uses whatever is provided when connecting to a different network. And it’s been confirmed by the user of a Pixel phone that this option is also present in the release version of Android 9 Pie, so this functionality will probably stick around in future versions of Android.

Implementation of this new privacy and security feature by the good people at Android is a big boost for making encryption the norm on the Internet, and opens the opportunity for network operators, DNS operators, VPN providers and everyone else running recursive DNS resolvers to quite easily add this functionality. Whoever connects to your network with Android 9 will automatically start using encrypted DNS service and will make sniffing of the queries at the transport layer a little bit more difficult for eavesdroppers.

With Unbound this is pretty simple – and in my next blog post we’ll be looking into how to enable DNS-over-TLS in Bind and some other DNS servers.

There are already few public recursive DNS resolvers currently supporting DNS-over-TLS on port 853 – Cloudflare on 1.1.1.1, Quad9 on 9.9.9.9, and also CleanBrowsing. But we’re also appealing to network operators and anyone who operates a recursive resolver to please add this functionality to your server. It won’t hurt as regular DNS clients will not even notice it, but for those whose operating systems can take advantage of port 853, it will benefit them a lot.

For more information about why DNS-over-TLS is important, the DNS Privacy Project has a good problem statement on its website, along with an explanation of the technical solutions.

Further Information

Categories
Deploy360 Domain Name System (DNS) Improving Technical Security Open Internet Standards Privacy Technology

A Deeper Dive Into Public DNS Resolver Quad9

There are plenty of public DNS resolvers. The best known was Google Public DNS i.e. 8.8.8.8 and 8.8.4.4 for IPv4 and 2001:4860:4860::8888 and 2001:4860:4860::8844 for IPv6. But there are a few other options available now, each with different policies and technical features.

Two new Public DNS resolvers were recently launched. Quad9 (launched Nov 2017) and 1dot1dot1dot1 (launched Apr 2018). We have already covered 1.1.1.1 in detail in a recent blog. So let’s talk about Quad9 (9.9.9.9).

IBM and Packet Clearing House (PCH) partnered with Global Cyber Alliance (GCA) to launch a Global Public Recursive DNS Resolver Service. Quad9 intends to protects users from accessing the overwhelming majority of malware, malicious domains, botnet infrastructure, and more. Leveraging threat intelligence from multiple industry leaders; it currently blocks up to two million threats per day.

A handy little infographic on the Quad9 website helps show how it works. Essentially, you set up Quad 9 as your DNS and when you query a known bad hostname, the DNS servers respond that the domain does not exist (NX DOMAIN or non-existent domain).

Quad 9 provides 2 types of resolvers, “Secure” which provides security features, and “Unsecured” which doesn’t.

Secure IPv4: 9.9.9.9
Secure IPv6: 2620:fe::fe

Unsecured IPv4: 9.9.9.10
Unsecured IPv6: 2620:fe::10

Threat Intelligence on malicious domains comes from 19 threat feeds. 12 partners are publicly listed and include IBM’s X-Force, Abuse.ch, Anti-Phishing Working Group (APWG), Bambenek Consulting, Cisco, F-Secure, mnemonic, Netlab, Payload Security, Proofpoint, RiskIQ, and ThreatSTOP. Seven remaining Threat Intelligence partners are not listed.

Quad9 also uses two whitelisting methods. The first method uses a list of the top one million requested domains from the Majestic Million daily top one million feed. The feed is constantly updated, and the DNS accounts for any changes. The second is a “Gold List” of domains that should remain secure at all times e.g. Microsoft, Amazon, Google etc.

As explained earlier, if the domain is on Quad9’s blacklist, the resolver answers with NXDOMAIN (No Such Domain – this domain does not exist). Let’s see an example of that:

Blacklisted Domain: renovation4all.gr
Source: openphish.com

In the first example, Google Public DNS (8.8.8.8) returns an A record (188.40.68.58), whereas in the second example Quad9 (9.9.9.9) returns NXDOMAIN. Similarly, the “Unsecure” Quad9 (9.9.9.10) returns the A record of the blacklisted domain. Same results for the IPv6.

Privacy

From a privacy point of view, Quad9 is specifically committed to protecting the users’ privacy and its service doesn’t retain request data. As mentioned in their FAQ: “When an entity or an individual is using the Quad9 infrastructure, their IP address is not logged in our system. We, however, log the geo-location of the system (city, state, country) and use this information for malicious campaign and actor analysis, as well as a component of the data we provide our threat intelligence partners.”

In the Quad9 Privacy policy they have clearly highlighted what data they are recording:

We do keep some generalized location information (at the city/metropolitan area level) so that we can conduct debugging and analyze abuse phenomena. We also use the collected information for the creation and sharing of telemetry (timestamp, geolocation, number of hits, first seen, last seen) for contributors, public publishing of general statistics of use of system (protections, threat types, counts, etc.) We do not correlate or combine information from our logs with any personal information that you have provided Quad9 for other services, or with your specific IP address.

When you use Quad9 DNS Services, here is the full list of items that are included in logs:

  • Request domain name, e.g. example.net
  • Record type of requested domain, e.g. A, AAAA, NS, MX, TXT, etc.
  • Transport protocol on which the request arrived, i.e. TCP, UDP, and encryption status of the protocol
  • Origin IP general geolocation information: i.e. geocode, region ID, city ID, and metro code
  • Protocol version IP address – IPv4, or IPv6
  • Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, etc.
  • Absolute arrival time
  • Name of the Quad9-operated machine that processed this request
  • Quad9 target IP to which this request was addressed (no relation to the user’s IP address)

It is also mentioned in the Privacy policy that Quad9 may keep the following data as summary information, including all the above EXCEPT for data about the DNS record requested:

  • Currently-advertised BGP-summarized IP prefix/netmask of apparent client origin
  • Autonomous system number (BGP ASN) of apparent client origin

All the above data may be kept in full or partial form in permanent archives.

Network Infrastructure

Quad9 is leveraging the Packet Clearing House (PCH) global assets around the world. PCH has Points of Presence (PoPs) in 181 internet Exchange Points all across the world.

Quad9 uses AS19281 to announce following IPv4 and IPv6 prefixes.

IPv4: 9.9.9.0/24, 149.112.112.0/24, 149.112.149.0/24
IPv6: 2620:fe::/48

No ROA found for any prefix.

DNS over TLS

A DNS query is by default sent over a plaintext connection, which makes them vulnerable to eavesdropping by attackers with access to the network channel, reducing the privacy of the person sending the DNS request. DNS over TLS (RFC7858) is a security protocol that forces all connections with DNS servers to be made securely using TLS. This effectively keeps any middle party (ISPs) from seeing what website you’re accessing. Initiation of DNS over TLS is very straightforward. By establishing a connection over a well-known port, clients and servers expect and agree to negotiate a TLS session to secure the channel.

RIPE Labs has published some extensive test results on this.

Final Word

Every step taken towards greater security, privacy, and reliability is a positive one. The addition of Quad9 and APNIC-Labs/CloudFlare’s 1.1.1.1 is definitely going to bring good to the whole internet ecosystem.

Categories
Deploy360 Domain Name System (DNS) IETF Improving Technical Security Transport Layer Security (TLS)

Cloudflare launches 1.1.1.1 DNS service with privacy, TLS and more

There was an important development this month with the launch of Cloudflare’s new 1.1.1.1 DNS resolver service. This is a significant development for several reasons, but in particular it supports the new DNS-over-TLS and DNS-over-HTTPS protocols that allow for confidential DNS querying and response.

Why 1.1.1.1?

Before we get to that though, Cloudflare joins Google’s Public DNS that uses 8.8.8.8 and Quad9 DNS that uses 9.9.9.9, by implementing 1.1.1.1 as a memorable IP address for accessing its new DNS service. IP addresses are generally not as memorable as domain names, but you need access to a DNS server before you can resolve domain names to IP addresses, so configuring numbers is a necessity. And whilst a memorable IP address might be cool, it’s also proved important recently when DNS resolvers have been blocked or taken down, requiring devices to be pointed elsewhere.

The 1.1.1.1 address is part of the 1.1.1.0 – 1.1.1.255 public IP address range actually allocated to APNIC, one of the five Regional Internet Registries, but it has been randomly used as an address for so many things (e.g. for proxies), that it was overwhelmed with garbage traffic every time it was announced in the global routing system. The Cloudflare network is sufficiently scaled that it can cope with this traffic, so an agreement was established to allow APNIC Labs to analyse traffic to this address range in return for Cloudflare being able to use 1.1.1.1 for its DNS resolver project.

Under the agreement, APNIC also allowed Cloudflare to use the address 1.0.0.1 as the second IPv4 address for their DNS services, from a separate address range allocated for research. IPv6 addresses are also available, although at 2606:4700:4700::1111 and 2606:4700:4700::1001 they are not nearly so memorable.

Improving DNS Performance

It’s also important to have a fast and reliable DNS resolver service. Every device connecting to the Internet needs a recursive DNS resolver to translate names into addresses, which are usually provided by your ISP who’ll automatically configure your devices to point to them. However, ISP-provided resolvers can often be slow and unreliable (a problem I’ve encountered recently with an ISP that I use, and there’s some interesting comparison testing in this in this blog post), quite aside from the fact that locally-based servers have been blocked or censored by some national governments in response to civil unrest or politically embarrassing incidents. The likes of Cloudflare, Google, Quad9 and others provide alternatives, allowing users to choose better performing services with enhanced features rather than just having to rely on the default service offered by your ISP.

DNS Privacy

And this leads us to the most innovative feature of Cloudflare’s 1.1.1.1 DNS service. The DNS was never designed with privacy or security in mind, and whilst DNSSEC adds verification to the information returned by DNS queries, traffic is still sent unencrypted which allows anyone monitoring your network connection to see what you’re looking up and therefore visiting.

A couple of different solutions to this problem have recently been developed by the IETF, which we’ve discussed in previous blogs. The DPRIVE Working Group has developed DNS-over-(D)TLS, whilst the DOH Working Group has been working on DNS-over-HTTPS. The different protocols have different merits and try to address particular legacy behaviour of the DNS protocol (e.g. limitations on UDP packet size and the need for fast responses), but both approaches encrypt DNS queries and responses to provide confidentiality of these transactions.

So far so good, but there’s also a need for both resolvers and clients to be upgraded to support these protocols. Up until now, whilst some test servers have been set-up by various organisations, Google has been the only significant provider supporting DNS-over-HTTPS through their Google Public DNS and Android operating system. As a result, there’s been a certain reticence for other providers and vendors to build in support for protocols that rely on a competitor, but hopefully as more alternative resolver services are established, we’ll see increasing usage of these DNS privacy protocols.

Limitations

It should be pointed out that both DNS-over-HTTPS and DNS-over-TLS only encrypt DNS communications between stub-resolver (on the client device) and recursive resolver (e.g. Cloudflare 1.1.1.1). They do not currently encrypt the communications between the recursive resolver and authoritative DNS servers when resolving queries, so the provider of the resolver needs to be trusted as it still has the potential to monitor and log transactions. Neither does either protocol ensure the integrity of information returned from an authoritative server, which is why DNSSEC is also required to cryptographically assert the DNS entries are correct. They are nonetheless important components in improving the security and confidentiality of the DNS.

Implementation

If you’re interested in how to set-up a recursive DNS resolver and/or stub-resolver on a client device, you can find a lot of information over on the DNS Privacy website. Deploy360 also published a blog post last year on how we set-up DNS-over-TLS in the Go6lab which is well worth reading.

 


UPDATE: We should also note that Cloudflare’s 1.1.1.1 service also supports “Query Name (QNAME) Minimization”, as defined in RFC 7816. They include a reference to this at the end of their “Nitty Gritty Details” page:

Cloudflare minimizes privacy leakage by only sending minimal query name to authoritative DNS servers. For example, if a client is looking for foo.bar.example.com, the only part of the query 1.1.1.1 discloses to .com is that we want to know who’s responsible for example.com and the zone internals stay hidden.

Kudos to Cloudflare for implementing this higher level of privacy protection in their service.

Thanks to Stéphane Bortzmeyer for pointing out on Twitter that Cloudflare had implemented QNAME minimization. We had missed the small mention in Cloudflare’s technical blog post and weren’t aware they had included this.