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.
2 Comments. Leave new
YES!!!! I just saw the blog entry, because I am in the middle of configuring a DNS based load balancer. I can confirm that it is days. As long as the connection comes back, the ADO.NET connection will continue using the IP values.
But yea, why do people think it’s okay to hard code an IP address in their code?
I think the real question would be: why are people hard coding connection strings in their code at all. A connection string should not be hard coded in and instead should be stored in a config file or some other external configuration method that is easy to change. Not saying the article is wrong, but there should never be a reason to call in a developer to change a connection string. IT administration staff should be able to update a configuration value and the application respect that. In .NET this is easy using an app.config (or web.config) file and the System.Configuration.ConfigurationManager class.