The big DNS Privacy Debate at FOSDEM

This weekend at the excellent FOSDEM gathering there were no less than three presentations on DNS over HTTPs. Daniel Stenberg presented a keynote session “DNS over HTTPS – the good, the bad and the ugly” (video), Vittorio Bertola discussed “The DoH Dilemma” while Daniel, Stéphane Bortzmeyer and I formed a DNS Privacy Panel expertly moderated by Jan-Piet Mens. I want to thank Daniel, Jan-Piet, Rudolf van der Berg, Stéphane & Vittorio for proofreading & improving this post, but I should add this does not imply an endorsement from anyone!

In what follows, I will attempt to give a neutral description of what I think we learned, and where we now are on DoH, with a focus on the European perspective. If you find a noticeable bias, please let me know urgently and I’ll address it. But to be clear, I’m no fan of centralizing DNS on a small number of cloud providers.

After the neutral description you will find some strong opinions on if “DNS over Cloud” is a good thing or not.

Screenshot from 2019-02-07 09-49-47

Daniel Stenberg’s interpretation of what worries people about DoH

Words & definitions

During the FOSDEM presentations, various visions on the desirability of DNS over HTTPS were discussed. We were sadly rather hampered by messy definitions. There are two definitions that sound the same but are different in practice. Firstly, there is “DNS over HTTPS” (DoH) which is a transport protocol so you can securely ask DNS queries over HTTPS.

Secondly, Google, Firefox and Cloudflare are working on using DoH to move DNS queries from the network service provider straight onto the cloud. In other words, where previously your service provider could see (and answer) your DNS queries, in this proposed future you would send your DNS requests to a “free-as-in-beer” cloud provider.

As Daniel pointed out well during his keynote, both of these things have been called DoH, which is highly confusing. “The Resistance” as Daniel labels it complains about “DoH” when in fact they are mostly complaining about centralizing DNS on cloud providers. We should not blame the protocol for what operators might do with it.

It may be that the greatest benefit we get out of the hours of FOSDEM DoH presentations is that we now know we should separate our concerns with DoH (the protocol) from our concerns about the application of this protocol to deliver what I propose we henceforth call DNS over Cloud (DoC).

DNS over HTTPs (the protocol, DoH)

The DoH protocol is designed to use the HTTP and TLS infrastructure to deliver encrypted and authenticated DNS answers that (crucially) are hard to block by network operators. An earlier protocol called DNS over TLS was already available but since it runs on port 853 and “does not look like HTTPS”, network operators that dislike DoT can easily block it. Most corporate networks will in fact do this by default.

DoH shares the benefits and downsides of HTTPS. It can send out more trackable data than regular DNS, simply because HTTP supports things like headers & cookies. TLS session resumption functions as another tracking mechanism. On the plus side, anything that can cache or redistribute HTTPS can now also be used to improve or proxy DNS. Also, DNS over HTTPS makes it possible to push DNS answers even before they are asked, which could increase page load performance.

It may be seen as good or bad that HTTPS can be made undetectable and unblockable, depending on who you are and what you worry about. If Google were to colocate a DNS over HTTPS service on the IP address also used for ‘Google.com’, countries and network operators would face a Solomon’s choice if they wanted to block DoH: give up Google searches or keep DoH alive.

Update: Google turns out to do exactly this, you can get DNS answers over an https://google.com/ request.

Network operators that feel they should be in control of their network will not like this standoff, while users that think their network operators should have no power over them will rejoice. For the second group, at FOSDEM we discussed the proverbial Turkish dissident that would benefit from unblockable DNS.

Finally, because DoH uses authenticated HTTPS (just when like visiting any website), we know we are talking to the nameserver we want to talk to. It protects against rogue nameservers, possibly injected by hijacking the DHCP request, or simply by spoofing IP packets.

DNS over Cloud (DoC)

