Tell HN: Please update your DNS records when abandoning servers | Hacker News Reader

Tell HN: Please update your DNS records when abandoning servers

177 pointsmwgarcia66 comments

I got contacted by someone wanting to buy the domain and was thoroughly surprised. It seems that the owner had it pointed to a Linode instance/IP which was then abandoned and was subsequently "inherited" by me.

http://unstoppable.com/

https://whois.domaintools.com/unstoppable.com

https://reverseip.domaintools.com/search/?q=unstoppable.com

View on HN

Yep.

A few years ago I had a server on DigitalOcean and stopped using it. I forgot to remove the A record for it on a sub-domain connected to my main site and suddenly a sub-domain on my main site was serving ~400,000 pirated PDFs because the old server's IP address was in control by someone else.

I wrote about it here: https://nickjanetakis.com/blog/a-recycled-ip-address-caused-...

And it was discussed on HN back then: https://news.ycombinator.com/item?id=17020944

Then another DNS related issue happened 6 months ago where someone thought I owned a domain they used to have: https://nickjanetakis.com/blog/at-first-i-thought-someone-wa...

In this 2nd case someone else forgot to update an old domain redirect and I ended up being the recipient.

Although in OP's case someone wanted to buy the domain, so maybe don't update your DNS records, in case your subdomain becomes worth a lot of cash?

I mean hell, create a bunch of random bogus A records too just in case any of them wins the lottery ticket. A records are free, after all.

I think you have it backwards. OP didn't own the domain, just inherited the IP address through their host. The actual domain owner is losing out on the sale.

Yup. You could however try to middle-man the sale if you could find the actual domain owner.

Is an open commons to be treated like this by civilized people? Why throw garbage in the streets? It makes no sense or else is motivated by reaction and negativity.

It seems either desperate, or hostile, or so casual as to be literally stupid.

I see I have it backwards as another comment noted.

Why is it hostile though? A records are under your own domain. Creating a bunch of bogus A records for sale is the digital equivalent of a garage sale on your front lawn. You're not actually squatting any TLDs, which would be the digital equivalent of a real estate ghost town.

I was in a similar situation for a while. It seems Google's finally updated their index and dropped all of the PDFs, but for a while there it was pretty tough to find the actual content on my (admittedly mediocre) site.

On a related note, you should also set proper DNS on domains you do not use!

https://www.gov.uk/guidance/protect-domains-that-dont-send-e...

Have never considered that. Thanks.

While domain registrants should certainly be careful that their DNS records point to trusted servers only and should definitely remove any stale DNS entries, we should also configure our web-servers to return successful response for specific hostnames only and error/no response for everything else. Here is roughly how the configuration for, say, https://example.com/, would look like:

  sudo mkdir /etc/nginx/ssl
  sudo openssl req -x509 -newkey rsa:4096 -nodes -keyout /etc/nginx/ssl/key.pem -out /etc/nginx/ssl/cert.pem -days 365 -subj "/CN=localhost"

  echo "server {
      listen 80 default_server;
      listen [::]:80 default_server;
      listen 443 ssl default_server;
      listen [::]:443 ssl default_server;
      ssl_certificate /etc/nginx/ssl/cert.pem;
      ssl_certificate_key /etc/nginx/ssl/key.pem;
      return 444;
  }" > /etc/nginx/sites-enabled/default

  echo "server {
      listen 443 ssl;
      listen [::]:443 ssl;
      server_name example.com;
      ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
      ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
      root /var/www/example.com;
  }
  server {
      listen 80;
      listen [::]:80;
      server_name example.com;
      return 301 https://example.com$request_uri;
  }" > /etc/nginx/sites-enabled/example.com

The self-signed certificate for the default_server is okay. The client will get a TLS certificate issue. That's fine because we don't anyone to be using the default_server anyway. If the client decides to proceed despite the TLS certificate issue, then the 'return 444' directive would close the connection without response.

The reverse is the problem here: your domain, somebody elses server

> The reverse is the problem here: your domain, somebody elses server

Why would my domain point to somebody else's server?

The original post says, "It seems that the owner had it pointed to a Linode instance/IP which was then abandoned and was subsequently "inherited" by me."

As per my reading of this, it sounds like the domain name is owned by someone else that points to an IP address of the poster's server. My comment was meant for a scenario like this where if someone else's domain name points to my server's IP address and a visitor visits my web server via that domain name, then my server will close the connection without response.

