So, we can (more or less) still federate with Neckbeard, by manually shoving their IP into /etc/hosts. This doesn't last forever: renewing the certificate won't work, things like that. But if something like this does happen, you can communicate with instances that have gone down during the window between DNS failure (in this case due to the gTLD,
nic.xyz) and the time the DNS issues resolve (

) or there's a new home for the instance by manually adding their IP address to /etc/hosts. This file is consulted before doing a DNS query
The
fedilist.com crawler keeps track of IPs, but doesn't keep historical information on them. (It resolves the domain before trying to hit any of the instance's endpoints. There are a lot of reasons for this: one is security purposes, like in the case of domains that resolve to
127.0.0.1. Initially this also served to warm up the cache, but now that it goes through proxy servers, it helps avoid the overhead of talking to them in cases where the domain doesn't resolve.) Because of recent events, I'll probably stick another field into the `instance_log` table and keep track of old IPs, but in neckbeard.xyz's case, it hadn't given up yet and had the IP around still. (It's still going to launch with source code soon-ish; I'm hacking on the Other Project at present, and also engaging in lucre-seeking activities.)
At any rate, because it doesn't have historical data, here's the current list of all instances, whether up or down, as a TSV, compatible with /etc/hosts: you just drop entries in as needed. (Instance states are "up", "down", "nxdomain", "shenanigan", or "blacklisted". The first three are obvious, "shenanigan" is used when an instance is engaged in chicanery, like setting their domain name to
127.0.0.1 or similar, and "blacklist" is to keep the crawler from repeatedly checking domains that are not fedi instances, regular websites or parked or whatever.) If you run a local DNS server like dnsmasq, you can often get it to log queries and results, so you can grep that to get historical data as far back as your log rotation config allows.
There's an interesting idea: it wouldn't be too difficult to, say, hook the fedilist DB up to PowerDNS (which keeps its records in Postgres/MariaDB/sqlite3, so it's trivial to update, possibly even have them share the DB) so that it could also serve DNS queries based on the last-known IP. If you tacked it onto the bottom of your resolvers list, it could keep some domains from going away during that window. That might be fun to do, and not much effort. So maybe
fedilist.com will also have a DNS server as a component.
You could, if you wanted, just tack this entire file directly onto the end of your /etc/hosts, but you (probably) don't want to do that: instances do change IP addresses, that's one of the things that is seamless thanks to DNS. This is pretty old-school: before DNS, there was a master host list, it was added to HOSTS.TXT (the equivalent of /etc/hosts) for every machine connected to the internet. DNS was created in 1983 to avoid having to do this (
https://www.ietf.org/rfc/rfc882.txt ) and aside from that, reading and parsing an excessively large hosts file can slow down address resolution.
The current structure, however, has ICANN at the top, in charge of accrediting registrars, who then sell domains, and provide their zone information to the IANA, which manages the root DNS. It's a somewhat tangled hierarchy, but we are all at the bottom: gTLDs have their own authorities, ccTLDs are owned by governments, ICANN and IANA run the entire system, individual registrars have deals with TLD authorities and are accredited by ICANN and that's where you get your domains.
poa.st and
gleasonator.com both have .eth domains. Pretty cool. The issue is that, like with .onion instances, it's harder to federate. Federation as currently implemented relies pretty heavily on the domain name system.
instance_hosts.tsv