As it stands, network operators (ISPs, service providers, your WiFi providing coffee shop) can see your DNS traffic. In addition they could (and actually often do) manipulate or block certain queries or responses. This is an intrinsic property of providing DNS service – everyone that provides DNS service to you can do these things, cloud based or not.

One concrete difference between typical network DNS and DNS over Cloud is that network DNS tends to be unencrypted while DoC can encrypt the transport component. And encryption is good.

Much like using a VPN to access the internet only moves your traffic from one place to another, choosing a different DNS service does not magically make your DNS more secure. It does change who you want to trust though. And if you are lucky your trusted provider is more secure in ways that are relevant to you.

Currently, that trust is not very intentional. Internet users often have little choice in what ISP to use. In many cases they may not even know. While local regulations (like GDPR, NIS, ePrivacy and EU telecommunications directives) may limit what a provider is allowed to do, users may not be sure if their actual network operator adheres to these legislations.

DNS over Cloud proponents advocate that the user did however consciously choose a browser and that the browser is therefore in a good position to suggest or even pick a DNS provider for their users. Users sometimes also can’t pick a browser either, but they may have freedom to select a phone and different brands of phones include different browsers. Cheaper phones all ship with the same browser however.

During our DNS Privacy Panel it was also established that we estimate that most users do not care very much about their DNS privacy, and are in any case not well informed about the tradeoffs. The choice of DNS provider therefore needs to be made for them, either by their phone, their operating system or their browser.

A brief interlude on DNS encryption

Everyone agreed more encryption is good. This can happen between client equipment and the nameserver, or between the resolving nameserver and authoritative nameservers. Warren Kumari from Google tested the waters for our thoughts on opportunistic DNS over TLS (DoT) between phone/browser and DNS service, and this went down well, except that it was noted it is subject to downgrade attacks. I noted that PowerDNS has been stimulating its customers to enable DoT already because Android Pie will attempt to use your DoT service if it is there. There was also a brief discussion on the efforts to encrypt traffic between resolver and authoritative servers, something that is also good.

What does DoH protect against? Because we use HTTPS anyhow for protection?

At the very end of Daniel’s keynote a question was asked what the point is even of protecting DNS queries and responses. The DNS response leads to the setup of a TLS connection and this TLS connection is itself already encrypted and private. We don’t need DNS for that. In addition, a TLS connection setup will typically include the name of the site being visited in plaintext, even with TLS 1.3 (the Server Name Indication or SNI field). Finally, the IP address we eventually end up connecting to may give a very good indication who this connection is going to. So it is generally possible to tell where a TLS connection is going – even without looking at DNS. Stéphane’s RFC 7626 discusses many of these tradeoffs.

As of February 2019, there is little privacy differential when using DNS over HTTPS since the name still travels in plaintext. It may however be more expensive for a snooping network provider to extract the SNI from packets. Also, work is ongoing to use encrypted DNS to encrypt the SNI field too, in which case DNS over HTTPS would actually give us more additional privacy.

What DoH does however deliver today is protection against DNS-based censorship.

Censorship & things that break

The PowerDNS DoC service quickly gained thousands of users, many of whom are in Indonesia. PowerDNS learned that Indonesian ISPs perform a lot of blocking and DoH servers are a great way around such blocking. It may be that doh.powerdns.org is small enough to fly under the radar of the Indonesian censors.

Separately there was a brief discussion on how DoC can break things like VPNs and split horizon. We did not explore this much further except that it was noted it actually breaks things in production. An open question is if the encryption is worth the amount of breakage observed, and if we could maybe work around it.

Differences between Cloud and Network DNS Providers

The highly regulated nature of service providers, at least here in Europe, is a double edged sword. It restricts what ISPs can do with your data but it also means they respond to court orders that block content and may implement blocking of child pornography even without such orders. Internet users may not be happy with such blocking, either because they want easy access to Torrents, or simply because they object to the very principle of communications being blocked.

