For many years (but no longer) Vince Cate's Offshore Information Services had a DNS A record for the ccTLD "ai", so that http://ai/ was a valid URL that worked in browsers. (A few people also had e-mail addresses @ai.)
Today, there are no longer any TLDs of any kind with their own A records.
The DNS record is no longer in the root zone itself (I think it used to be?) and some recursive resolvers seem to filter out the bare-TLD query or response. But the A record still exists inside the ai zone... so I'm not sure who is right, so to speak!
The A record was never in the root zone. The root zone has an NS record for ai TLD which delegates authority to ai nameservers.
You can try `dig @a.root-servers.net ai NS` to get the nameserver `a.lactld.org.` which is authoritative for ai. You can now try `dig @a.lactld.org ai A` to get it (that's how recursive resolves generally work)
Yeah, so I think I'm seeing something weird where some software isn't allowing this particular recursive query? I'll dig into it more.
By the way:
> The A record was never in the root zone.
Are you sure of that? I don't have any proof, but my impression was that the DNS registry for ai (which was also just Vince Cate...) was able to ask for it because at one time the root zone was less restrictive in what RRtypes could be placed there for TLDs. But that might just be repeating someone else's mistaken impression.
and this version of the root zone from 2009 does indeed not have an A record for ai, just ordinary NS delegations. So it seems like your explanation is confirmed, and there must be a change in some recursive resolver behavior. (I tried from four different Linux systems on different networks and all refused to resolve it, so there really must be something that's changed more widely, not just my home router.)
I checked an archive of root zone data from June 1999 to May 2021[0], and there don't seem to be A records for any TLD. Not sure why you're having this issue, but I'm curious to know which Linux distro/software doesn't resolve ai.
It looks like it's systemd-resolve. I just checked on several machines and, when using nslookup to query the recursive nameserver that systemd-resolve is forwarding to, the ai A record does resolve, while when using systemd-resolve itself, or the local instance on 127.0.0.53 configured via /etc/resolv.conf, it returns a failure every time.
I'll have to look into this some more.
Edit: I think I found it! From systemd-resolved.service(8):
· Single-label names are routed to all local interfaces capable of IP
multicasting, using the LLMNR protocol. Lookups for IPv4 addresses
are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are
only sent via LLMNR on IPv6. Lookups for the locally configured
host name and the "_gateway" host name are never routed to LLMNR.
· Multi-label names are routed to all local interfaces that have a
DNS server configured, plus the globally configured DNS server if
there is one. Address lookups from the link-local address range are
never routed to DNS.
I can't edit this anymore, but further down in this thread it turned out that it's just systemd that refuses to attempt a global DNS A lookup for a single-label name, so this record DOES still exist, just like it ever did, but all the machines that I've tried on for the past few years as well as yesterday were Linux systems using a local systemd stub resolver that enforced this rule. :-(
I guess I should get some servers running other operating systems, or something.
It might be difficult to convince the systemd developers that this special case should be removed just because of this one anomalous DNS name...
Mind sharing some background? I'm curious about how you snagged the domain, how you've managed to monetize it, and what the competition is like in this space.
You've shortened 6,463,545 links so far. Assuming you're using a charset of [A-Za-z0-9], that gives you 14,776,336 total possible 4-character URLs. Almost half way there!
What's your plan once you reach the 4-character limit? Roll over to 5, or something fancier?
Yes, you are correct. I don't have anything fancy planned. Users with accounts are able to customize the ending so this will increase the availability. Currently, Bitly is up to 7 characters long when you create a random short URL. T.LY is already 2 characters shorter and there are still plenty of short random URLs 62^5 = 916,132,832
years ago, we asked bit.ly if they could vendor our link shortening and tracking. Turned out we were already a couple multiples larger than them in terms of link processing. our use case is a bit different though. Instead of one link given to many, we tend to be one link given to one recipient. Optimizing this kind of problem is interesting and fun.
I actually like using it. There's something comfortable about using an operating system that's old enough to have kids. Another benefit is that screens are high enough resolution nowadays that it doesn't look like a child's toy.
