I did some Googling and apparently my Google-fu is weak today.<p>I'm wondering why hostnames ended up being reversed. Ex: .com.example is now example.com.<p>I recall reading that the reversal happened somewhere during the development of a messaging protocol for ARPANET. com.example@user was reversed to user@example.com and then it just sort of stuck. Am I far off?<p>Does anyone have any resources or anecdotes that explain this at all? I think I may have even seen this explained in an HN thread once but was unsuccessful in finding it.<p>Thanks.
The earliest RFC which I know of which spells it out is RFC 805, <a href="https://tools.ietf.org/html/rfc805" rel="nofollow">https://tools.ietf.org/html/rfc805</a><p><pre><code> It was clear that the information
content of all these syntactic alternatives was the same, so that
the one causing least difficulty for existing systems should be
chosen. Hence it was decided to add all new information on the
right of the @ sign, leaving the "user" field to the left
completely to each system to determine (in particular to avoid the
problem that some systems already use dot (.) internally as part
of user names).
The conclusion in this area was that the current "user@host" mailbox
identifier should be extended to "user@host.domain" where "domain"
could be a hierarchy of domains.
In particular, the "host" field would become a "location" field
and the structure would read (left to right) from the most
specific to the most general.
</code></pre>
It was chosen apparently because RFC 805 was standardizing to "mailbox@computer", and since 'mailbox' is more specific than 'computer' it became more and more specialized going left.<p>As for why 'mailbox' comes first, it's presumably because that's someone's username. The very first thing you want to see is, "I'm sending this to drostie," and only afterwards do you need to know where that server is located.
I don't have any concrete evidence, but my guess is that having the repeating value (the TLD) at the front meant that storing domain names in a hashtable was inefficient. Lookups would be faster if the more-unique part was at the front of the string, since the string comparisons would run faster.