Tell HN: Please update your DNS records when abandoning servers

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

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.

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.

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.

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

Another reason to require https?

(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

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.

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

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

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.

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

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.

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.