In my time as software developer, I have ended up building a lot of strange esoteric applications, but a requirement received from a customer meant I spent some time last night building a DNS server.
The requirement from the customer was that they operate two servers, and each of their customers (”end-customer”) is “homed” to exactly one server. From time-to-time they need to move a customer from Server A to Server B. At the moment each end-customer connects to a URL like http://servera.foo.com/application/customera/default.aspx. The problem is that should an end-customer need to move to a new server they have to change the configuration in an application running on the customer’s site. This can almost certainly never be done in a hurry – sometimes it can take weeks.
The requirement from our customer was that the application installed on the end-customer’s computer would call into a Web service which would return the IP of the server to connect to, update the local configuration and away you go. Basically the “switching” server would always stay in one place.
And as I was thinking about that I thought that there was already an established technology that takes a name and turns it into an IP… DNS. This would mean that customers could configure themselves as http://customera.foo.com/application/customera.aspx and obviously the physical location of customera.foo.com would be transparent and could change. This approach removes the need for any weird or complex code and allows the right protocol to do the heavy lifting.
Not knowing off the top of my head any DNS servers that allowed queries to come out of a database, I wondered how hard it would be to build one. The answer was “not hard to do, but hard to come across the information required”. RFC1035 was *eventually* discovered offered the required information and I was somewhat blown away by the fact this RFC is 22 years old. I started by building a DNS client that would do “A” lookups against our in-house Microsoft DNS. Once I broke the back of building the client, a DNS server that only answered “A” queries for a known domain was relatively straightforward.
That said, driving back home it did occur that running BIND and creating a utility that dumped a new configuration file periodically would probably be a more robust, production-ready solution! But at least I got to build something I had never build before…