In addition, while (European) service providers are under legal obligation not to monetize or otherwise sell your traffic (without very explicit permission), that does not mean they don’t do it. Specifically, all service providers here will respond to government (bulk) interception orders, and provide police & spies with a full copy of all your traffic, including the unencrypted DNS parts.

Cloud providers meanwhile are very adept at navigating the GDPR waters and are able to simultaneously promise you they won’t sell your data but also power most of their bottom line selling advertising based on what you do online. In addition, they are relatively out of reach of government interception or blocking orders, which take many months to travel to a foreign jurisdiction, and frequently never arrive.

Screenshot from 2019-02-07 10-03-37

Differing views on the panel

We lucked out with three speakers with three informed but still different opinions on the subject.

I (Bert) make my living selling software and services to telecommunication service providers. I know many European ISPs intimately and I do not believe they are engaging in secret user profiling. We have enough trouble with GDPR as it is to get any kind of DNS debugging data out of our customers. So my belief is that while service providers may not be “a force for good”, I do predict they’d have a very hard time breaking regulations to secretly run a surveillance economy. But, these people pay my company good money so I am biased to like them. I do not believe it is a good idea however to send a record of every website I visit to cloud providers like Google or Cloudflare.

Stéphane meanwhile is highly knowledgeable on how governments actually regulate the Internet. He even wrote a book on it that is subtitled “The Internet – a political space”. In his opinion, GDPR and other regulations may be great, but enforcement is scarce as data protection agencies do not understand DNS and do not prioritize it. This leaves room for even European service providers to sell and monetize DNS data. In addition, Stéphane is worried that when governments DO finally get interested in DNS, it is for censorship purposes.

Daniel offers a perspective inspired by his background in HTTPS – he sees the obvious benefits of not only encrypting DNS data but also authenticating its server. “You know who you are talking to”. He furthermore observes correctly that users spend time on different networks, and that we can’t possibly expect them to study the privacy practices and reputation of every school or coffee shop where they use Wifi. If users picked a suitable DoH provider that worked over all networks, they’d receive a constant level of trust – no matter what network they are on.

Daniel has separately argued that he regards an explicit promise from a cloud provider not to sell your traffic as a stronger guarantee than passively trusting that a provider will stick to the applicable laws. Finally, Daniel notes correctly that GDPR does not protect you if you are connected to a rogue nameserver (so not the one you were expecting to use). It may not be the service provider that spies on you but someone else on the path TO that provider. DoH protects against that scenario.

Who gets to pick who we should trust?

If a browser decides to use DoC for its lookups, which provider should it offer? Early in the discussion it was noted that there should be a transparent process for deciding who could be offered as a provider, where it was also noted that this process for Firefox has been far from transparent or even operational so far. A member of the audience spotted an interesting analogy with the CA/Browser Forum which has been used to determine which certificate authorities are to be trusted. Daniel noted that this is however also similar to search engine selection in browsers “and everyone picks the default, and that is the one that pays most”.

Stéphane opined that there should be many DoC providers to choose from, but since picking one is hard, the browser should present a list with a random one at the top. This allows choice but also prevents needless concentration if a user picks the default.

Why are cloud companies so anxious to host our DNS?

Warren Kumari from Google gave a very clear response – a better and faster internet leads to more internet use and more searches and therefore more advertisements and thus more money for Google. Such honesty is rare & it is appreciated. Warren also reconfirmed (as happened at FOSDEM 2018) that 8.8.8.8 sticks to its privacy policy, it is not being mined. As an aside, when 8.8.8.8 was launched, the state of ISP DNS was indeed dire. DNS in many service providers did not not have a good home – fitting awkwardly between network and application departments. The creation of 8.8.8.8 contributed to the vastly improved DNS we see today, and at the time it was necessary.

But why 1.1.1.1 or 9.9.9.9? Christian Elmerot from the Cloudflare (1.1.1.1) resolver team offered the explanation that people on 1.1.1.1 will get (slightly) faster answers from 1.1.1.1 for Cloudflare domains than when using other resolvers, and this makes their services more attractive.