The OP is putting himself in the domain owner's shoes. It's a mild inconvenience for the OP, but what if the OP was a bad guy? He could have setup a site that looked like the old one saying "unstoppable is back! Log in and update your payment info!" but stole credit card info or passwords.

The owner of the domain should have been more careful to delete their A records once they no longer owned the IP address. IPv4 addresses are finite and it's not surprising for a housing provider to recycle them.

Thank you for clarifying the OP's intention. It indeed makes sense to advise the domain registrants to be careful about cleaning up stale DNS entries.

Yes, if a domain points to IP addresses of servers we do not control, many bad things can happen. Here is a really interesting security disclosure related to stale DNS entries that comes to my mind: https://thehackernews.com/2019/04/subdomain-microsoft-azure.... .

> "It seems that the owner had it pointed to a Linode instance/IP which was then abandoned and was subsequently "inherited" by me."

answers the "Why would my domain point to somebody else's server?", doesn't it?

That fixes a web-server from serving HTTP responses to other hostnames but none of the other thousand problems

You can't: the web server has to accept the connection to know the hostname. The best you can do is close the connection immediately without sending a response if it's an unknown hostname.

I believe that at least with Apache and nginx doing this requires using a non-default module.

Indeed the web server has to accept the connection, check the hostname, and return an error or close the connection without response.

I think you are over complicating things. You just need a default virtual host that displays a "domain not configured" page. This is what we did when I ran a hosting company.

The parent comment originally said "just don't accept HTTP connections for unknown hostnames".

that doesn't prevent the "a domain you own points at someone elses server and they can do unsavory things with it". (Especially bad if it's a subdomain, or a domain linked to one of your others.) it's not for OPs sake, but for the domain owners sake.

My domain name is under my control and therefore should not point to servers I do not trust. If one's domain name points to an untrusted server, a very fundamental mistake has been made and no amount of configuration can fix the issues associated with it.

Webmasters we have two things in control:

1. Their domain name. It should point to trusted servers only.

2. Their web server. It should be configured to return successful responses only for domain names they care about and no response/error for everything else.

The configuration fixing it for the domain owner is very simple: update your DNS so it doesn't point to a server you don't control anymore. OP observed someone made that mistake and is posting a PSA "hey, remember that that's a thing and don't do it because it's bad". If that's obvious to you and you never make that mistake, great, you are not the target, but real-world experience shows that it happens all the time.

Just curious - can you explain #2 ? I get that someone can register some freebitcoin.xyz and point to your IP, but the content is still controlled by you, right? What is the security angle here if your host returned a static index.html to any host? Some CSRF?

Edit: only asking for cases where #1 does not apply - that is you don’t have domains or sub-domains pointing at rogue IPs

If it's just an empty placeholder, not much. if it's your actual site or app there could be various issues, e.g. with search engines, people actually using/being tricked into using the app through the wrong domain and having cookies associated wrongly, bad content on subdomains being associated with you, ...

This is a great suggestion and I'll set up servers this way from now on rather than allow default fallback content to be served. Others are quick to point out this only fixes half the problem, well that's 50% more than nothing. For the other 50% you have control of your own DNS records, keep them up to date. And if everyone did this mismatching hostname/content would be a thing of the past.

(sub)domain takeover is one of the more common security issues affecting organisations, and bounty programmes often pay-out for these issues.

https://www.hackerone.com/blog/Guide-Subdomain-Takeovers https://github.com/EdOverflow/can-i-take-over-xyz

And to explain the severity: if you control a subdomain, you're potentially getting trusted access to cookies, cross-origin requests, and so on.

This whas not subdomain takeover though.

No, I know - but the impact is the same.

I've also had people abandon domains onto my nameservers and keep renewing them for years, which is similar.

They are now a sort of pseudo-controlled domain now.

This is a common issue in AWS too. User sets up a Route53 entry pointed at an S3 bucket, then later deletes the bucket but not the domain. Someone else then creates the same bucket again in their account (bucket names are globally reserved) and suddenly they can host content on a domain they don't own.

How can they know the name of the original bucket? Can the route53 entry be queried?

So how did the prospective buyer even find your e-mail address...?

If I were you I would configure my web server so that it will only accept HTTP connections for hostnames that are your own. If you had done that then the buyer would probably never have found you.

Do a dns lookup for a large website. Then google that up address. There is a good chance you will see the domain name in one of the results

