连接字符串 DNS 查找是否会被缓存？
假设如下：
我在 database.mywebsite.com 上设置了一个数据库，该数据库解析为 IP 111.111.1.1，从我们网络上的本地 DNS 服务器运行。
我有无数的 ASP、ASP.NET 和 WinForms 应用程序，它们使用连接字符串，利用 database.mywebsite.com 作为服务器名称，所有这些应用程序都从内部网络运行。
然后运行数据库的机器死机了，我切换到 IP 为 222.222.2.2 的新机器。
因此，我将 database.mywebsite.com 的 DNS 更新为指向 222.222.2.2。
所有应用程序和运行它们的计算机是否都会缓存旧的已解析 IP 地址？
我假设他们会的。
任何类似于“每次切换盒子时不要更改 IP”的建议都不太受欢迎，因为不幸的是，我无法控制这方面的情况。 我们目前使用的是盒子的机器名称，每次盒子死亡时都会改变，所有应用程序等都必须使用新的机器名称进行更新。 好痛。
Suppose the following:
I have a database set up on database.mywebsite.com, which resolves to IP 111.111.1.1, running from a local DNS server on our network.
I have countless ASP, ASP.NET and WinForms applications that use a connection string utilising database.mywebsite.com 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 222.222.2.2.
So, I update the DNS for database.mywebsite.com to point to 222.222.2.2.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
即使 DNS 没有缓存在计算机本地，它也可能会缓存在计算机和名称服务器之间的 DNS 链上的某个位置，至少会缓存一小段时间。 我的理解是，这种情况通常可以通过 IP 接管来处理，只需将新机器设置为 111.111.1.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.
我猜你正在寻找 DNS TTL（生存时间）。在我看来，应用程序最多可以缓存 TTL 值的 IP。 然而，我担心某些应用程序/技术实际上可能会将其缓存更长时间（我认为完全错误）
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)
每台机器都会缓存ip地址。
缓存的时间长度就是 TTL（生存时间）。 这是您的 DNS 服务器上的设置，如果您将其设置得很低（例如 5 分钟），那么您会显示出相当快的启动和运行速度。 有点黑客，但它应该可以工作。
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.
是的，其他评论是正确的，因为控制它的是主机名database.mywebsite.com 的DNS TTL 设置。
在切换到辅助地址后，如果主地址 (111.111.1.1) 出现故障，您必须决定愿意等待的最长时间。 较低的设置将为您提供更快的恢复时间，但也会增加 DNS 服务器的负载和带宽，因为客户端必须重新查询它以更频繁地刷新其缓存。
您可以使用 nslookup 在 cmd 提示符下使用 -d 选项来查看您正在查询的 DNS 服务器的默认 TTL 时间和剩余 TTL 时间。
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.
您应该假设它们被兑现的原因有两个，之前没有明确提及：
1- 许多“现代”版本的操作系统系列都进行 DNS 缓存。
2- 许多应用程序都会进行 DNS 缓存，或者对实时连接和/或打开新连接的错误/故障检测很差。 这可能包括您的数据库客户端。
此外，这可能没有很好的记录。 我做了一些谷歌搜索，发现了 MySQL 的这个：
http://dev.mysql.com/doc/refman/5.0/en/connector-net-programming-connecting-connection-string.html#connector-net -programming-connecting-errors
它没有明确解释其在这方面的行为。
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.
我在一个网站上遇到了类似的问题，该网站禁用应用程序池回收功能并连续运行数周。 有时，集群的 SQL Server 机器会重新启动，并且由于某种原因，我的 SqlConnection 没有重新连接。 我收到错误：
服务器在那里 - 并且正在运行 - 事实上，如果我只是回收应用程序池，应用程序会正常工作 - 但我不喜欢回收应用程序池！
连接池中保存的连接以某种方式使用旧的连接信息，并且可能是旧的 IP 地址。 这看起来与发帖者的问题非常相似，它似乎缓存了 DNS 信息，因为一旦清除某种缓存，该应用程序就可以正常工作。
这就是我解决这个问题的方法 - 通过强制重新创建池中的所有连接：
代码示例只是简化的基础知识 - 应该根据您的情况进行调整！
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:
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:
The code sample is just the boiled-down basics - it should be tweaked for your situation!
DNS 会被缓存，但对于任何解析到错误 IP 地址的服务器，您可以更新服务器的 HOSTS 文件，并且 IP 应立即更新。 如果访问数据库服务器的服务器数量有限，这可能是一个解决方案。
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.