Aller au contenu Aller au menu principal Aller au menu secondaire Aller au pied de page

About the attack on French ISPs’ DNS resolvers

Home > Observatory and resources > Expert papers > About the attack on French ISPs’ DNS resolvers

On 1 and 2 September 2020, several French ISPs (Internet Service Providers), including SFR and Bouygues, were “down”, as has been commented upon in the media. Their DNS resolvers were offline, and it does indeed seem that this was the result of an attack carried out against these resolvers. What lessons can we draw from this?

Image tweet customers SFR

One of the numerous messages on Twitter that evening

First, the facts. Let us take as an example the problem of SFR (and Numéricâble, which was acquired by SFR some time ago). Many social media users complained that their Internet access “didn’t work”. Several of them noted that when they replaced the “normal” DNS resolvers with public DNS resolvers such as those of Google or Cloudflare, access was restored. One may therefore deduce from this that the ISP’s network was working properly and only the DNS resolution service was affected. But what is a resolver? It is one of the two kinds of DNS server (the other being the authoritative name server, which will not be discussed here). It is the one that does the bulk of the work on behalf of the end user, to be able to obtain information (such as the IP address of a Web server) in exchange for a domain name. It is the machine that we all interrogate. It is automatically configured when we connect to a network. It is managed by the ISP or, in the case of an organisation’s LAN, by the organisation’s IT department. But it is also possible to explicitly change the settings, for example in order to use public resolvers, as many users did during the downtime, to be able to continue using the Internet. Organisations with their own IT department, or enthusiastic computer engineers may also have their own resolver, which gives them maximum control over the domain name resolution process. So we can see that the resolver is a crucial component. For the average user, not having a resolver is pretty much the same as not having Internet at all. Installing, configuring and above all maintaining a fast and reliable DNS resolution service is therefore one of an ISP’s essential tasks. But what happens to this resolution service during downtime? We must point out that, as with all Internet problems, whether breakdown or attack, very little precise information is made public. A general statement tends to be published (“there is a limited problem, which we are working hard to resolve”), the reliability of which is not always assured. It is therefore always difficult to analyse the problems, and this article must of necessity be cautious. By the way, full marks to Cloudflare, one of the very few Internet companies to publicly document its outages, in excellent technical articles. So it is that the major outage of Level3/CenturyLink on 30 August was not publicised at all by CenturyLink (but was well analysed, precisely by Cloudflare).

But to return to the problem of 1 and 2 September. Was only France affected? No, precise reports indicated similar problems in Belgium and the Netherlands. While a total outage of an ISP’s DNS resolvers is something that happens and has already happened several times, the bunching together in time of all these outages suggests a systemic problem, very probably a series of attacks carried out by the same group. These denial of service (DoS) attacks, which aim not to take control of a computer system but to stop it from working, are one of the scourges of the Internet, and it is very difficult to defend against them. In this case, according to certain precise witness accounts, the attackers succeeded in bringing several ISPs’ DNS resolvers to a halt by overloading them with requests.

What were the attackers’ motives? Unlike Raffles, the gentleman thief, they did not leave a calling card. We do not know who they were (attributing attacks is always very difficult and depends more on political than on technical considerations), or what their aim was.

Image tweet SFR DNS

Advice frequently given (but debatable): go to GAFA

During the attack we saw a large number of users switch to public resolvers. This allowed users to continue using the Internet, and from a technical point of view it proved that the problem was indeed a DNS resolver problem. There are a great many public resolvers, the best known ones among which are operated by the major US corporations that have cornered a large proportion of Internet services and are often referred to as “GAFA” (from the initials of Google, Amazon, Facebook and Apple), or the “Big Four”. What are the problems linked to this use of GAFA as DNS resolvers? In the first place it gives them access to even more personal data, of which they already have far too much. As noted in RFC 7626, the DNS requests that you make are very revealing of your activities. Not when you use, of course, given its widespread use, but a request for (Alcoholics Anonymous) is no doubt more sensitive. (Furthermore, if the communication with the resolver is unencrypted, anyone keeping watch along the way can read your requests.) Beyond the capturing of personal data, this use of GAFA has more strategic consequences. Since all activity on the Internet starts with DNS requests to the resolver, such dependence on GAFA places them in a position of power and may enable them for example to block certain domain names to which they might object for whatever reason.

It is highly likely that the immense majority of people who changed their settings to use the public resolvers will not revert to the previous ones. So every failure, every successful attack, increases their market share.

Not that users can be “blamed” for this. During the downtime there was really no choice if they wanted to resume their online activities. There are admittedly some non-GAFA public resolvers, such as those of FDN (which by the way was the victim of a successful attack, no doubt from the same source) but they also pose privacy problems since reaching them requires tracing a long unencrypted path on the network (unless the resolver implements encrypted protocols such as DoT (DNS over TLS), and/or DoH (DNS over HTTPS), and they are not always fast or reliable. It’s also possible to have your own private resolver at home, but in practice the current software options mean that this is really only available to computer engineers.

In conclusion, this attack has demonstrated once again the critical nature of the DNS resolver, an essential infrastructure component but one that is all too often forgotten. This component must receive the human and financial investments necessary to ensure reliable operation. Now that this attack has demonstrated the vulnerability of part of the French Internet and the risk that users will turn to GAFA, it is also important to consider this as a strategic problem.