hckrnws
So you point your nameservers at a third party, let your account with that third party expire, then someone later on can create an account at third party and resume control of the DNS zone? I mean yeah, but you mustn't care much about the domain and any credibility it has will evaporate quickly.
I had something similar happen to a client using Cloudflare. The attacker somehow was able to establish a new account(s) at CF that used the same free nameservers as my client. When my client's domain expired the attackers added the domain in their CF account, and were then able to control DNS. I reported it to CF security but I'm not sure if the loophole was closed. What I don't know is how the attacker was able to get an account with the same nameservers which are seemingly assigned at random (maybe not?). Maybe they just own/operate thousands of CF accounts?
Update: CF claims to have closed this loophole: https://github.com/indianajson/can-i-take-over-dns/issues/10
Hate to admit it, but I had several domains get semi-hijacked using a cloudflare(esq?) technique, it went like this...
registered a bunch of domain names, had my registar auto set to make all new registered domains auto point to cloudflare..
some months later I found that a domain was pulling up some shady site..
So I never went into my cloudflare account and added the domains there, but the dns from uniregistry was pointing to alex.cloudflare.. and so sneaky perps I assume created a CF account and added my domain name there and then pointed it to their server..
I reported this - never heard back. found the issue with another domain, reported it, never heard back.. got busy.. found another domain name that had the same 'exploit', running through CF... didn't bother reporting it.
No longer auto-pointing to cloudflare for new domains.
Actually no longer pointing any new domains to CF but that's other reasons.
Neat to see how people find ways of exploiting wierd misconfigs, I gave them major props for pulling it off, and gave CF non-props for not responding with 'we found person X who was pointing your domain without permission, and found all associated..' whatever.
> I reported this - never heard back. found the issue with another domain, reported it, never heard back.. got busy.. found another domain name that had the same 'exploit', running through CF
To me this indicates it may have been a widespread problem. Really calls into question this hypothesis and the categorization of it being an "edge case":
>At this point, it would take upwards of 450 Cloudflare accounts to get an account that matches one of your specific vulnerable domain's nameservers. Additionally, in my experience, there is only around a 10% chance of success even if the nameservers assigned to your account match the domain. While this is a far cry from the theoretical 200,000 accounts previously believed necessary, that's still a lot of work to perform a targeted takeover. *https://github.com/indianajson/can-i-take-over-dns/issues/10
How exactly does this happen in practice? When you add a domain to a Cloudflare account, can that domain actually "expire" and no longer be attached to the account? Or can the account itself and all the domains in it expire?
I don't see why Cloudflare would do this. If you stop paying for a paid tier, I figure your account and the domains associated with it would still exist in the free tier. I can see how this could happen if you manually remove the domain from your account but don't change the nameservers (at least before they fixed it so the previous nameservers will never be assigned to the same domain in the future), but when would Cloudflare automatically expire the domains from an account or automatically expire an account itself?
(I can potentially see this happening for providers that don't have free tiers.)
> How exactly does this happen in practice? When you add a domain to a Cloudflare account, can that domain actually "expire" and no longer be attached to the account?
Basically yes. When you have a domain in setup in CF (free tier), and the domain expires CF will inform you "nameservers no longer point to CF" and then if you do nothing, CF will remove that domain from your account. This process might have been altered, I'm sure someone will correct me if I'm wrong.
Not sure if you're emphasizing "claims" because you find it dubious so perhaps it's worth noting that the statement is coming from someone who claims (heh) to be an engineer at CF rather than someone working in PR/marketing. In case that affects the reader's view of the statement.
I don't necessarily find it dubious. I emphasized because I have not verified personally that the exploit is closed nor would that even be feasible (for me or anyone outside CF). I also previously reported this issue to multiple people at CF, offered more information and it was seemingly ignored/buried until this project called them out.
Also, when reading through the thread I shared it doesn't seem like CF or the researchers recognized the extent of the initial problem when they initially classified as "edge case". My client who was targeted was small and insignificant which caused me to doubt this an "edge case". Just my speculation.
I don't understand what the "loophole" is. You say the domain expired...?
1. Domain owner signs up for CF
2. CF assigns "semi permanent" nameservers like: bob.cloudflare.com
3. Attacker creates CF account and somehow gets assigned the same nameserver.
4. Once the domain expires, CF allows it to be assigned to a new CF account.
5. Domain comes back online with same nameservers.
6. Attacker adds domain to their CF account and now controls DNS because the nameservers stayed the same but CF allowed a new controlling entity.]
I butchered that explanation but whether that's a loophole, exploit or just an "issue" I'm glad it's solved.
CF says they now no longer allow previously used nameservers to be used again. The only problem with this is if someone swaps CF accounts hundreds/thousands of times and "runs out" of custom names.
I'm replying to my own comment as I've had some new thoughts on how these attackers could have pulled it off.
1. Attacker registers hundreds/thousands of free CF accounts.
2. Each account gets assigned random CG nameservers (some dupes obviously)
3. Attacker than loads the assigned nameservers into a tool that looks for domains using those nameservers.
4. Attacker monitors those domains for accidental expirations.
5. Once expired, attacker adds domain in the CF account that matches the existing nameservers.
6. Once renewed domain comes back online, attacker controls DNS at Cloudflare.
> CF says they now no longer allow previously used nameservers to be used again. The only problem with this is if someone swaps CF accounts hundreds/thousands of times and "runs out" of custom names.
It’s not necessary for Cloudflare to remember or to reject all previously assigned name servers: Cloudflare can simply fetch the domain’s cached NS records before DNS enrollment and refuse to assign them again.
> Once the domain expires
If the domain is expired, someone else can buy it. This is normal. I don't understand where the attack is.
From TFA:
> 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.
Because it’s not an attack. What am I missing here?
This doesn’t feel any different than letting your domain expire.
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.
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.
Comment was deleted :(
> 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?
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.
> 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 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.
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 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.
She just needs to change her nameservers at the registrar level.
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.
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.
GoDaddy and SquareSpace (now that Google's DNS shifted) are notable by not being listed.
That's probably because they won't host your DNS without having the domain registered with them.
UK.GOV has a good guide on "Keeping your domain name secure." https://www.gov.uk/guidance/keeping-your-domain-name-secure
TFA reminds me that most people miss the basics (eventually letting their domain expire), which is a much bigger threat than domain takeover:
- Enable 2FA
- Check that your domain is set to auto renew
- Lock your domain from transfer
- Check your payment details
- Use a reputable domain registrar
- Be sure you actually own your domain
- Extend your domain registration
- Be aware of any TLD-specific rules around renewals
from: https://onlineornot.com/guidelines-to-help-avoid-losing-your...
If your domain name is critical to you, pay 10 years in advance where possible, and still extend every year, to keep this 10 year buffer.
I did a 100 year registration. This was under $1;000 about 10 years ago. The status only show 10 year increments. I did it with network solutions.
Do you worry about the registra going down during that time? I guess ICANNs records should include the lease length and as long as you can prove you exist at the correct physical address or whatever you can "reassign" it to a down stream registra?
The domain pre-exists ICANN. I guess I’m counting on money and receipts still being being valid. If I ever find myself with a fear that hints at a breakdown of society or the monetary system I pull back and reorient my perspective.
If society fails planning likely won’t help.
I think a lot of people make bets like this that are very black and white. It's also very possible that something goes wrong at the registrar and your receipts aren't accepted because they don't have any records of it on their end. And society doesn't collapse but you're still screwed.
In this case I think 30+ years of ssl certs and other ephemera would help in this world where network solutions disappears but there is still an appeal to paperwork.
Sometimes luck is all one should relay on.
100 years is too long, you will completely forget to renew
I think I’m also auto paying. I figure I’m giving a 100 year head start on finding the paperwork.
I have told my kids but who knows if there listening. I’m in process of buying a sailboat and wondering how important a domain name is.
It’s safer to regularly have a transaction with the registrar. This serves as a sanity check that they keep record of your registration. Without any interaction, a lot can go wrong over decades, and you might notice only too late.
Comment was deleted :(
Ironic as last I checked (admittedly 2016) .uk domain transfers saw no verification: https://pricey.uk/blog/uk-domain-transfers-are-scary/
> I registered a new domain at one registrar and immediately asked they change the IPS tag to another. A coworker [saw] ... the tag change, but then I got distracted looking for cake/looking over their shoulder. They set up a new account at the second registrar and claimed the domain, using no secret information and without either registrar or Nominet gaining my consent.
To be clear, the IPS was (is?) publicly visible. So you could poll a list of domains looking for it.
It's worth noting that even if you registered .co.uk with e.g. Gandi, you still get a separate Nominet account with it's own authentication. It doesn't matter if you add 2FA etc - after such a transfer, the domain was registered to a different nominet account.
This is how I understand the exploit, can someone please confirm if I have the right idea?
1. I register a domain name -- example.com -- with a registrar like NameCheap. They tell Network Solutions (the .com registry) to add records on my behalf like below, which means the rest of the internet asks NameCheap's nameservers when they want to look up my domain.
example.com. 172800 IN NS ns1.namecheaphosting.com
example.com. 172800 IN NS ns2.namecheaphosting.com
example.com. 172800 IN NS ns1.he.net
example.com. 172800 IN NS ns2.he.net
4. Now this HE customer has control over my domain... because I told my registrar to change the NS records to HE's nameservers. Why would I ever do that?
My understanding is this should never happen, I have no reason why I'd want to make such a change. ICANN have a policy on domain transfer between registrars: https://www.icann.org/resources/pages/transfer-policy-2016-0... -- and transferring a domain should only be done with the gaining registrar (HE in my example) putting an explicit request to the losing registar (NameCheap in my example), and the losing registrar getting to decide yes or no to the transfer.
So... how are there a million or more domains at risk this way? Is it old practises that haven't been corrected? How would this work?
This is kinda how it works, but not how it would work in practice.
The issue would be more like:
1. Register your domain with namecheap, and you want to have digital ocean run your DNS, so you point the domain to use their name servers.
2. A few months later, you decide to stop using digital ocean DNS, so you delete all your records… but you forget to change your NS record at namecheap, so now someone else can now add that DNS name to their digital ocean account.
This would only happen if your aren’t actively using the DNS name, which would allow you to have it point to a NS you aren’t controlling.
Gitlab also had same issue few weeks ago. Gitlab, once static pages are published, gives you a URL with gitlab.io ending. You can use your custom domain or subdomain by pointing CNAME or A record to Gitlab.
What users would do is, add DNS records to their DNS Manager to point their custom domain to Gitlab Pages, later will delete the Gitlab pages when not wanted any more. Scammer will simply point that same domain to his fake repository, thus hijacking customer domain.
Gitlab then made customer add a Txt Record for verification of domain. Scammer's txt record value is different from customer txt record, scammer can't modify DNS records.
Is there a similar mitigation that would work when you're using the 3rd party nameservers (a la Cloudflare), and not just a CNAME?
But the easy fix is just to change the NS records back to something you control. Somehow I don’t understand the problem.
It's easy to fix if you own the domain, but it still happens. The idea is to find ways to address the problem with the DNS providers so that it doesn't happen at all.
The point is some people will forget.
It is not a huge security hole, but just something that will cause issues for some people.
From what I understand the issue is more that people point domain to a DNS service, use it for a while and then remove their account (/domain from the account). Now someone else can add it to their account.
This is unlikely to be an issue on their primary domain but could be for e.g. subdomains or some marketing domains that aren't really in use anymore. Or cases where domain is just be squatted.
Namecheap is not a losing registrar, HE is not a gaining registrar, and the transaction you describe with Namecheap requesting that they update your registration's nameservers to HE's is not a domain transfer. You're conflating registration with nameserver assignment.
I'm not trying to conflate it, but I'm trying to imagine why you would ever switch your domain's NS entries away from your current registrar's nameservers, and the only reason I can think of is that you'd want a registrar transfer -- which should and I think does have more ownership checks around it.
However, other posters have given a more plausible example: you have server hosting with someone who isn't also a registrar, so for simplified management, you get your registrar to point your domain's nameserver at the server hosting company's nameservers, delegating it all to them... now you just need one customer portal to update all your hosting and DNS entries... and then you leave the hosting company (maybe the bill's too much), and you also forget to clean up the NS records, pointing them back to the real registrar's nameservers, so they're still pointing at this server hosting company you're no longer a customer of.
The hosting company isn't a registrar and is under no obligation to follow ICANN policies, so they can give the domain to some other customer of theirs without doing any verification. (I'm not sure they can do domain ownership validation, if they're not a registrar themselves)
> so they can give the domain to some other customer of theirs without doing any verification
Hosting company can not "give" the domain to anybody. If domain is still pointing to Hosting with NS records, anybody could make an account at Hosting, and add that domain. Now that scammer controls whats visible at Domain, but he is not yet the owner of domain.
Owner is who control and can change NS records. Scammer can change all other records, but not NS. NS is at original domain registrar. Original owner can very easily change the NS and cut the scammer out of everything (& should).
Gitlab used to be like this. You add a domain to Gitlab. You add an A record to your domain registrar or NS Manager. Now your domain shows your Gitlab Page. After few months, you don't want the pages anymore. You delete the project from Gitlab. You ignore to delete the A Record. Scammer adds that domain to his Gitlab, and shows his content at your domain.
Now Gitlab asks you to add a verification TXT record when adding any domain. Scammer's veri record is different. He can't prove that he owns the domain.
> Hosting company can not "give" the domain to anybody.
> Gitlab used to be like this
That's what I'm saying. Hosters can "give" a domain (i.e. control of that domain's records on their nameserver only) to someone else, because they're not registrars and aren't _required_ by some painful business contract with ICANN to have to take change of ownership seriously.
They should require a domain validation challenge to add a new domain, like your Gitlab example, but it doesn't seem like anyone can make them.
So therefore the onus is currently on the domain owner not to leave their domains' NS records pointing at nameservers they don't control!
Hosting can't make the challenge. Only way to prove is to make a TXT or cname record. Anybody where tha NS is pointing to, can make any DNS records.
Its like you put a lock (NS) on your box (Domain). After few months you don't care about that box anymore and leave that key in the wild. Anybody can pick that key and use the box. The box holder (domain registrar) can't make you verify that you are the original owner 'by' asking you to open the box, because by default, anybody who has key, can open the box. The correct way & responsible way is to destroy the box (delete the domain) or at least destroy the key (unpoint the third party NS records).
> the onus is currently on the domain owner not to leave their domains' NS records pointing at nameservers they don't control!
That's exactly right. That is how this "attack" happens. Bad actor exploits registrant's abandoned yet still authoritative third-party nameservers assignment.
Discussion elsewhere in this thread[1] of how some of that responsibility/risk could be spread/shifted onto the DNS provider.
I personally keep my domain registrations and zone files separate as a matter of security policy. I place as much importance on vetting reputable DNS providers as I do registrars. Nameserver assignment remains with the ICANN-accredited registrar.
(I would also never maintain a registration nor a zone file with a web/cloud hosting service.)
> why you would ever switch your domain's NS entries away from your current registrar's nameservers,
I want my domains at dynadot or namecheap or hexonet, but want CloudFlare to manage all DNS. CF doesn't support al ccTLDs.
I've often run my registrars separate from my nameservers. Maybe I'm self hosting my nameservers. Maybe the nameservers are tied to the rest of my hosting (for ease of dynamic hosting) but want the ability to rapidly migrate if the hosting provider goes down. If the registrar is my nameserver host, good luck changing the SOA and NS records when SHTF at your host.
Part of this problem is authoritative dns server operators not sharding their zones.
The only provider I know who does this correctly is AWS Route 53. Your zone gets assigned 4 unique authoritative servers from a set of namespaced shards. eg ns-2048.awsdns-64.com
Someone else can create a zone for the same domain but will map to different shard so no real world effect.
Always surprising to me that hardly any providers do it.
Azure DNS does the same.
I've just launched a DNS hosting provider ( https://www.ptrdns.net ) and this is one of the problems I'm worried about. With the PowerDNS backend I'm using, once a zone is added PowerDNS will respond to queries for its record regardless of the nameserver the queries are sent to. One can, for example, query the IP address of the nameserver to get a response.
The Route 53 technique of assigning random server names looks a bit like the technique of creating virtual hosts in a nginx server, but it looks like this is a custom AWS implementation and not something that comes out of the box in any DNS server software I know.
Somewhat related question: I have a (obscure) domain that I'm planning to let expire soon. Is there anything I could / should do to stop it being used for questionable purposes?
Create a permanent redirect to any other site should transfer any search "scores" onto the new site. You can also request google to de-list the domain from search, which should reset any value that the domain has acquired from the time you owned it.
If the account is validated on large platforms, it should be a good idea to remove those from the account as a way to signal the platform that it is no longer validated on that site.
Some TLDs/registrars let you park registrations. They won't appear in the DNS, but they can't be registered by anyone else. Or there is a delegation to some internal hosting service that the registrar operates that is an empty zone (i.e. no A, MX, etc.) so there is nothing reachable.
I've done this with zones I've had for a while - it sucks since you want to be a good net citizen and not let the zones be used for spam/attacks. You end up paying for a domain for years after you stopped needing it.
Delete any accounts you've created using that domain, those could be taken over by the new owner. Especially important if you ever used email on the domain.
Once you let your domain expire you no longer have any say over what happens with the domain so no, not really.
I would just recommend cleansing the domain from any systems you may have used it on and ensuring that you have no other technical ties the domain. Treat it just like any other domain you do not own.
First, let ArchiveTeam know, so that we can save anything public you have on the domain to archive.org so it will persist beyond the expiry.
If you don’t own the domain then you have no say over what’s it’s used for. The only thing you can do is not to let it expire.
Isn’t this the same as the spammy bear attack?
What happens if you set your name servers to e.g. Digital Ocean then go to Digital Ocean and try to add your domain name there but you find that an attacker has already created that domain name under their account? They were watching the name server records on your domain.
I'd change the registration info at the registrar - park the zone if you must. That would at least stop the attack from continuing (caches would still have the attacker's responses).
The best defense is to set up the delegation at the host first, then set up the delegation information at the registrar. A stub zone is could be run indefinitely (as long as there were no name collisions) before a formal delegation from a TLD is set up. Gives you time to set things up the way you want before it is reachable from global DNS tree.
I always set up at least the basics of the zone first, then point the nameservers. Why would you point to nameservers that know nothing of the zone?!
From TFA:
> DNSMadeEasy founder and senior vice president Steve Job
That name surprised me. I thought it couldn't possibly be real. I looked it up and apparently that's actually his name; presumably no relation to the plural one who ran Apple. Most articles seem to write his first name with an N to make it more believable.
My tired mind had to read your comment a couple of times before realising you actually meant Steven, not Nsteve.
The Gell-Mann Amnesia is strong in this story and thead.
As I posted on Krebs' article:
This is neither news nor new. There have been prior panics around this “water is wet” type issue going back at least a decade.
(Search up “Floating Domains – Taking Over 20K DigitalOcean Domains via a Lax Domain Import System” – and others).
I also wrote about this on CircleID from the DNS operator’s perspective (“Nameserver Operators Need the Ability to “Disavow” Domains”) – after this same issue was used to DDoS attack another DNS provider by delegating a domain to their DNS servers without having setup an account there, and then doing a DNS reflection attack on that domain. That was over ten years ago.
The fact that people can delegate their own domains to somebody else’s nameservers without ever properly setting up a zone on those nameservers, or ever keeping track of where THEIR OWN DOMAINS point is 100% the responsibility of the domain owner – and to varying degrees a function of their REGISTRAR – who is the only entity that has any control over it.
It’s a weird flex for corporate registrars who purport to be “high touch” and exclusive, to simply shrug their shoulders and turn a blind eye to their own clients’ obviously broken and vulnerable nameserver delegations.
For our part this is specifically one of things we actively monitor and alert our clients about.
Crafted by Rajat
Source Code