> There is a frequently updated list published on GitHub called “Can I take over DNS,” which has been documenting exploitability by DNS provider over the past several years.
https://github.com/indianajson/can-i-take-over-dns
Whoa, names like Digital Ocean, Google Cloud, Linode, Hurricane Electric - all classified as fully vulnerable.
This doesn’t feel any different than letting your domain expire.
What happens is Alice creates some DNS records for example.com which is registered elsewhere. Everything is fine.
At some point (maybe Alice forgets to pay the bill) the DNS records expire.
A bit later Bob makes an account at the same DNS provider and makes DNS records for example.com. This is possible because Alice's records have been deleted. Bob has now effectively taken over example.com
The due diligence missing is that the provider could have kept a record that the DNS records were owned by Alice. They should have been asking questions (or doing additional validation) when Bob tried to create new ones for example.com.
So as sibling says it's a case of changing the ns to some other provider, or else I suppose a support case to somehow prove you do own the domain, so please assign control back to your account.
Isn’t that this covered by e.g. OVH that sends you at least a dozen of emails before your domain expires?
In this "attack" the domain is not expired.
A dns company that goes into commercial relationship with a customer should try to prevent themselves from being used in a crime. DNS registrars are already very much used to this since fraudulent registrations are common place, and top registries generally demand some minimum standards when dealing with it. It is not a major leap to demand something similar from dns services.
The issue is kind of similar to account creation bugs, where a user name ALICE (all caps) can masquerader as user Alice. If the new user claims to be alice, they either have to log in with the old account (alt using an account restoration process), or they have to validate that they are in control of the domain name. Validating a sub domain is fairly easy, but even a bare domain is doable using unique ns records, alternatively using any third-party validations (e-id, company registrations, etc.) that other part of society is already using for validation.
I see this as a purely dns industry problem that can be solved using existing tools and expectations.
You just shouldn't point your domain into DNS providers that aren't providing DNS for you. If you go and add them to your domain, it's reasonable for the provider to decide that what they are doing is correct.
Anything you add here (are people thinking about some hard to write TXT record? It surely looks like so) will break more things than it fixes.
This is generally the level of diligence (i.e. emailed verification link) that registrars are held to. DNS providers should be held to the same when the requesting account isn't the same account that created the 'earlier' zone file for a given domain at the very same provider.
Maybe we should add a requirement that the zone register sends some notification on behalf of the DNS provider. That could work, at least on the TLD level.
Point being that, short of transfer Auth-Codes[5], a verification link sent to the registrant's email address by the DNS provider is the functional equivalent of nearly the most that a registrar may be required to do in order to contact and/or verify a registrant.
[1] https://www.icann.org/resources/pages/ra-agreement-2009-05-2...
[2] https://www.icann.org/resources/pages/ra-agreement-2009-05-2...
[3] https://www.icann.org/resources/pages/benefits-2013-09-16-en
[4] https://www.icann.org/resources/pages/registration-data-accu...
[5] https://www.icann.org/resources/pages/auth-2013-05-03-en
So the only way the DNS service can get a notification to the domain owner is if it's forwarded by the registar.
The DNS provider absolutely can send a notification to the registrant without having to 'go through' (meanining interact with) the registrar. Even a third-party privacy service merely exists as a notification broker. Any notification sent by the DNS provider would simply pass through onto the registrant directly.
[1] https://www.icann.org/resources/pages/governance/bylaws-en/#...
In the case of a large-scale, multi-domain authoritative nameservers assignment change, only the DNS provider would be able to facilitate the process programmatically. And at that kind of scale (i.e. hundreds of domains), one would hope verification would not only be obtained through, but require some form of human-to-human contact coupled with thoroughly documented scope.
It seems like the vulnerable providers either respond from or assign prior NS hosts, sometimes with randomized lottery thrown in, which only reduces the takeover probability.
Krebs's article also mentions it:
>What did DNS providers that have struggled with this issue in the past do to address these authentication challenges? The security firms said that to claim a domain name, the best practice providers gave the account holder random name servers that required a change at the registrar before the domains could go live. They also found the best practice providers used various mechanisms to ensure that the newly assigned name server hosts did not match previous name server assignments.