DNS Hijacking?

I have a DNS hijacking theory.

Route 53 is Amazon's elegant DNS web service. DNS is the part of the Internet that converts domain names, like apple.com, into IP addresses such as 17.172.224.47. This is how humans contact computers on the Internet. While DNS is robust, resilient, and redundant, it is the Internet's single point of failure.

So, here's my theory. Websites, like adweek.com, use Route 53:

dig adweek.com ns

returns:

adweek.com. 172800 IN NS ns-304.awsdns-38.com.

adweek.com. 172800 IN NS ns-532.awsdns-02.net.

adweek.com. 172800 IN NS ns-1322.awsdns-37.org.

adweek.com. 172800 IN NS ns-1571.awsdns-04.co.uk.

This means the first time you visit adweek.com, your web browser/ISP will ask one of the Internet's root servers for adweek.com's registrar (i.e., where is the domain name, adweek.com, registered). The root servers will tell your web browsers that adweek.com is hosted at moniker.com (Moniker is a domain name registrar, similar the well-known GoDaddy). The next step is that your web browser will ask Moniker where adweek.com's DNS servers are located. These are referred to as the DNS name servers, or NS for short. As seen above, the response will point your browser to Route 53 which answers with four different servers for redundancy. The final step is that your web browser will query any one of these four servers for the physical IP address of adweek.com. All of these steps happen in the blink of an eye.

Now here's the hijacking part. What if I go to my own Route 53 account, create an entry for adweek.com, and start adding records? When I did this, Route 53 assigned the following four NS servers to me:

ns-715.awsdns-25.net.
ns-1787.awsdns-31.co.uk.
ns-396.awsdns-49.com.
ns-1263.awsdns-29.org.

There should be no hijacking problem since Route 53 assigned four NS servers to me that are different than adweek.com's NS servers. In other words, I cannot hijack adweek.com's Internet traffic in this case. But what if Route 53 had assigned to me an NS server that was the same as adweek.com's NS server? Then, I'm speculating, I could redirect at least a small portion of adweek.com's traffic to wherever I wanted to.

Perhaps this isn't an issue because Route 53 ensures that it never duplicates NS servers names. That would be an expensive proposition, but certainly doable. From there, if my theory holds true, then what about simpler DNS hosts, such as GoDaddy whose DNS servers seem to be limited to nsXX.domaincontrol.com, where XX appears to be a double digit number? This means that many different domain names are using the same DNS server names. Would that make it possible to hijack some traffic from websites sharing the same DNS server? I'm sure that DNS implementations are robust enough that this isn't an issue, otherwise it would have occurred by now. But, with my understanding of the DNS RFC, I don't know how this hijacking issue has been avoided.

So, how has this DNS hijacking scenario been prevented? I'd love to know.

Twitter Alternatives (Rough Draft)

The beauty of Twitter is that it's simply 140 characters of text. Shorter than an SMS text message - akin to a headline. Any other payload in the message is a hyperlink which is also text.

Why only 140 characters per tweet? Because it was designed to fit into a 160 character SMS message preceded by the sender's user name:
"@joemoreno: Just arrived at the Top of the Rock. http://epics3.com/piqk"

Which begs another question: Why only 160 charters for an SMS? Because the inventor of SMS, Friedhelm Hillebrand, typed out random sentences and noticed that they fit into 160 characters.

Worthy Competition
There have been some alternatives to Twitter, but they're just copies. What's the point of making a copy of Twitter if it still suffers from the same Achilles' heel: a centralized single point of failure controlled by one corporation?

A worthy competitor to Twitter requires fundamental integration into the Internet's infrastructure. This shouldn't be too difficult, after all, it's just text --- or another way to think about it, it's just TXT.

DNS? Seriously?
The Twitter alternative that I'm proposing simply uses DNS. In other words, a tweet would simply be stored as a DNS TXT record. Since it's widely recognized that DNS is the Internet's single point of failure, it has multiple, redundant and distributed, servers to keep it running. DNS servers have impeccable uptime stats because, without DNS we have no practical Internet connectivity.

Advantages.
1. No additional servers required. Simply add a new DNS record for each TXT tweet.

2. Redundantly propagated across multiple DNS servers.

3. Server load distributed to ISP DNS caches. In other words, massive traffic for a single tweet would not need to go back to the authoritative DNS server. Set a long TTL for the TXT tweet, say 24 or 48 hours, and each local ISP should only hit the authoritative DNS server once every day or two to refresh a particular tweet's TTL.

Disadvantages
1. Can't easily delete tweets since they're cached at each ISP's DNS server, especially if added with a long TTL.

2. Tweets would need to be inserted into TXT records using a robust API - the only one I'm aware of is Amazon's Route 53 API.

3. Each TXT tweet would need to be a linked list to the previous tweet; or, perhaps, a double linked list to both previous and next TXT tweet.

4. Each TXT tweet would need an embedded timestamp (either UNIX timestamp: 1342472514 or a human readable dateTime object: 2012-07-16T20:38:00Z).

5. TXT tweets, unlike Twitter tweets, can be edited.

6. TXT tweets can expire after the TTL timesout.

TXT Tweet Proposed Standard

The format of the TXT tweet uses pipe | delimited text:

Timestamp | GPS Encoding | TXT Tweet | Previous Chronological Tweet Host Name | Next Chronological Tweet Host Name (optional)

(White space added around pipes only for readability purposes.)

Since the TXT tweets are a single (or double) linked list, we need to know where to start. The logical place to start is with the most recent (i.e. last) TXT tweet. That could be defined in the domain's root TXT record which can be found via the dig command:

dig -t txt joemoreno.com
joemoreno.com.   1 IN TXT "2012-07-16T20:38:00Z|tweet4.joemoreno.com"

So, the most recent TXT tweet is at tweet4.joemoreno.com. (A simpler naming convention could be host names with integers, such as 0.joemoreno.com, 1.joemoreno.com, 2.joemoreno.com, etc.)

dig -t txt tweet4.joemoreno.com

tweet4.joemoreno.com. 86400 IN TXT "\"2012-07-16T20:38:00Z | 40\16150'16.8\"N74\16127'57.6\"W | 31 years ago, today, Harry Chapin left us. http://blog.joemoreno.com/2011/07/harry-chapin.html | tweet3.joemoreno.com |\""

TXT tweet tweet4.joemoreno.com points to tweet3.joemoreno.com as the previous TXT tweet.

dig -t txt tweet3.joemoreno.com

tweet3.joemoreno.com. 86400 IN TXT "2012-07-16T20:36:00Z | | Yahoo has named Google executive Marissa Mayer as its new CEO. | tweet2.joemoreno.com | tweet4.joemoreno.com"

Practically speaking, we might be limited to 254 characters in a DNS TXT record in order to support older DNS servers. It's a tight fit, but it works with the timestamp, GPS encoding, 160 character TXT tweet, plus the previous and/or next TXT tweet host name.

Left for the Student
Several services need to be built on top of this proposal. Displaying a single user's TXT tweets can be rendered by a simple script running on a web server to display a specific user's feed. Mixing different user feeds, chronologically, is a little harder, but very doable.

However, where it gets challenging is how to handle "follows" and "mentions." In both cases, a server would need to either push or pull these notifications in real time. Pulling could be simple polling, like an RSS feed query. But, push notifications can be a bit more challenging. I'll have to think about how this part would work.