Also http://ai./ which doesn't redirect you anywhere.

Does this mean you (theoretically) can’t name a host "dk" on your local network? That seems bad, (even if naming hosts after TLDs is a bad idea).

Technically, you should be able to have your local host resolve first. To avoid it being resolved and use the TLD instead, use the trailing dot: http://dk./ https://news.ycombinator.com./ This makes it a FQDN, just like you enter it in your DNS records. Practically, people tend to forget about it, and accessing websites this way sometimes break in unexpected ways when the server doesn't expect the trailing dot in the "host" header.

http://www.dns-sd.org./TrailingDotsInDomainNames.html

You shouldn't be doing this anyways. There are reserved TLDs for this like .corp

https://tools.ietf.org/id/draft-chapin-rfc2606bis-00.html#ne...

.va used to have an SMTP server.

Technically it could be shorter still, if only either . had an A RRset, or if there were 1-character TLDs. Just cause those aren't true today, doesn't mean they can't ever be true.

Chrome won't load that without the trailing dot: http://dk.

Loads fine for me without dot in Chrome (tested on Linux and Android).

Is http://. possible?

Apparently it is possible to do it with local DNS resolution, using your hosts file Not sure how possible it would be on a remote DNS server, or whose authority you'd need to actually do it.

[root@host ~]$ curl -v http://.

* About to connect() to . port 80 (#0)

* Trying 127.0.0.1...

* Connected to . (127.0.0.1) port 80 (#0)

> GET / HTTP/1.1

> User-Agent: curl/7.29.0

> Host: .

> Accept: /

>

< HTTP/1.1 400 Bad Request

< Date: Sat, 15 Aug 2020 15:38:54 GMT

< Server: Apache

< Content-Length: 347

< Connection: close

< Content-Type: text/html; charset=iso-8859-1

<

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>400 Bad Request</title>

</head><body>

<h1>Bad Request</h1>

<p>Your browser sent a request that this server could not understand.<br />

</p>

<p>Additionally, a 400 Bad Request

error was encountered while trying to use an ErrorDocument to handle the request.</p>

</body></html>

* Closing connection 0

Yes, if the root zone (".") published a CNAME or A record. You can simulate this yourself by setting your resolver as the master for "." and giving it an A record. Note that most webservers will barf if you try to send "." in the Host header unless you explicitly configured it.

    # cat named.conf.local
    zone "." {
     type master;
     file "/etc/bind/db.root";
    };

    # cat db.root 
    $TTL 60
    @ IN SOA localhost. root.localhost. (
             1  ; Serial
        604800  ; Refresh
         86400  ; Retry
       2419200  ; Expire
        604800 ) ; Negative Cache TTL
    ;
    @ IN NS .
    @ IN A 209.216.230.240

    # dig a .
    ...
    ;; QUESTION SECTION:
    ;.    IN A
    ;; ANSWER SECTION:
    .   60 IN A 209.216.230.240

    # wget http://./ 
    --2020-08-17 09:38:26--  http://./
    Resolving . (.)... 209.216.230.240
    Connecting to . (.)|209.216.230.240|:80... connected.
    HTTP request sent, awaiting response... 400 Bad Request
    2020-08-17 09:38:26 ERROR 400: Bad Request.

Was my thoughts also.

Doing a dig, there are no A records for . but they do provide NS records obviously, for all the other TLDs to resolve.

Devilish detail is probably in the RFC and likely implementation specific also, as to whether they accept it is a valid request or fail before trying.

dig A .

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> A . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26280 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION: ;. IN A

;; Query time: 3 msec ;; SERVER: 192.168.1.254#53(192.168.1.254) ;; WHEN: Sat Aug 15 18:19:41 BST 2020 ;; MSG SIZE rcvd: 17

How does this work? Also, why can't nslookup resolve it?

domains are split by the dot, from right to left. what is not visible is that the top level domain is not really the first one. the first one is the root domain (or root zone), which is represented by an empty string. you can try it on any domain, add a dot at the end. it will resolve, but the web server may not be configured to respond to it with the right website.

if you want to query a dns server for a top level domain, you have to query the dns that handles it, which in our case is one of the 13 root dns servers.

read more here: https://en.m.wikipedia.org/wiki/DNS_root_zone

https://en.m.wikipedia.org/wiki/Root_name_server

Oh! Now that's nifty. How long have they had that?

DONKEY KONG