Hacker News Reader

Comment by rnhmjoj | Hacker News Reader

Is a TLD alone technically a valid host name?

Technically yes, because like every other domain name, it can have an A record pointing to an address.

From a technical perspective, there's no difference between `www.example.com`, `example.com` and `com` having an A record.

From a best-practices standpoint, A records on TLDs aren't liked (just see this submission here when looking for a reason) and thus exist only very rarely.

The term to use is 'dotless domains' and they're prohibited in new gTLDs. For more information on why you might want to read these.

https://www.icann.org/en/system/files/files/sac-053-en.pdf

https://www.icann.org/en/system/files/files/sac-083-en.pdf

Of course, see localhost.

It would probably work, but it would break spec.

It definitely works http://ai.

The period needs to be part of the URL at least for Chrome but HN isn't rendering it as part of the link.

the period has to be there because it breaks spec btw

Which spec is this? As far as I know `http://google` is completely fine, and the period at the end is only necessary for the browser address bar heuristics we're talking about. `http://to` was operated as a URL shortener for a while.

It's not just browsers. eg;

  $ host -v ai
  Trying "ai.home.example.com"
  Trying "ai"
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29228

So if there was a host on my network named 'ai', http://ai would resolve there (The terminating dot being standard to indicate a fqdn, rather than a browser trick). This has been understood for a long time; rfc1049 gives us:

  Relative names are either taken relative to a well known origin, or to a
  list of domains used as a search list.  Relative names appear mostly at
  the user interface, where their interpretation varies from implementation to implementation[.]

I stress that last clause; dotless domains have no defined behaviour. "http://google/" may refer to google.example.com. (relative to my search list), google.com. (relative to a well-known origin), or google. (a fqdn). That's not browsers, or omnibars, it's been the vagueness of undotted-domains since the start.

I see what you're saying but these all seem like client-side issues to me.

Possibly. But with two complications - one is that there is no defined correct behaviour for undotted domains. All the RFC gives us is "implementation vary". Second is that this behaviour is inherited from gethostbyname(), so it's unlikely to change soon.

There should be no A-labels on bare gTLDs, so "https://google" should never make sense (per SSAC053 report - https://www.icann.org/groups/ssac/documents)

In Chrome, the link (without the period) in your comment worked for me

It turns out it was my DNS settings. It was trying to lookup ai.company-name.com without the period.

Also http://dk.

I think it breaks policy but not the spec.

Technically the root zone has to have NS records. So even records without a label at all should work. of course you can not resolve them without a static zone configuration.

Reply on news.ycombinator.com