The shortest, regex breaking website-domain possible: http://pn/
18 comments
In an earlier thread I was claiming that http://ai/ was no longer operating, but I belatedly learned that this is because systemd's DNS resolver has hard-coded a refusal to look up addresses with a single label from servers outside the LAN. I misinterpreted the lack of results as implying that it had been removed upstream.
https://news.ycombinator.com/item?id=27157712
So, (1) there is another site that is as short as the one you mentioned, and (2) Linux systems that default to using systemd-resolve won't be able to see either of them!
https://news.ycombinator.com/item?id=27157712
So, (1) there is another site that is as short as the one you mentioned, and (2) Linux systems that default to using systemd-resolve won't be able to see either of them!
Does http://ai./ (declaring the name as fully qualified) work on those systems?
Nope! I specifically tried that in the course of researching my post for the other thread, and again now. This doesn't work either on the browser or command line, including using DNS-specific software like dig or host. I think I found a spot in the systemd source code where it specifically says it will refuse to attempt single-label lookups to remote nameservers, and all my Linux systems are relying on systemd-resolve for all of their DNS lookups.
If I specifically change my nameserver away from 127.0.0.53 for a query and point it anywhere else, these single-label names immediately resolve correctly again.
I was also speculating in the other thread that it might be hard to get systemd to reverse this decision just for the one host "ai". Even though we now have twice as many examples of hosts that are broken by this, I still think it might be hard to get it fixed!
If I specifically change my nameserver away from 127.0.0.53 for a query and point it anywhere else, these single-label names immediately resolve correctly again.
I was also speculating in the other thread that it might be hard to get systemd to reverse this decision just for the one host "ai". Even though we now have twice as many examples of hosts that are broken by this, I still think it might be hard to get it fixed!
I also couldn't see ai, but my nameserver was set to my wifi router. I guess either my wifi router is using systemd-resolve or this practice isn't just done by systemd.
Interesting. Thanks for sharing!
I almost get the impression that the only single restriction to urls is having http(s):// at their beginning.
Also reminds me on this interesting collection of unusual urls (and regular expressions) https://mathiasbynens.be/demo/url-regex
Also reminds me on this interesting collection of unusual urls (and regular expressions) https://mathiasbynens.be/demo/url-regex
This is very cool and I have 0% idea how it works. My work's network actually blocks this as 'Unknown', but I'll check it when I get home.
How do you even access it? It won't resolve for me (1.0.0.1). redbot.org can't see it either. who.is falls back to pn.com.
Archive.org has some archived governments website under the address. I got it to resolve under google DNS as an empty webserver with no contents.
It doesn't seem to have a corresponding ip, at least for me. Wonder if Pihole can't handle it.
If you're using systemd-resolve either on your own system or on the Pi, single-label DNS lookups won't be propagated. (You can see that you're using this if your upstream resolver is set to 127.0.0.53 anywhere.)
http://pn/
It indeed runs a webserver.