Thankfully, your URL can be lengthened to this:

https://aaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...

Let me shorten that for you:

https://t.ly/MdaT

Haha nice that's better!

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.

https://www.internic.net/domain/root.zone

Neat! That link worked for me on the latest Chrome ¯\_(ツ)_/¯

I don't understand how that could be (!).

Perhaps it auto-prepends "www" to it (since that worked for me on FF).

Found this old comment about it (of course it had to be a long URL)

https://aaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...

Works here, too. Chrome on Android. Got a very basic html site with Vi ce Cates' name on it.

Firefox, works just fine.

But... it doesn't have a DNS record anymore!

You sure?

    $ dig +noall +answer ai.
    ai.   80534 IN A 209.59.119.34

Huh, this is weird!

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.

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

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

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. :-(

You can try http://ai./

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

There's also https://www.dj/

  curl ai

Worked as well.

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.

It could be shorter still! Stop forcing HTTPS!

HTTPS is not required. t.ly works fine without "https://"

Really? The browsers I usually use to test if a site works without HTTPS (IE6 and IE8 on XP SP2) can't load it. Weird!

the http url is a 301 redirect to https so thats why it doesn't load ultimately

Disappointing; that doesn't really count!

Curious to how you are still running IE6 :)

It's the default for XP SP2.

Ok so curious why you are running Windows XP :)

Because I have a need for Internet Explorer 6-8!

Why do you use Internet Explorer 6-8 on the internet?

Because I have some software that has it as a hard-dependency.

I feel for you :(

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.

so ftp:// ? or is there something shorter?

HTTP!

I think http is longer than ftp :P

Yeah, but it's a web URL shortener.

Yes ftp would not work lol