[buffrr]

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)

[schoen]

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.

OK, I went and looked in the Internet Archive

https://web.archive.org/web/20090716164810/http://www.intern...

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

[buffrr]

> Are you sure of that?

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.

[0] http://stats.research.icann.org/root-zone/data/root-zone-arc...

[schoen]

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.

So, systemd-resolved.service appears to treat single-label names inherently differently from multi-label names when doing a DNS lookup. (LLMNR is https://en.wikipedia.org/wiki/Link-Local_Multicast_Name_Reso..., which is ... not exactly DNS.)

Presumably ai is the only name on the Internet concretely impacted by this behavior. :-(

[suprfsat]

You can try http://ai./