Do connection string DNS lookups get cached?

Question

Suppose the following:

I have a database set up on , which resolves to IP , running from a local DNS server on our network. 解析为IP ，从我们网络上的本地DNS服务器运行。

I have countless ASP, ASP.NET and WinForms applications that use a connection string utilising as the server name, all running from the internal network. 作为服务器名称的连接字符串，它们都从内部网络运行。

Then the box running the database dies, and I switch over to a new box with an IP of . 的新盒子。

So, I update the DNS for to point to . 的DNS更新为指向 。

Will all the applications and computers running them have cached the old resolved IP address?

I'm assuming they will have.

Any suggestions along the lines of "don't have your IP change each time you switch box" are not too welcome as I cannot control this aspect of the situation, unfortunately. We are currently using the machine name of the box, which changes every time it dies and all apps etc. have to be updated with the new machine name. It hurts.

Answer 1

Even if the DNS is not cached local to the machine, it will likely be cached somewhere along the DNS chain between the machine and the name servers, at least for a short while. My understanding is this situation would usually be handled with IP takeover where you just make the new machine 111.111.1.1.

Probably a question for serverfault.

Answer 2

You're looking for DNS TTL (Time To Live) I guess.. In my opinion applications may cache the IP for at most the value of the TTL. I'm afraid however that some applications/technologies might actually cache it longer (agian in my opinion completely wrong)

Answer 3

Each machine will cache the ip address.

The length of time it is cached is the TTL (Time To Live). This is a setting on your DNS server, if you set it very low say 5 mins, then you show be up and running fairly quikly. A bit of a hack but it should work.

Answer 4

Yes, the other comments are correct in that what controls this is the DNS TTL set for the hostname database.mywebsite.com.

You'll have to decide what the maximum amount of time you're willing to wait for if you have a failure on your primary address (111.111.1.1) after you make the switch to the secondary address. Lower settings will give you a quicker recovery time, but will also increase the load and bandwidth to your DNS server because clients will have to re-query it to refresh their cache more often.

You can use nslookup using the -d option from your cmd prompt to see what your default TTL times and remaining TTL times are for the DNS server you are querying.

%> nslookup -d google.com

Answer 5

You should assume that they are cashed for two reasons not clearly mentioned before:

1- Many "modern" versions of OS families do DNS caching. 2- Many applications do DNS caching or have poor error/failure detection on live connections and/or opening new connections. This would possibly include your database client.

Also, this is probably not well documented. I did some googling, and found this for MySQL:

http://dev.mysql.com/doc/refman/5.0/en/connector-net-programming-connecting-connection-string.html#connector-net-programming-connecting-errors

It does not clearly explain its behavior in this regard.

Answer 6

The DNS gets cached, but for any server that resolves to the wrong ip address, you can update the HOSTS file of the server and the ip should be updated immediately. This could be a solution if you have a limited amount of servers accessing your database server.

Answer 7

I had a similar issue with a web site that disables the application pool recycling features and runs for weeks on end. Sometimes, a clustered SQL Server box would restart and for some reason, my SqlConnection's were not reconnecting. I was getting the error:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

The server was there - and running - in fact, if I just recycled the app pool, the app would work fine - but I don't like recycling app pools!

The connections that were being held in the connection pool were somehow using old connection information, and that could have been old IP addresses. This is what seems so similar to the poster's question, that it appears to be cached DNS information, because as soon as some sort of a cache is cleared, the app works fine.

This is how I solved it - by forcing all of the connections in the pool to be re-created:

Try
    ' Example: SqlDependency, but this could also be any SqlConnection.Open call
    Dim result As Boolean = SqlClient.SqlDependency.Start(ConnStr)
Catch sqlex As SqlClient.SqlException
    SqlClient.SqlConnection.ClearAllPools()
End Try

The code sample is just the boiled-down basics - it should be tweaked for your situation!