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
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.
And the dnscache resolver cache service in win2k and up.
Support policy for DNS client-side caching - Windows Client | Microsoft Learn
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.
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
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.
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.
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