For example, I picked up this from techrunch's tweet http://bit.ly/12V9c1. I could also create a link called http://mayanks.bit.ly/12V9c1 and it would still take me to techcrunch's site. So I get to brand my own short url.
Is this an undocumented feature or something is wrong here?
Not an uncommon practice, and helps ensure that things like the random typo of ww.site.com by a user still gets them to where they were expecting to go.
So my guess is that it's not an undocumented feature but more of a clever hack that exploits something that was done for an entirely different, but closely related, purpose.
For example in case of cbs.bit.ly only links shortened by cbs should be valid. But try it out any bit.ly shortened link works with cbs. subdomain as well.
My guess would be that for particular subdomains (om, cbs, etc.) they may be offering some stats on clicks, referrers, etc., so that those users can better track that sort of stuff.
But, the easiest way to manage this DNS-wise is to use wildcards. The side effect is that any subdomain becomes valid, but that's usually no issue.
------------------------------------------------
brks-macbook-pro:Downloads brk$ ping om.bit.ly
PING om.bit.ly (128.121.254.129): 56 data bytes 64 bytes from 128.121.254.129: icmp_seq=0 ttl=57 time=69.395 ms 64 bytes from 128.121.254.129: icmp_seq=1 ttl=57 time=69.584 ms ^C
--- om.bit.ly ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 69.395/69.489/69.584/0.095 ms
brks-macbook-pro:Downloads brk$ ping cbs.bit.ly
PING cbs.bit.ly (168.143.174.25): 56 data bytes 64 bytes from 168.143.174.25: icmp_seq=0 ttl=57 time=69.898 ms 64 bytes from 168.143.174.25: icmp_seq=1 ttl=57 time=69.625 ms 64 bytes from 168.143.174.25: icmp_seq=2 ttl=57 time=69.815 ms ^C
--- cbs.bit.ly ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 69.625/69.779/69.898/0.114 ms
brks-macbook-pro:Downloads brk$ ping foo.bit.ly
PING foo.bit.ly (128.121.254.129): 56 data bytes 64 bytes from 128.121.254.129: icmp_seq=0 ttl=57 time=70.048 ms 64 bytes from 128.121.254.129: icmp_seq=1 ttl=57 time=69.509 ms 64 bytes from 128.121.254.129: icmp_seq=2 ttl=57 time=70.003 ms ^C
--- foo.bit.ly ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 69.509/69.853/70.048/0.244 ms
brks-macbook-pro:Downloads brk$ ping brk.bit.ly
PING brk.bit.ly (168.143.174.25): 56 data bytes 64 bytes from 168.143.174.25: icmp_seq=0 ttl=57 time=69.191 ms 64 bytes from 168.143.174.25: icmp_seq=1 ttl=57 time=69.489 ms 64 bytes from 168.143.174.25: icmp_seq=2 ttl=57 time=72.154 ms ^C
--- brk.bit.ly ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 69.191/70.278/72.154/1.332 ms
brks-macbook-pro:Downloads brk$ ping 123.bit.ly
PING 123.bit.ly (128.121.254.201): 56 data bytes 64 bytes from 128.121.254.201: icmp_seq=0 ttl=57 time=69.376 ms 64 bytes from 128.121.254.201: icmp_seq=1 ttl=57 time=70.049 ms 64 bytes from 128.121.254.201: icmp_seq=2 ttl=57 time=75.750 ms ^C
--- 123.bit.ly ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 69.376/71.725/75.750/2.859 ms
brks-macbook-pro:Downloads brk$ ping 456.bit.ly
PING 456.bit.ly (168.143.174.25): 56 data bytes 64 bytes from 168.143.174.25: icmp_seq=0 ttl=57 time=69.185 ms 64 bytes from 168.143.174.25: icmp_seq=1 ttl=57 time=69.917 ms 64 bytes from 168.143.174.25: icmp_seq=2 ttl=57 time=69.663 ms ^C
--- 456.bit.ly ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 69.185/69.588/69.917/0.303 ms brks-macbook-pro:Downloads brk$
------------------------------------------------
Also, sub-sub-domains work:
brks-macbook-pro:Downloads brk$ ping ntr.brk.bit.ly
PING ntr.brk.bit.ly (168.143.174.29): 56 data bytes 64 bytes from 168.143.174.29: icmp_seq=0 ttl=57 time=70.208 ms 64 bytes from 168.143.174.29: icmp_seq=1 ttl=57 time=68.510 ms
This must be an undocumented feature to allow user accounts to brand their links if desired, since it redirects to the account's recent list. I am curious if many twitter clients would properly recognize "<user>.bit.ly/xyz" as a shortened url and try to expand it via the API, my guess is a few out there might see this as a long url and try shortening it again. What a unforeseen mess that would cause.
If it is an undocumented feature, it is susceptible to link hijacking. I can take a url shortened by you (pplante) and brand it as my own mayank.bit.ly/xyz. That will not be cool...