It may however be that public DoC providers are not entirely disinterested in getting a copy of the world’s browsing behaviour.

Is it any faster?

DoH (or more precisely, DoC provided by Cloudflare) is actually 7 milliseconds slower on average than the system resolver, according to measurements performed at Mozilla back when Daniel still worked there. He does note however that the worst case performance of the Cloudflare DoC is much better than the worst case system resolver performance.

Should you run your own resolver?

It may be slower, but Stéphane noted that having your own resolver on your own machine, is actually also not good for your privacy, since authoritative servers will now see your personal IP address, instead of the service provider IP address. However, it does offer full control – at a possible performance and privacy penalty. Stéphane notes that a mixed mode local resolver, that uses a DoH provider for cache misses, may be an optimum. Some further thoughts on the benefits of a local resolver can be found in this post “Benefits of DNS service locality” by Paul Vixie.

What about EDNS Client Subnet?

There was a brief and somewhat angry discussion between me and Daniel that somehow got cut from the end of the video recording. This discussion was about EDNS Client Subnet, and how it impacts your privacy when used by a service provider.

Some large scale internet service providers include part of a customer’s IP address when sending queries to (for example) Akamai or Level3. This is currently necessary because these large scale CDNs perform load balancing via DNS and they need to see 24 or sometimes even 25 bits of the IPv4 address to determine the right server for a user. This is sometimes reported as a privacy problem, and in the general case it could be. However, when used between a hosting provider like Akamai and a service provider, in reality there is no loss of privacy – the customer is attempting to connect to an Akamai service, and Akamai will always see the subscriber IP address in that case.

Noteworthy is that DoC-providers that do not implement EDNS Client Subnet (ECS) may disadvantage competing cloud operators since they will send internet users to sub-optimal content distribution nodes. It may not be wise to rely on one CDN to connect to a competing CDN.

The balance

This is where the attempt at impartiality in this post ends.

First, we should separate a few things: DoH, DoC and “DoC-by-default”. It seems clear that the first two of these are not problematic. It is good that we have a secure DNS transport mechanism and some DoC providers may truly be a step up in privacy and security for users in some countries or places.

Our discussion should be about what we think of “DoC-by-default”, that is, any attempt by browser vendors to default people into moving their DNS to Cloudflare or themselves. My concern also extends to a weaker form where you get DoC-by-nudge if you press a little ‘Got it’ button when prompted if you want to benefit from the ‘Google Secure Lookup Service’.

Who should we believe, the highly regulated (European) service provider that says it is not allowed to spy on its users using DNS, and also says they aren’t doing it?

Or should we believe the cloud provider that claims those service providers are spying on their users and then asks us for our DNS traffic while promising not to sell it, although they will log each and every query?

Is it credible for DNS over Cloud providers to spend huge efforts on pushing their DNS services but also to claim they won’t do anything impactful with the results? Google has advanced that faster DNS means more revenues for them, which is likely true, but DNS over HTTPS will first slow things down!

Cloudflare meanwhile opines that if you use their DoC-service, this makes accessing Cloudflare domains a tiny bit faster compared to visiting competitor’s domain names. While this may be true, first the effect is tiny and second, it is not that great a sell for an actual Internet user.

It is currently true though that your coffee shop WiFi may be spying on you, or may enable an attacker to do so. However, as noted above, the names of sites you visit are still sent out unencrypted by TLS connections these days, so DoC does not even deliver on saving you from such spying right now.

Finally, much is made of the users in repressive regimes which might benefit greatly from unblockable DNS, and this may indeed be so. But as noble as it is to help the Turkish dissident to communicate with the world, it seems odd that to help her we need to send Cloudflare or Google a record of every website visited by 500 million Europeans!

Other arguments for DoC-by-default may be more appealing – if you are a cloud provider. Despite all promises to not sell the DNS data, not log it very long etc, the fact remains that a DoC operator gets sent a copy of every server and site name a user visits. Somehow someday that data is going to be monetized, and this will happen in ways users will not be consulted about.

