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-HTTPS (DoH) Support in Mozilla Firefox

Recent releases of Firefox have introduced the concept of DNS privacy under the name “Trusted Recursive Resolver”. Although Firefox ships with DNS-over-HTTPS (DoH) disabled by default, there has been some discussion within the Mozilla developer community about changing the default to “enabled”.

Although DoH is somewhat controversial because it moves control plane (signalling) messages to the data plane (data forwarding), and can thereby bypass local network policies, DoH advocates argue that it makes it harder to block or monitor DNS queries which is a commonly used method for restricting access to the Internet and/or monitoring user behaviour.

But putting these arguments aside, if you want to try out DoH then the DNS privacy (or “TRR” in Firefox speak) configuration in Firefox can be accessed as follows:

  • Enter “about:config” in the address box of the browser
  • Search for “trr” (without quotes)

A sample output of DNS privacy configuration in Mozilla Firefox is as follows:

Firefox offers its technical users quite a few settings to play with, but the most important options (along with their recommended settings) for TRR are:

“network.trr.bootstrapAddress” specifies the IP address of a recursive resolver that should be employed to obtain the address of the DoH resolver specified using the “network.trr.uri” variable.

For modes other than “3”, Firefox will employ any DNS servers learned from DHCP. However, when mode “3” is selected, queries are not sent by default to any non-DoH resolver, and hence it is necessary to specify the address of a DNS resolver to be able to “bootstrap” DNS privacy.

Setting network.trr.mode to “3” sets “strict” resolution – meaning only DoH will be employed, with no fall back mechanism. This is a sensible option, since it prevents downgrade attacks.

Finally, network.trr.uri allows the selection of a DoH server/resolver.

The resulting configuration is:

In order to check whether TRR has been successfully enabled, it’s possible to use a protocol analyzer, as follows:

  • Check the network for traditional DNS traffic – this means packets destined for TCP port 53 or UDP port 53. If DoH has been successfully enabled, you should see no traffic from the local node to those ports
  • Check the network for DoH traffic – that means packets destined for TCP port 443 of the IP address(es) corresponding to the DoH resolver in the “network.trr.uri” variable. If DoH has been successfully enabled, you should probably see traffic to this port.

A more interesting way of checking the status of TRR is to employ the Firefox’ “about:networking”  experimental interface. This allows access to internal networking-related features, and can be accessed by entering the aforementioned string (without quotes) in the address box – with the DNS cache being directly available at “about:networking#dns”.

The following figure shows a sample output of the DNS cache:

The first column contains the list of cached domain names, while the second column indicates the protocol family employed (IPv4, in all of our domain names). The third column specifies whether TRR (DoH) was employed for DNS resolution, as if it has been enabled on the browser since we ran it, all of the entries in the DNS cache should have the third column set to “true”.

The fourth column specifies the addresses resulting from DNS resolution, while the fifth column specifies the current “time-to-live” of each entry (in seconds) before the entry is purged from the cache.

Firefox TRR Configuration variables

Whilst we only need to set three configuration variables to enable TRR, Firefox offers a range of other options for tuning it:

  • trr.allow-rfc1918: false (boolean)
    • Firefox will only allow RFC1981 addresses in TRR responses if this flag is set to “true”
  • trr.blacklist-duration: 60
    • Number of seconds a domain will be kept in a “blacklist” when resolution does not work with TRR, but works with a normal resolver.
  • trr.bootstrapAddress:
    • Address of a recursive resolver to obtain the address of the server specified in “network.trr.uri”
  • trr.confirmationNS: example.com
    • Firefox will try to do DNS resolution to check that TRR is working properly
  • trr.credentials:
    • Credentials to be used in the “Authorization” request header
  • trr.disable-ECS: true (boolean)
    • Disable sending EDNS Client Subnet (ECS) information to authoritative servers.
  • trr.early-AAAA: true (boolean)
    • Firefox normally sends both A and AAAA queries in paralell. It will only use AAAA records if they arrive first and this flag is set to true
  • trr.max-fails:
    • Number of times after which Firefox should give up on TRR resolution for a given domain name
  • trr.mode: 0
    • 0: Off – use normal resolver and don’t use TRR
    • 1: Race – do TRR and normal resolution in parallel, and use whatever answer comes first
    • 2: First – use TRR, and fall back to normal resolver if it fails
    • 3: Only – Only use TRR, and never use normal resolver (after initial setup)
    • 4: Shadow – Do TRR in parallel with normal resolver (for measurements) but only use results from normal resolver5: Off by choice – same as “0”, but represents explicit decision to disable TRR
  • trr.request-timeout: 3000
    • Time value in seconds after which a TRR query is considered to have failed
  • trr.uri: https://mozilla.cloudflare-dns.com/dns-query
    • URI to be employed for DNS resolution
  • trr.useGET: false (boolean)
    • Whether to use GET rather than POST method.
  • trr.wait-for-portal: true (boolean)
    • Whether to wait for captive portal detection before using DoT

 

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

 

Categories
IETF

IETF 101, Day 4: The Brass Tacks about DNS and Routing

This week is IETF 101 in London, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. And Thursday is probably the busiest day for us, covering the whole range of our interests.

ROLL has its first of two sessions starting at 09.30 GMT/UTC; continuing on Friday morning. There are several drafts being discussed dealing with the issues of routing over resource constrained networks where limited updates are possible.