That is not what happened in this particular case though.

The Whois record showed the title of my page which has my name lol. They contacted me in LinkedIn using that. Directed them to use the GoDaddy contact thing based on Whois. EDIT: I got it mixed up, they just browsed unstoppable.com which was not filtered out by my server.

And yeah I should have had server_name in my nginx config in the first place. This time I did some fun with multiple roots/domains on one server: one for unstoppable.com and the other for my actual website.

I have a dedicated box just for this kind of thing. When I'm offlining names I point them all to this one. It marks all pages as 410 (except for stuff I want to 300). It catches mail. Has a little script to help me verify necessary settings.

So, while winding down or pending removal it's basically a dead-end parking page.

I once inherited an ip block the previous owner never pointed his SEO network domains away from. I setup a wildcard, captured all the traffic and made good coin for quite a while.

Care to share how exactly you earned from that? :) SEO Network domains (or link blogs) are usually built for Google crawlers, not actual human eyeballs. They don’t rank high, they boost the rank of other sites.

Adult content(before and after), and it was about ten years ago. Odd part was, the owner renewed some of the domains, so I got this income for two years.

I don't see why you should care.

Don't allow the requests from non hosted domains on your server.

You don't control the DNS' you can't rely on people to updated them.

Totally agree. I failed to add server_name to my nginx config. IIRC I wrongly assumed that it can only accept one domain/pattern and didn't want to bother so I can simplify testing using localhost.

I think the concern is for the domain owner who could get a visit from the government if “their” server is serving something illegal.

The domain owner should care, because OP could misuse the domain.

Right, the domain owner should care. Not OP.

But OP does care about others. If you own a domain it's a non-obvious vulnerability.

Thanks OP!

I've had the reverse, people shutdown small private servers and they change their DNS to the ip of our community forums.

I think they want to "do right by the community" not realizing almost nothing works when people hit the old domain name.

If any of y'all need a CLI tool to check your DNS propagation check out dug!

Repo: https://git.kaijucode.com/matt/dug HN Post about dug: https://news.ycombinator.com/item?id=25618012

So obvious in retrospect, and so little talked about. Could something be done with the DNS / IP protocols that would improve this?

In the protocols themselves I wouldn't think so because how would it know you no longer paid for that ip.

Something digitalocean could do? Once an ip is assigned to another customer either: warn, warn/disable dns, change dns automatically

The owner of the domain pointed the traffic where he wanted it to go.

The protocols are working as intended.

This is the fundamental problem in security. You have no idea that there is a problem until after you get robbed.

If anyone needs to check the state of their DNS on a bunch of servers at once check out dug: https://git.kaijucode.com/matt/dug

This is more commonly referred to as a 'sub-domain takeover' . You could make a good living finding these and reporting them to bug bounty programs.

If this domain was somehow related to UnstoppableDomains project, the irony is beyond anything.

Another reason to require https?

If somebody is in control of the content served via the domain, as this is the case, they can obtain a valid HTTPS certificate

Not necessarily. You can always generate self-singed certificate, yes, but trusted issuers such as Let's Encrypt often use challenges that require you to temporarily modify the DNS record - that wouldn't be possible in this case.

The HTTP-01 challenge for example can be performed on any domain pointing to a machine you control, without the need to further modify DNS records, resulting in a valid certificate accepted by most browsers.

https://letsencrypt.org/docs/challenge-types/

Care to explain how on earth you believe this is connected to https at all?

Because you wouldn’t then serve content for a domain for which there is no cert installed

I agree, but there's something related which I feel is very weird and I wonder if I'm the rule or the exception: I have close to 100 domains to my name(for relatable reasons, i.e. "hey I have a wix site can you please add a domain to it, idk how") in addition to a dozen servers. Some of those domains are completely unused but could be pretty valuable to some people. No one has ever contacted me about either one of them.

I only had about 5 domains and two different Chinese people contacted me about buying 2 of them (4-letter domains)... I sold one for a couple of hundreds.

That seems really low unless the domains were nonsense random letters.

I sold a 4-letter “acronym” .com (acquired in a merger) on behalf my employer about 5 years ago for a few hundred thousand USD.

Yes it was random letters, and the domain isn't in used yet (and that was years ago)... I guess you got lucky that your random letters became/were an acronym.

If you want someone to buy your domains, you need to list them on the domain marketplaces, e.g. Sedo and GoDaddy.

Reply on news.ycombinator.com