The DNS Under Your Hood

The other day I was reading an article about Ford’s efforts in conjunction with MIT to embed wireless applications into cars. It’s really exciting stuff. A scenario described is one car communicating with cars further up the road to prepare the driver and vehicle for impending road conditions. For example, setting ABS for wet pavement when the wipers on the car a mile ahead turn on. This got me thinking about the potential DNS queries, the volume of queries, and responsiveness of queries necessary for this to really happen. To address these issues, it’s worth a look under the hood to see how DNS works. All internet applications depend on the DNS name server hierarchy for DNS resolution. There are two fundamental characteristics of import for DNS resolution: name server availability and speed of resolution. Factors affecting availability include the redundancy of name servers within the DNS zone. Fault tolerance is mandatory so any authoritative DNS name server failure is backed-up by peer servers within that zone. Factors affecting performance (speed of resolution) is the proximity (latency) between application/user and name server node. The more geographically dispersed the nodes the lower the resolution latency. It gets interesting when you think about doing queries while driving down the highway at 70 MPH. So, how do these queries get handled? The principle methods are anycast and unicast routing. Unicast is the traditional model setting up a 1:1 relationship between a single client and a single server. Anycast is a newer model setting up a 1:many relationship between the IP address and the name server. In other words, the same name server IP address can simultaneously exist at multiple points. In general, unicast is simpler to implement while anycast can be higher-performing with lower latency, particularly for connectionless interactions. This makes me think I’m going to need anycast under my DNS hood to support my next generation intelligent vehicle.