← Back to context

Comment by tannhaeuser

2 years ago

> fear of changing DNS settings

Is that really a thing, with HNers of all people? You just use your registrar's/nameserver operator's web tool to point your DNS name to a new IP. Transferring your DNS to a new registrar might be a bit more involved but is guaranteed to be also possible by domain market regulation. Or maybe it is a problem of cache invalidation and/or lack of control over exact timing of DNS switchover? Or, idk, possibly Google-owned TLDs like .dev require Google Domains as registrar? Or does Google Domains (or GoDaddy or other big registrar) make transferring your domain difficult in a dark pattern way? Doubt it though, if even changing pointed to IPs appears difficult, which however shouldn't be something a registrar would have an interest in making difficult.

7 comments

tannhaeuser

Reply
echelon  2 years ago

> Is that really a thing, with HNers of all people?

You want it to be hitless. Unfortunately DNS can take days to fully propagate and you may not see mistakes until it's too late to fix them. This can cause horrifying outages.

HNers should be respectful of DNS changes and plan accordingly.

  • neurostimulant  2 years ago

    I always setup a reverse proxy on the old server that tunnel all TCP traffics on port 80 and 443 to the new server whenever I migrated a website for this reason. Some network really take their time updating their DNS cache, even if your domain has low TTL.

  • zakki  2 years ago

    You can change your DNS TTL to let say 5 minutes before you move to new IP. You can change it 3 days before the movement(?).

    • scott_w  2 years ago

      A story from 10 years ago providing services to the education sector:

      I did exactly what you suggested, even leaving extra time (a full weekend!) for the DNS changes to propagate. What happened?

      Turns out local authorities don't all respect DNS TTL settings and we had a major outage. I had to on-the-fly learn how to configure iptables to act as a proxy for the new server.

      The "proxy" was still receiving requests 2 weeks later.