This leaves us with other explanations for the DoH push, and none of these are very good. For one, it is plain and simple an attempt to fully control the Internet experience. As an example, there have been ISPs that have pondered adding ad-filtering as a network service. This does not sit well with advertising companies like Google, so they’d love to be sure such blocking is not possible. DoC-by-default gives that to them.

We’ve previously established that users do not have strong or informed opinions on the source of their DNS, so whatever happens will be decided by browser vendors, on behalf of internet users.

Given what we now know about the relative risks and benefits of DoC, it seems utterly unwarranted to decide that users should give their DNS to Google or Cloudflare because there is no credible claim it will actually improve their
lives.

Thanks for making it to the end of this long post!

  • Some more thoughts on DoH & specifically the Firefox plans can be found here.
  • Open-Xchange and several other groups are actively informing governments and data protection authorities about what is going on & why we feel DoC-by-default is a bad thing. Please contact vittorio.bertola@open-xchange.com if you are interested in joining in!

 

Changes in the PowerDNS Recursor 4.2.0

The 4.2.0 release of the PowerDNS Recursor brings a lot of small, incremental changes over the 4.1.x releases. We expect little operational impact when upgrading from 4.1.x. However, several new features have been implemented and some features have changed.

This release was made possible by contributions from: Gibheer, cclauss, Aki Tuomi, Ruben, Doug Freed, Richard Gibson, Peter Gervai, Oli, Josh Soref, Rens Houben, Kirill Ponomarev, Kees Monshouwer, Matt Nordhoff, OSSO B.V., phonedph1, Rafael Buchbinder, Ruben Kerkhof, spirillen, Tom Ivar Helbekkmo and Chris Hofstaedtler.  Thanks!

DNS Flag Day

The 4.2.0 release of the PowerDNS Recursor removes several workarounds for authoritative servers that respond badly to EDNS(0) queries. This is part of a multi-vendor effort known as DNS flag day to move the DNS ecosystem forward by being less lenient on non-conforming implementations.

XPF Support

This release adds support for DNS X-Proxied-For (draft-bellis-dnsop-xpf-04). This technique is roughly equivalent to HTTP’s X-Forwarded-For header, it can communicate the IP address and port of the original requestor from a loadbalancer/frontend (like dnsdist) to the backend server. This can allow the backend server to make decisions regarding that specific client. XPF is disabled by default and can be enabled by setting the xpf-allow-from setting to the source IP address of the front-end proxy and setting xpf-rr-code to the code of the resource record used by the frontend.

EDNS Client Subnet Improvements

More granularity has been added for the users of EDNS Client Subnet. The new ecs-add-for setting can be set to a list of netmasks for which the requestor’s IP address should be used as the EDNS Client Subnet for outgoing queries. For IP addresses not on this list, the PowerDNS Recursor will use the ecs-scope-zero-address instead, which matches the behavior of 4.1.x. Valid incoming ECS values from use-incoming-edns-subnet are not replaced.

New and Updated Settings

Sites that process large numbers of queries per second (100k+), may benefit from the new distributor-threads setting. This can be used in combination with pdns-distributes-queries=yes to spawn multiple threads that will pick up incoming queries and distribute them over the worker threads.

For several statistics, the PowerDNS Recursor uses a public suffix list to group queries. Before, this list was built into the binary and only updated for every release. This release adds the public-suffix-list-file setting that allows operators to supply their own public suffix list. This option is unset by default, which means the built-in list is used.

Over the last years it has become clear that many networks on the internet lose large UDP packets, leading to authoritative servers being seen as dead from the recursor’s perspective. To ensure return packets from authoritative servers have a better chance of reaching the recursor, the edns-outgoing-bufsize setting’s default has changed from 1680 to 1232. 1232 was chosen because it is the largest DNS response that can be carried on an IPv6 link with the IPv6 minimal MTU (1280). In tandem with this change, the udp-truncation-threshold that decides when to truncate responses to clients has also been changed from 1680 to 1232.

