Yesterday I reported that I was able to get my primary DNS server running again. Unfortunately, that’s only part of the battle. It’s not really possible to have a primary DNS server (that’s also the authoritative resolver for multiple domains) running on a dynamic IP. Still no luck getting my ISP to talk about static IP addresses — they try to be helpful, but I think it’s just out of their scope. Further, there seems to be some kind of blocking or filtering on incoming connections to the island place, or possibly just some bad routes. “No problem,” thought I. I’ll just take the configuration information from the current primary DNS server and move it to a new server in the cloud. And so I did. Except…
The Domain Name System is an incredible feat of engineering that enabled the working of the internet in a bygone day when you couldn’t assume that any one machine on the internet could consistently communicate with another machine. We take that for granted these days, but it wasn’t always true. It wasn’t possible (or practical) to create one massive index that mapped domain names (“twoprops.net”) to IP addresses (“5.78.42.129”). You really wouldn’t want to do that anyway: it would put way too much control in the hands of whoever operated the Big Index.
Instead, when your machine wants to look up the IP address for “example.twoprops.net”, it starts by using some hard-coded addresses to look up just “.net” on what are known as root servers. There are several, but they are quite stable and well-connected. The only thing they do is point to the authoritative servers for “twoprops.net”. Those servers might be operated by the owner of “twoprops.net” or might be hosted by third parties, but they’re the ones that can definitively answer the question “what is the real IP address for ‘example.twoprops.net’“.
To make all this even more reliable, and to reduce internet traffic and save time, every one of these multiple lookups are cached, so the data is saved for a specified period of time and each resolver in what can be a very long chain can say “oh, this data is still valid, I don’t need to look it up again.” That makes everything better right up until you’re trying to configure and test a new authoritative server, and suddenly everything stops working and you don’t know if it’s because you configured something wrong (probably) or there’s stale cached data messing things up (also probably). Further, when you’re at the authoritative and root server levels, cache times can be a week or more. That’s a long time to wait between configuration tests.
—2p
addendum 20240902@14:23
It seems I got lucky. Less that 48 hours after my last change, everything seems to have settled down and DNS is running as expected.