1. 27

Turned up on the Orange site. Sure enough, you can’t actually post it as a story here either, but the URL works: http://pn/

  1.  

  2. 10

    Back when the internet was quite a bit smaller, I considered (but never did) asking the honduras domain registrars to add an MX record and forward ‘j’ to me, so I could be j@hn.

    1. 6

      http://ai./ also works. also, could you technically run a web server on one of the DNS roots? in which case, http://. could serve traffic.

      1. 2

        safari can’t find the server

        same for pn.

        Maybe my pihole is blocking it.

      2. 5

        I remember a few domains with A records at the top level; I think dk had one at some point

        1. 3

          Correct. You used to be able to type “dk.” in a browser and you would then be redirected to the website of DK Hostmaster who manages the .dk TLD.

          I found it to be quite useful as a quick way to get to their site.

        2. 2

          I wrote an article about TLDs that serve web content. It’s in French, but you’ll find the domain names: https://www.simonjunod.ch/projets/webtld/

          1. 2

            Similarly cm used to resolve, though no longer apparently.

            1. 2

              No mention of https://to./?

              That was the first TLD site I ever heard of, it used to be a url shortener, but today it seems like it’s defunct since the certificate is expired and the home page 404’s.

              1. 2

                Croatia has its homepage at http://www.hr/ A friend of mine had a name@hr email address which was very cool until you try to get past form input validation.

                1. 1

                  Doesn’t work for me on Firefox or Chrome. Must be my adblocker

                    1. 2

                      Same thing :(

                      1. 1

                        Try with http:// as a prefix

                  1. 1

                    What qualifies as works? http://a/ works too for some value of “work”. edit: oh, I see other comments report it actually resolves. Not for me either.

                    1. 1

                      Curious how this URL works! It redirects me to https://pn.com, which on the surface looks like a privacy-oriented tech news site.

                      1. 12

                        That’s probably your browser “helpfully” guessing where you want to go instead.

                        The actual site should just show

                        It works! This is the default web page for this server.

                        The web server software is running but no content has been added, yet.

                      2. 1

                        http://de interestingly ends up on some advertising page. How does one take over such a page?

                        1. 3

                          It doesn’t resolve for me. Maybe you have some catchall DNS?

                          1. 1

                            Have you tried to add a dot ?

                            1. 5

                              There is no A record for de. You are behind a split-horizon resolver, most likely your ISP’s to inject advertisements.

                              1. 2

                                Creepy. That would explain why I got different results using my cell network.

                          2. 1

                            no luck for me either. I wonder if there’s something funky with my DNS. dig A de spits out

                            de.			7155	IN	SOA	f.nic.de. its.denic.de. 1623166346 7200 7200 3600000 7200
                            
                            1. 3

                              That’s just the authority record (see the SOA instead of A) telling you which nameserver is authoritative for the query. There aren’t any A records listed on de as far as I can see.

                          3. 1

                            With the handshake root selling alt TLDs to its users, I expect we’ll see ever-more experimemtation with records right on TLDs and what sofware works right in that case

                            1. 1

                              This is not a valid URL. Certain web browsers will “fix” this URL by converting it to http://pn.com/. The same browser will convert http://arstechnica/ to http://arstechnica.com/ for example. It’s just the browser trying to be “user friendly” by adding “.com” if the hostname doesn’t contain a TLD. But try it with curl or wget and it will fail correctly.

                              1. 3
                                $ curl -Iv http://pn
                                *   Trying 139.162.17.173...
                                * TCP_NODELAY set
                                * Connected to pn (139.162.17.173) port 80 (#0)
                                > HEAD / HTTP/1.1
                                > Host: pn
                                > User-Agent: curl/7.64.1
                                > Accept: */*
                                >
                                < HTTP/1.1 200 OK
                                HTTP/1.1 200 OK
                                < Date: Tue, 08 Jun 2021 15:29:28 GMT
                                Date: Tue, 08 Jun 2021 15:29:28 GMT
                                < Server: Apache/2.2.22 (Debian)
                                Server: Apache/2.2.22 (Debian)
                                < Last-Modified: Thu, 30 Jul 2015 00:14:34 GMT
                                Last-Modified: Thu, 30 Jul 2015 00:14:34 GMT
                                < ETag: "e0003-b1-51c0c9688ffb3"
                                ETag: "e0003-b1-51c0c9688ffb3"
                                < Accept-Ranges: bytes
                                Accept-Ranges: bytes
                                < Content-Length: 177
                                Content-Length: 177
                                < Vary: Accept-Encoding
                                Vary: Accept-Encoding
                                < Connection: close
                                Connection: close
                                < Content-Type: text/html; charset=UTF-8
                                Content-Type: text/html; charset=UTF-8
                                
                                <
                                * Closing connection 0
                                
                                1. 2
                                  $ curl -Iv http://pn/
                                  * Could not resolve host: pn
                                  * Closing connection 0
                                  curl: (6) Could not resolve host: pn
                                  

                                  The difference has to be in our DNS servers.

                                  If I use the DNS server 1.1.1.1, it works. If I use the DNS server 8.8.8.8, it does not work.

                                  1. 1

                                    oh weird, I wonder if google just drops TLD requests. not like it really affects anyone.

                                    1. 2
                                      % dig @8.8.8.8 pn.
                                      
                                      ;; QUESTION SECTION:
                                      ;pn.				IN	A
                                      
                                      ;; ANSWER SECTION:
                                      pn.			21599	IN	A	139.162.17.173
                                      

                                      Google properly resolves pn.

                                      1. 2

                                        That command didn’t work for me 2 hours ago, but it is working now.

                                2. 2

                                  This is not a valid URL.

                                  Unless I’m reading the ABNF in RFC3986 (“Uniform Resource Identifier (URI): Generic Syntax”) incorrectly, it’s a valid URI (and also a valid URL) because reg-name can be 0-or-more unreserved which includes ALPHA. Hence pn is a valid reg-name and the whole is a valid URI.

                                  Additionally, the regexp they give for parsing URIs accepts http://pn/ and spits out the correct fields.

                                  > echo "http://pn/" | perl -nle '@a = ($_=~m%^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?%);print join(" | ", @a);'
                                  http: | http | //pn | pn | / |  |  |  |
                                  

                                  Which gives us scheme = http, authority = pn, path = /, query = "", fragment = "".

                                  1. 2

                                    You are correct, it is correct URL syntax. (Since ‘pn’ doesn’t resolve on my system, I made the mistake of thinking it was unresolvable, hence http://pn/ doesn’t point at anything, hence it isn’t valid. I now understand I was wrong about this.)

                                3. [Comment removed by author]

                                  1. 10

                                    Still, both are not top level domain only, which is what this post is about IMHO