Looking Forward

After the release of 4.2.0, the regular bugfix and improvement processes will happen.

At the same time, we will be working on the next major release of the PowerDNS Recursor (probably numbered 5.0) for which we are planning several new and exciting features aimed at moving the DNS ecosystem to a more privacy-centric and secure place. To do this, we would like to implement QNAME Minimisation and support for (longlived) TLS connections to authoritatives.

Other improvements we’d like to implement is an experimental feature where the cache is shared between the worker threads.

If you have any ideas that should be in the PowerDNS Recursor in the future, you’re welcome to open a feature request on GitHub. And if you would want to help write these features, we are still looking for people! Have a look at our careers page or send you CV and motivation to powerdns.careers@powerdns.com.

PowerDNS Recursor 4.1.11 Released

Since Spectre / Meltdown, system calls have become more expensive. In
addition, relevant versions of glibc turn out to implement pthread_cond_wait
and pthread_cond_signal in such a way that they use multiple system calls always.
There is an optimization in glibc to improve this but it is disabled.

This new setup changes our protobuf logging so it amortizes system calls so we perform
far less than one call per message.

Note that our previous RemoteLogger was configured in terms of how many
messages it would buffer. Our new code is configured in terms of how many
bytes. I have multiplied the configured numbers by 100 elsewhere (recursor
config, dnsdist config) to sort of maintain parity.

In addition, the old RemoteLogger would buffer messages while there was no
connection available. We no longer do this.

Finally new, every ‘reconnectTimeout’ seconds we will flush our buffers
opportunistically to not keep people waiting.

The changelog:

  • #7434: Add an option to export only responses over protobuf
  • #7430: Reduce systemcall usage in protobuf logging

The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

PowerDNS Authoritative Server 4.1.6 Released

This release fixes a single issue: the PowerDNS API would accept more than one CNAME record for the same name attribute and would return 204 instead of refusing and returning a 4xx error.

The changelog:

  • #7279: Prevent more than one CNAME/SOA record in the same RRset

The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

PowerDNS Recursor 4.1.10 Released

This release is only relevant when building PowerDNS Recursor from source with protobuf support disabled.

Release 4.1.10 fixes a bug where the recursor would not build when one had protobuf support disabled.

The changelog:

  • #7403: Fix compilation in handleRunningTCPQuestion without protobuf support

The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.

Domain security outside of DNS: Getting hacked administratively

This is a brief blogpost on the news that has been sent to us by many people, namely that there is a suspected Iranian group that is “hijacking DNS”. I was about to be interviewed on this subject but sadly that fell through. I did however prepare notes already, so please find some possibly useful things on the subject here.

Briefly: the weakest part of your DNS security currently likely isn’t actually DNS. It is the login (and password reset mailbox) where you manage your domains & nameserver settings. 

In general, if an attacker wants to take over a service you provide (a website, email or whatever), this requires them to change or redirect traffic between users and the targeted service.

There are four “gates” that determine how information flows from/to a named service:

  1. The nameserver configuration for a domain name (“the names of the nameservers”)
  2. What those configured nameserver names respond with.
  3. Which cables those IP addresses are routed to: the Border Gateway Protocol
  4. The actual servers and the software they run

Many attacks have historically focused on item 4, hacking either servers or software. For decades this was the easiest way. Recently however, the most used pieces of software have become more secure, and operators also update their software far more faithfully. Often this is done on their behalf by cloud providers.

Meanwhile, we are seeing a lot more attacks that involve BGP hijacks to route the (correct) IP addresses to incorrect locations.

The currently discussed attack involves items one and two. Why attack a server if you can reroute all traffic with a simple login? Once an attacker is logged in to a domain management solution they can change whatever they want.

