In today’s SQL newsletter from SQL-Server-Performance.com I was horrified to find the following tip:
When you specify a server in an ADO.NET connection string, use the server’s IP address, not the server’s DNS name. By using an IP address instead of a DNS name, name resolution does not have to occur, reducing the amount of time it takes for a connection to be made. A server’s IP address can be used to specify either a default or named instance of a server running SQL Server. If you are running a cluster, use the virtual SQL Server IP address. [7.0, 2000, 2005]
As a guy who’s lived through more than one IP address renumbering disaster, please believe me when I say you should never do that. IP addresses can and do change. While server names can also change, it’s easy to make fake DNS entries for an old server name that points to the new name. It’s impossible to make a fake IP address point to one in another subnet, especially if the server is being physically moved.
Disaster recovery is a great example, and performance testing offsite is another. There are times when we’ll airlift an entire application and drop it somewhere else. Everything will be the same, but the IP’s are different - and bam, the application fails. Programmers have to be called in to track down every possible location in their app for a connection string.
Furthermore, applications don’t query DNS every time they query the server. They have a DNS cache, and they will only look up the DNS name periodically - and that time is usually measured in hours or days, not seconds or minutes.
If your application is so blazingly fast that a 1-second DNS lookup once per day is a bottleneck for you, then I salute you, and you might consider using IPs in your connection string. However, the rest of us need to use DNS names.
Normally I like SQL-Server-Performance.com and I recommend it for beginners, so I was surprised on this one, and I had to point it out.
