This belongs in /r/blackmagicfuckery
There's no magic. It works the same way any other domain does.
http://pn./
21–30 of 70 posts
Re: http://pn./
#22Okay, please explain the domain for us.
Re: http://pn./
#23If 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.
Re: http://pn./
#24Works using 8.8.8.8 and 1.1.1.1 as resolvers.
Re: http://pn./
#25Does 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
Re: http://pn./
#26Not working on my random ISP’s DNS, and iOS iPhone 7 Chrome.
Re: http://pn./
#27Now go and install mod_perl
Re: http://pn./
#28If 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 o…
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?).
Re: http://pn./
#29No, 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 an…
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)
Re: http://pn./
#30works opera android
8.8.8.8 dns