[icebraining]

Right now you can guess that a company's web address is probably companyname.com, but .companyname alone can't be a web address.

Not true, and you can see it yourself:

http://ac/

http://ai/

http://tm/

Nothing technically prevents a TLD from having an A record, it's just uncommon. So there could very well be http://microsoft/ or http://apple/, which would appear as "microsoft" and "apple" in FF and Chrome, at least.

[regularjack]

Are you sure about that? ac, ai and tm do not resolve:

  nslookup tm
  Non-existent domain

Browsers are able to reach them by forwarding to ac.com, ai.com or tm.com

[hazov]

It does have an A record:

  % dig a tm
  
  ; <<>> DiG 9.7.3 <<>> a tm.
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41011
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
  
  ;; QUESTION SECTION:
  ;tm.				IN	A
  
  ;; ANSWER SECTION:
  tm.			86366	IN	A	193.223.78.213
  
  ;; Query time: 1 msec
  ;; SERVER: 192.168.66.32#53(192.168.66.32)
  ;; WHEN: Thu Jan 12 10:20:15 2012
  ;; MSG SIZE  rcvd: 36

And also an open http server:

  % nmap tm.
  Starting Nmap 5.00 ( http://nmap.org ) at 2012-01-12 10:24 BRST
  Interesting ports on serv213.icb.co.uk (193.223.78.213):
  Not shown: 997 filtered ports
  PORT    STATE  SERVICE
  80/tcp  open   http
  113/tcp closed auth
  443/tcp open   https

[icebraining]

You might want to check your DNS server, because nslookup tm works fine here.

And yes, browsers redirect to .com if you jut put "tm", but at least Firefox loads the correct website if you put the whole URL, with http://

[derefr]

    Server:	8.8.8.8
    Address:	8.8.8.8#53

    Non-authoritative answer:
    Name: tm
    Address: 193.223.78.213

Seems to be working for me.

[tankenmate]

I think you'll find that IANA (currently ICANN) refuses to put general purpose A, and AAAA records in the root. As far as I am aware only NS, "glue" A (and AAAA), and DNSSEC records are allowed in the root (aside from the records necessary for the root itself, i.e. SOA etc).

You should also note that email addresses that doesn't have a '.' in the host part are technically invalid, i.e. me@mytld is not a valid fully qualified email address.

[icebraining]

I don't know what IANA decided; all I know is the TLDs I listed do have A records, and they load at least on Firefox, so there's obviously no technical reason the new TLDs can't.

You should also note that email addresses that doesn't have a '.' in the host part are technically invalid, i.e. me@mytld is not a valid fully qualified email address.

Hmm, has RFC 2822 been superseded? Because it clearly says the domain part can be a dot-atom, which is defined in the same RFC in ABNF form as:

    dot-atom        =       [CFWS] dot-atom-text [CFWS]

    dot-atom-text   =       1*atext *("." 1*atext)

As you can see, the dot (".") is enclosed in a section of variable repetition (*) with no minimum number of times, so it can not appear at all.

[tankenmate]

I suspect those A records are probably grandfathered and they are of course ccTLDs so the rules are different. None of the gTLDs have A records for their TLD (although they almost certainly have glue A records). From memory I queried John Craine (ICANN Security, Stability and Resiliency Director) about this a number of years ago and again if I remember accurately his response was that they wouldn't allow any additional types of records. I suspect this is a policy decision rather than a technical one.

RFC 2822 has been superceded by RFC 5322. The problem is not being allowed to put MX records in the zone for a TLD, and hence the mail is not routeable. Also remember that you would need to differentiate between "me@mytld<.localdomain>" and "me@mytld.", I'm not sure if all MTA software (let alone MUA) will do the right thing with differentiation. This is probably considered to impact stability and hence is discouraged.