http://pn./ | Hacker News Reader

http://pn./

pn.

122 pointstodsacerdoti66 comments

Shortest URLs on the Internet - https://news.ycombinator.com/item?id=32801359 - Sept 2022 (168 comments)

.ai - https://news.ycombinator.com/item?id=32804189 - Sept 2022 (81 comments)

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.

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

https://news.ycombinator.com/item?id=23479435

In 2020, someone find if you add "." in host suffix of Youtube url: http://www.youtube.com./ it will works without AD (IIRC, because AD resource file is viewed as different domain and blocked)

Alas, now it just redirects to the dotless version.

Appending "." to domain names helps bypass naive DNS based censorship, too.

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.

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.

Gs.com. is probably because the server doesn't expect a . At the end of the domain in the host header

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

> I work on retro websites

Can you please share links?

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.

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 works, Firefox for Android.

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

See here https://jameswillia.ms/posts/shortest-urls.html

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.

People having trouble with this on a Linux-based OS might check out the systemd-resolved discussion in the current thread about the ai domain.

https://news.ycombinator.com/item?id=32804743

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

That's because of systemd [0].

There's some quirks that will resolve it, once its cached, but generally speaking, you need to tell systemd to resolve these names.

[0] https://wiki.archlinux.org/title/systemd-resolved#systemd-re...

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.

Please describe the domain to us.

https://en.wikipedia.org/wiki/.pn

further context: https://news.ycombinator.com/item?id=32801359, and see also the other two-letter domains on the front page of HN today. i'm not really sure if this is what you were asking, but it at least explains what's going on to somebody from the future who finds their way back to this comment section.

https://pn./

> Apache/2.2.22 (Debian) Server at pn Port 443

Yikes!

Works for me, Windows 10 IoT LTSC

Also http://ai./

Works but not working through some proxy. A rare but interesting edge case

Now go and install mod_perl

Not working on my random ISP’s DNS, and iOS iPhone 7 Chrome.

Works using 8.8.8.8 and 1.1.1.1 as resolvers.

Okay, please explain the domain for us.

https://en.wikipedia.org/wiki/.pn

https://en.wikipedia.org/wiki/Pitcairn_Islands

(ccTLD for the Pitcairn Islands, one of the most isolated communities on the planet)

https://jameswillia.ms/posts/shortest-urls.html

it doesn't work for me. FF nightly android (if it matters: JS disabled and HTTPS mode enabled)

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.

This belongs in /r/blackmagicfuckery

There's no magic. It works the same way any other domain does.

Thanks for the explanation

what is this? how is it working?

Same as you, how does it work?

See https://jameswillia.ms/posts/shortest-urls.html and its HN submission https://news.ycombinator.com/item?id=32801359

works opera android 8.8.8.8 dns

> It works!!!

Ship it!!!

No, it doesn't. (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".

works for me, macOS Chrome — this is just from that "shortest links" article though.

Works on mine (macOS Firefox)

Works for me (Arch Firefox).

Reply on news.ycombinator.com