So, how are these systems attacked? In the simplest case, an important domain is hosted at a registrar and protected only by a weak or leaked password. We may wonder how this is possible but it happens a lot. The “most important domain” for many companies was frequently registered by the founder ages ago. And unlike all new domains, it still languishes at a relatively unknown provider where it was registered back in the 1990s. This for example is the case for our own ‘powerdns.com’ domain.

And this original founder may not have been a security professional and picked ‘password123’ as his password. Or perhaps he did pick a good password, but it has now leaked in one of the massive breaches over the past decades.

Secondly, almost all DNS control panels come with a password reset solution that typically sends a reset mail.. to a preconfigured email address. This email address again might not be a well secured Gmail account but some ancient Yahoo mailbox that hasn’t been touched in years – again likely with a 1990s-era  password.

If that doesn’t work, an attacker has further options. If gaining access to the control panel of ‘importantdomain.com’ fails on the first try, and the password recovery email address is ‘john@companyfounder.com’, we can repeat the whole process over at ‘companyfounder.com’!

Perhaps someone over time improved the password for ‘importantdomain.com’ but not for the control panel of ‘companyfounder.com’. And if we control the ‘companyfounder.com’ domain, we can hijack the account recovery email, and thence take over ‘importantdomain.com’.

Beyond, even if that fails, we can repeat the whole process for the accounts not of ‘importantdomain.com’, but for the domain that contains the names of the nameservers themselves. Once an atttacker changes those, they can substitute nameservers that give answers that are implement the hijack.

The options to attack a domain administratively go on and on and on. It is therefore indeed very plausible that attackers have been able to acquire control of large numbers of domains.

So, what should operators do? The standing recommendation is of course to enable two-factor authentication for all control panels and to make sure that any remaining account recovery mailboxes are very well secured. Despite our very low opinions of Google’s stance on privacy, currently almost nothing beats a GMail account that itself is two-factor secured.

In addition, some domains can be “registry locked”, which is also highly recommended for high-profile domains.

But the most important recommendation is to audit each and every domain name of the company to see if these security measures have actually been taken. Because through the hops as described above, ‘importantdomain.com’ may in fact be hijacked via the nameserver of the domain of the mailbox of the company founder.

As a final note, it is often claimed that DNSSEC and TLS will protect against these attacks. While adding cryptography does raise the bar, and sometimes significantly, the control panels we have discussed so far include options to disable DNSSEC, while a DNS hijack enables an attacker to get fresh all new TLS certificates under their control within seconds. Using DNSSEC and TLS judiciously requires attackers to work harder, but it is no guarantee.

I hope this has been helpful!

PowerDNS Recursor 4.1.9 Released

We are very happy to announce the 4.1.9 release of the PowerDNS Recursor. This release is fixing two security issues, and addressing a shortcoming in the way incoming queries are distributed to threads under heavy load.This release fixes the following security issues:

  • PowerDNS Security Advisory 2019-01 (CVE-2019-3806): Lua hooks are not called over TCP
  • PowerDNS Security Advisory 2019-02 (CVE-2019-3807): DNSSEC validation is not performed for AA=0 responses

These issues respectively affect PowerDNS Recursor from 4.1.4 and 4.1.0, up to and including 4.1.8.  PowerDNS Recursor 4.0.x and below are not affected.

Minimal patches are available at https://downloads.powerdns.com/patches/2019-01/ and https://downloads.powerdns.com/patches/2019-02/.

The changelog:

  • #7397: Load the Lua script in the distributor thread, check signature for AA=0 answers (CVE-2019-3806, CVE-2019-3807)
  • #7377: Try another worker before failing if the first pipe was full

The tarball (signature) is available at downloads.powerdns.com and packages for CentOS 6 and 7, Debian Jessie and Stretch, Ubuntu Bionic, Trusty and Xenial are available from repo.powerdns.com.

Please send us all feedback and issues you might have via the mailing list, or in case of a bug, via GitHub.