Does anyone know if there is a research paper or statistics related to what percentage of DNS servers do not adhere to advertised TTL's? I am looking for some verifiable research on this topic if it is available. Thanks, Steve
Although you asked for DNS servers - it helps to remember that no matter what the servers and resolvers do - IE will bring that behaviour to naught in many cases http://support.microsoft.com/default.aspx?scid=KB;en-us;263558 "Thurman, Steven" <steven.thurman@wamu.net> wrote: DNS TTL adherence Does anyone know if there is a research paper or statistics related to what percentage of DNS servers do not adhere to advertised TTLâs? I am looking for some verifiable research on this topic if it is available. Thanks, Steve
ennova2005-nanog@yahoo.com wrote:
Although you asked for DNS servers - it helps to remember that no matter what the servers and resolvers do - IE will bring that behaviour to naught in many cases
http://support.microsoft.com/default.aspx?scid=KB;en-us;263558
*/"Thurman, Steven" <steven.thurman@wamu.net>/* wrote:
Does anyone know if there is a research paper or statistics related to what percentage of DNS servers do not adhere to advertised TTL ’ s? I am looking for some verifiable research on this topic if it is available. Thanks,
Steve
And the dnscache resolver cache service in win2k and up. http://support.microsoft.com/kb/318803/en-us http://support.microsoft.com/kb/245437/EN-US/ If you are expecting hot cutovers to anything by utilizing DNS, sure seems that you need to expect to support traffic to the values of the old records for some time. And if you are expecting very long TTL's to give you extra insurance for outages and what-nots, expect spotty effectiveness.
On Wednesday 15 Mar 2006 02:32, Joe Maimon wrote:
And the dnscache resolver cache service in win2k and up.
http://support.microsoft.com/kb/318803/en-us http://support.microsoft.com/kb/245437/EN-US/
Both these article say the DNS TTL is honoured by the cache. Microsoft may have done some horrid things with DNS over the years, but returning stale data just breaks things.
If you are expecting hot cutovers to anything by utilizing DNS, sure seems that you need to expect to support traffic to the values of the old records for some time.
Nope. You can bin traffic as soon as the TTL for it expires. Everything else is broken, and experience here is that it is either spam/zombie generated or googlebots <sigh - there is always one>.
And if you are expecting very long TTL's to give you extra insurance for outages and what-nots, expect spotty effectiveness.
Agreed, there is no requirement to cache records for the whole of the advertised TTL (or -ve TTL). In answer to the original question, I'm not aware of any DNS servers that don't expire data at the end of the TTL period correctly. Failing to expire such data would be a good way of breaking things, and people would just not use such broken software. I'm not sure why the OP thinks someone would research such a bug in detail, my experience is they would just fix it.
On Mar 15, 2006, at 1:56 AM, Simon Waters wrote:
In answer to the original question, I'm not aware of any DNS servers that don't expire data at the end of the TTL period correctly. Failing to expire such data would be a good way of breaking things, and people would just not use such broken software.
Let me help you become aware, then...
I'm not sure why the OP thinks someone would research such a bug in detail, my experience is they would just fix it.
Some people don't believe it is a bug, and therefor don't see that anything needs "fixing". Feel free to, for example, send 2 consecutive queries for a record that has a short (<10,000 second TTL) to 212.23.11.206. This is one of the over 100,000 random open recursive servers that have been party to some of the recursive DNS server amplification DDoS attacks over the last few weeks... and this behavior exists in a number of them. If you can't think of a record to query for that has a short enough TTL, I've created a wildcard entry of: *.example.centergate.com so that you can test this repeatedly without having to wait for the overridden TTL to expire. Just use a different random wildcard record each time (remembering to send 2 consecutive identical queries to see the misbehavior). $ dig @212.23.11.206 jhgfd.example.centergate.com a This behavior is unfortunately not unique. /rlj
On Wednesday 15 Mar 2006 14:16, you wrote:
Let me help you become aware, then...
:)
Some people don't believe it is a bug, and therefor don't see that anything needs "fixing".
Oh the one shown is a bug, and needs fixing.
Feel free to, for example, send 2 consecutive queries for a record that has a short (<10,000 second TTL) to 212.23.11.206.
Safecom http response, busybox on telnet, some sort of embedded Linux device. Safecom sell routers... Of course can't tell if the broken DNS behaviour is the device, or possibly it is proxying upstream DNS servers.
This behavior is unfortunately not unique.
Alas what others peoples servers do, shouldn't be an issue for you. Your problem is they can be coerced into a DoS attack, not that the data is stale.
On Wed, 15 Mar 2006, Simon Waters wrote:
This behavior is unfortunately not unique.
Alas what others peoples servers do, shouldn't be an issue for you. Your problem is they can be coerced into a DoS attack, not that the data is stale.
Tell that to a customer when you've moved some resource of theirs to a different IP...having been careful to decrease the TTL well in advance. Some parts of the internet are simply broken and beyond your control. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Wed, 15 Mar 2006, Simon Waters wrote:
This behavior is unfortunately not unique.
Alas what others peoples servers do, shouldn't be an issue for you. Your problem is they can be coerced into a DoS attack, not that the data is stale.
actually, dos-attack-aside, the interesting thing is that lots of people (original poster perhaps included) believe that TTL's are adhered to except in some marginal cases. I think Rodney's point is that they are not adhered to anywhere near as much as we would all like to believe :( So, if you, or the original poster, is going to move ${important_resource} around ip-wise keep in mind that your ${important_thing} may have to answer to more than 1 ip address for a period much longer than your tuned TTL :(
participants (7)
-
Christopher L. Morrow -
ennova2005-nanog＠yahoo.com -
Joe Maimon -
Jon Lewis -
Rodney Joffe -
Simon Waters -
Thurman, Steven