NOTE: If you are unable to attend IETF 101 in person, there are multiple ways to participate remotely.


There’s a choice between a couple of working groups after lunch, starting at 13.30 GMT/UTC.

DOH was chartered to create a single RFC, so clearly the draft DNS queries over HTTPS is going to be the primary focus of discussion. However, there will also be updates on the practical implementation work, and a discussion about possible future work if there is a decision to re-charter the group.

6LO runs in parallel and has a fairly busy agenda with Registration Extensions for 6LoWPAN Neighbor Discovery, and Address Protected Neighbor Discovery for Low-power and Lossy Networks having received feedback from the IESG. The drafts related to IPv6 Backbone Router and Packet Delivery Deadline time in 6LoWPAN Routing Header are being prepared for Working Group Last Calls, and there will also be updates on the 6LO applicability and use cases and from the fragmentation design team (draft-watteyne-6lo-minimal-fragment-00 and draft-thubert-6lo-forwarding-fragments-04). Finally, there’s a proposed update to RFCs 6550 and 6775 where 6LoWPAN ND nodes in a RPL domain do not participate in the routing protocol.

Following the afternoon break there’s the choice of SIDROPS, T2TRG or a joint NTP/TICTOC meeting, commencing at 15.50 GMT/UTC.

SIDROPS will be discussing several drafts related to the operational management of certificates in the RPKI, and in particular how to perform RPKI checks via a route server. There are also two drafts related to Trust Anchor Locators – one defining a TAL for RPKI with support for HTTPS URIs, whilst RPKI signed object for TAL defines how a RPKI signed object can be used to communicate a new Trust Anchor Locator to already deployed Relying Parties. There’s a working group sponsored draft on Requirements for RPKI Relying Parties, and finally a new proposed draft on Origin Validation Policy Considerations for Dropping Invalid Routes (not yet published).

T2TRG researches the issues of turning the IoT into reality, and will be discussing a key draft State-of-the-Art and Challenges for the Internet of Things Security. There will also be presentations on Deep learning on microcontrollers, Secure Computations in Decentralized Environments, and Semantic Interoperability Testing.

The NTP/TICTOC joint session is focusing on Network Time Security (NTS). This represents a significant update for NTP server authentication as secure and accurate time synchronization is vitally important for the proper operation of security protocols.

If you still have any remaining energy, there’s a couple of evening sessions starting at 18.10 GMT/UTC.

DNSOP holds its second session of the week, and the main draft of interest is the Multi-Provider DNSSEC Model that relates to deploying DNSSEC in environments where multiple DNS providers are in use.

Last but not least, UTA will be discussing drafts on Strict Transport Security (STS) for mail (SMTP) transfer agents and mail user agents as well as SMTP Require TLS Option.

For more background, please read the Rough Guide to IETF 101 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups

Categories
Deploy360 IETF

Deploy360 at IETF 100, Day 4: Woohoo for DOH!

This week is IETF 100 in Singapore, and we’re bringing you daily blog posts highlighting some of the topics that Deploy360 is interested in. Thursday is another busy day, with the second sessions of the V6OPS and DNSOPS Working Groups, along with the first meeting of the DOH Working Group and other encryption-related activities.

V6OPS continues at 09.30 SGT/UTC+8 from where it left off. On the agenda are drafts relating to 464XLAT Deployment Guidelines for Operator Networks, transition requirements for IPv6 customer edge routers, and IPv6 prefix delegation for hosts. There’s other drafts on DHCPv6 Prefix Delegation and Neighbour Discovery on a cellular connected IoT router, and on using a /64 from a customer prefix for numbering an IPv6 point-to-point link. Finally, there’s an initiative to clarify about what functionalities should determine whether a network is ‘IPv6-only’.

Running at the same time is TLS, which will be primarily focusing on the two big issues of TLS 1.3 and DTLS 1.3. However, it will also be discussing drafts on connection ID, exported authenticators, protecting against denial of service attacks, and application layer TLS.


NOTE: If you are unable to attend IETF 100 in person, there are multiple ways to participate remotely.


After lunch sees the debut of DOH at 13.30 SGT/UTC+8. This is working to standardise encodings for DNS queries and responses that are suitable for use in HTTPS, thereby enabling the DNS to function where existing DNS methods (UDP, TLS and DTLS) have problems. There’s just the one draft so far, although there will also be a discussion on the planned next steps.

Alternatively, you can check out 6LO. There are four drafts relating to IPv6 Neighbour Discovery on node networks with limited power, memory and processing resources, and there will also be a discussion on the 6LO applicability and use cases. Last but not least, is a draft relating to the transmission of IPv6 packets over Wireless Body Area Networks.

Following the afternoon break, ACME is meeting at 15.50 SGT/UTC+8 to finalise the ACME specification. This has been submitted to the IESG for publication, and will focus on the feedback received to-date. Other drafts being discussed relate to automatic certificate management for telephony and email , along with Short-Term Automatically-Renewed (STAR) Certificates.

Running in parallel is DNSOP that will also continue from where it left off on Monday. Much of this session is likely to focus on new business, including returning additional answers in DNS responses, a mechanism allowing an end user to determine the trusted key state of resolvers handling DNSSEC queries, an update to the TSIG specification to address a known bug, and a proposal for a .internal TLD to use the DNS for non-global names.

For more background, please read the Rough Guide to IETF 100 from Olaf, Dan, Andrei, Steve, Karen and myself.

Relevant Working Groups