69 comments

[ 3.7 ms ] story [ 146 ms ] thread
No, it doesn't. (macOS Firefox)
works for me, macOS Chrome — this is just from that "shortest links" article though.
Works for me (Arch Firefox).
Works on mine (macOS Firefox)
For me DNS lookup fails (using dig, dns-sd, dscacheutil). Maybe an ISP thing?

Edit: Ah, I see (quoted in the shortest URLs page):

> Dotless domains will not be universally reachable and the SSAC recommends strongly against their use. As a result, the SSAC also recommends that the use of DNS resource records such as A, AAAA, and MX in the apex of a TopLevel Domain (TLD) be contractually prohibited where appropriate and strongly discouraged in all cases.

https://www.icann.org/en/announcements/details/new-gtld-dotl...

BTW, http://ai./ doesn't work for me neither.

Not ISP-dependent, but DNS-server dependent. The recommendation is also just that: It's not enforced. The TLD can decide to serve those records at the apex if it wishes, and any given DNS server should look them up as requested. It just so happens in your case it doesn't -- Windows DNS, for example, will not serve the TLD's A record.

Regardless, in your case, `dig pn. +noall +comments`, you'll likely see SERVFAIL.

Trying `dig pn. +noall +comments @8.8.8.8` and you'll see that you get a status of NOERROR.

(And, of course, `dig pn. +short @8.8.8.8` will give you the correct IP of 139.162.17.173)

ISP related in so far as this is where most people get their DNS queries resolved by default (DNS servers configured with DHCP).
Mine neither, but when I switch the DNS to 1.1.1.1, it does. You can switch just Firefox by enabling "DNS over HTTPS".
Not for me, Kiwi browser on Android.
Using an unmaintained browser might be dangerous
The only browser that allows me to use any addon I want. I'll continue to use it until Mozilla fulfill their promise and allow me to load any addon I want.

Fitness for use trumps security.

Works for me, Windows 10 IoT LTSC
It works, Firefox for Android.

Please explain the domain to us, how did you do it?

It doesn't work for me on Firefox on Android. Maybe my DNS resolver refuses to return A records for TLDs, even with a trailing .?
Must be a DNS thing, it also works for me in Firefox for Android.
Works in Netscape

Edit: https://ibb.co/1Th7mTX

Edit: And IE: https://ibb.co/HK9pzbm

Edit: Camino, one of my favorite browsers: https://ibb.co/8x3STrj

(I work on retro websites and test in these all day long.)

> I work on retro websites

Can you please share links?

I don't know if I'm more surprised by this quirk of DNS (as in, domains of the form <TLD><dot>) working, or more impressed that someone's still got a readily-available Netscape install to test it out.
This is one of the reasons I love HN.
It's not at all a quirk of DNS.

Or I spent too much time reading O'Reilly's "DNS and BIND" and everyone else thinks "no, that's not the root-root zone, that's a quirk".

How do you deal with constant SSL error messages? I tried to use Netscape for a while, it was a pleasant experience except the fact that most websites are HTTPS now and Netscape wasn't able to handle recent versions.
I'll bet it'd work if you used an HTTP proxy that the downgraded the modern protocols and encodings.

Though for general purpose browsing, the modern stuff like HTML5 / CSS3 / ES6+ would make it somewhere between unusable and nonfunctional.

I only browse HTTP websites with Netscape, mostly my own.
This belongs in /r/blackmagicfuckery
There's no magic. It works the same way any other domain does.
Does not work on my Arch Linux Firefox 104.0.1

    We can’t connect to the server at pn.. Did you mean to go to www.pn.?
Works on my Arch Linux Firefox 104.0.2
For a fun third Firefox (104.0.2) on Arch Linux behavior, it seems to resolve for me but warns me it can load it with TLS. I imagine that if I bypassed this it would work fine though.
I am impressed with HN gracefully degrading the handling of the URL. It doesn't know how to parse the url for the preview on the homepage, but it doesn't crash the page or prevent the link entry from rendering.
I’m not using anything fancy when I visit HN, what is it doing to preview the homepage and why would it crash or prevent anything from rendering? I don’t even understand what you’re congratulating HN for other than having hyperlinks.
I can see that crashing some languages

Depends how strict they are at runtime

I keep re-reading this and I just have to admit that I sincerely don’t understand. What runtime behavior is potentially crash prone in the first place? Are you saying stricter behavior would be more crash prone, or less? Which languages are more likely to be susceptible? I’m baffled and truly don’t mean to be dismissive.
Works but not working through some proxy. A rare but interesting edge case
More information in this other post that's currently on the front page https://jameswillia.ms/posts/shortest-urls.html
I guess I have to read the article for once.

Edit: nice article! I looked at the HN data and code, and trying to handle these as normal URLs with sitenames in parens would also let a lot of garbage through and/or be a lot of work. Given that the current submission kind of gracefully degraded (https://news.ycombinator.com/item?id=32805527), I think it's probably best not to invest the effort.

it doesn't work for me. FF nightly android (if it matters: JS disabled and HTTPS mode enabled)
If it’s not working for you it’s probably due to the resolver you’re using or how your host’s stub resolver is configured. Some stub resolvers have rules about the number of dots in the name.

I’m using dnsmasq on my router pointed at Google DNS and it’s not currently resolving for me on my iPhone. I’ll have to check where the failure is occurring.

Edit: if I turn off WiFi on my iPhone, I can load the site just fine over Verizon cellular. So it’s my dnsmasq config most likely.

A trailing dot is entirely within the spec, isn't it?

For some fun: http://gs.com./ gives an error. https://news.ycombinator.com./ works, but has me logged out (probably the cookie doesn't match?).

Yes. The trailing dot is typically to tell the stub resolver not to try qualifying with the local domain. Rules vary by stub resolver though. On iOS I’m getting “A server with the specified hostname could not be found. NSURLErrorDomain” regardless of browser. I’ll have to debug tomorrow when I’m not too lazy to get up off the couch from my phone.

Both of your URLs work for me. A 404 on the first. I stay logged in to HN on the second. My guess is my trouble is with my local dnsmasq config.

The SNI spec dictates that trailing dots shall be stripped from the hostname.

The HTTP host header which is sometimes (ab)used to perform a kind of not-quite-right-SNI doesn't have the luxury of being quite so well specified.

http://microsoft.com./ has an interesting 404 page
I used to work for a guy who registered borgosoft.com and CNAMEed it to microsoft.com. In the days before HTTP 1.1, a Host: header was not required on a request, and it would happily serve up microsoft.com's content under borgosoft.com. Eventually they started requiring a host header, and the trick stopped working. The guy I worked for claimed credit for making them do this; I have my doubts.
Gs.com. is probably because the server doesn't expect a . At the end of the domain in the host header
Appending "." to domain names helps bypass naive DNS based censorship, too.
Works using 8.8.8.8 and 1.1.1.1 as resolvers.
Not working on my random ISP’s DNS, and iOS iPhone 7 Chrome.
works opera android 8.8.8.8 dns
(comment deleted)
(comment deleted)