Hacker News Reader

Hacker News

Comment by kortilla | Hacker News Reader

Parent Full thread

kortilla

Because it’s not an attack. What am I missing here?

This doesn’t feel any different than letting your domain expire.

View on HN

I think the DNS provider is missing some due diligence.

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.

My question is, after this point, can Alice reclaim her domain? Is there any way to automate verification of domain name ownership outside without DNS?

She just needs to change her nameservers at the registrar level.

She hasn't lost the domain, she's lost the ability to control its DNS at the provider she's currently using (the nameservers she set).

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.

Well, if the email address you use at the registrar is under the domain the attacker now controls, they can hijack it and potentially escalate to taking over your registrar account as well. Hopefully you have 2FA set up and your registrar enforces it properly.

And, y'know, use a separate domain for admin email.

DNS is the verification of ownership. Paying your bill and having a receipt is the verification.

Thinking back more I realize that when I first registered my domain there was no money involved. I remember when ethical discussions of charging for domain names. The justification is that buying the domain name proved ownership. I suppose it was also meant to discourage people piping dict into the registration process. There was a land rush for nouns such as pets.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.

Isn’t that this covered by e.g. OVH that sends you at least a dozen of emails before your domain expires?

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

This is the DNS records expiring rather than the domain. On most providers DNS records are provided for free as part of having other services (eg a VM) so there is no incentive for the provider to nag you about your DNS records expiring. They are very likely to nag you about your VM expiring without mentioning the DNS records.

> A bit later Bob makes an account at the same DNS provider and makes DNS records for example.com.

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.

How can the DNS provider decide if Alice actually wants Bob to set her DNS, or if Bob is doing it without permission?

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.

Verification link sent to registrant's email address. Change not processed until verification occurs.

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.

Lots and lots of people don't use their own emails on the DSN information.

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.

Registrant contact information is maintained by the registrar. The failure of a Registered Name Holder[1] to furnish up-to-date contact information with its Registrar[2] may result in the forfeiture of rights[3] up to and including the suspension or cancellation of the registration itself.[4]

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

The registar knows the person's email. But the DNS service often does not.

So the only way the DNS service can get a notification to the domain owner is if it's forwarded by the registar.

The registrant's email address is made part of the WHOIS directories, whether obfuscated by a privacy service or not. It's publicly accessible information in accordance with § 1.1(a)(i) and (a)(iv) of ICANN's stated Mission.[1]

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

I don't trust email to be secure enough for this; they may still be going out in plaintext. How do you automate DNS nameserver updates if you are migrating hundreds of domains?

Agreed. Two big challenges. But to be clear—we're talking here only about zone file management, not registration transfer (if that's what you mean by migration).

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.

From what I have seen the common way to protect against this is that the DNS service assigns you a random set of DNS servers for your zone (like ns-1887.awsdns-43.co.uk, ns-378.awsdns-47.com, ns-1029.awsdns-00.org, ns-557.awsdns-05.net for reddit.com). All of these must be added to your domain registrar.

I might misunderstand something here, but essentially, the authoritative DNS provider should only need to: (1) check for existing NS records upon registration, (2) never reassign a name server matching #1, and (3) refuse to serve DNS responses from non-assigned name servers.

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.

I believe you are correct. This is how Cloudflare fixed the issue and how every other provider could fix it. Just may be (considered) a lot of work by providers that currently throw ns01.provider.com and ns02.provider.com at everyone.

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.

This definitely feels like an attack. One time I forgot to update my name servers after removing the domain from DigitalOcean and some spammer took it over. Another time I wanted to use DigitalOcean with my domain but I can't add it, because someone else has registered it.

After removing the domain from DigitalOcean did you use the domain anywhere else? It just seems strange to me that you can forget about a domain after explicitly removing that domain from a third party provider.

I have hundreds of domains. I was deleting them from DO by dozens. One slipped through the cracks.

The difference is whether it can be fixed. An expired domain is hard because we don’t actually know the attacker isn’t legitimate until they misuse the domain. In the case of hosting hijacking, though, the domain still has a legitimate owner, and the hosting provider is giving somebody else access without that owner’s permission. I’d blame the domain owner if they pointed their domain off at some malicious host, but the point here is that it’s hosting providers we consider trusted and legitimate that are doing this, and they can stop doing it, they’re just choosing not to.

Reply on news.ycombinator.com