Slashdot Mirror
Providers Ignoring DNS TTL?
cluge asks: "It seems that several large providers give their users DNS servers that simply ignore DNS time to live (TTL). Over the past decade I've seen this from time to time. Recently it seems to be a pandemic, affecting very large cable/broadband and dial up networks. Performing a few tests against our broadband cable provider has shown that only one of the three provided DNS servers picked up a change in seven days or less. After turning in a trouble ticket with that provider - two of the three provided DNS servers were responding correct - while the third was still providing bad information more than two weeks after that specific change. What DNS caches ignore TTL by default? Is there a valid technical reason to ignore TTL?"
"This struck me as odd, and I decided to run a few tests using my own domain. Lowering the TTL to twenty four hours, and making changes and then checking to see when a change was picked up. I queried twelve outside DNS servers/caches that I had access to (Thanks to my friends and relatives with dial ups and DSL who put up with me and my requests to reboot their machine daily!). Checks performed against these outside DNS servers indicate that it may take as much as four to five weeks before a DNS change is picked up! Most DNS servers picked up the change within 48 hours. A small number did not (three out of twelve - that's a quarter of them!)
This merits more study, and prompts a few questions. So, before I begin with a more serious broad study, I'd like to get some feedback on the problem as I've seen it. I know the tin foil hat crowd will see the failure to propagate DNS correctly as censorship, and the OS/bind/djb/whatever zealots will simply see this as an argument for their particular religion.
Based on the responses I get, I will then setup and test a couple of domains with different DNS servers for 6 weeks and report back the findings. [volunteers welcome!]"
This merits more study, and prompts a few questions. So, before I begin with a more serious broad study, I'd like to get some feedback on the problem as I've seen it. I know the tin foil hat crowd will see the failure to propagate DNS correctly as censorship, and the OS/bind/djb/whatever zealots will simply see this as an argument for their particular religion.
Based on the responses I get, I will then setup and test a couple of domains with different DNS servers for 6 weeks and report back the findings. [volunteers welcome!]"
in VOIP networks TTLs can be as low as 10 minutes
Usually on big providers overriding the TTL of the zone is a usual practice for sure, I do that myself in the ISP I'm working for (it's middle sized).
But I don't think they're setting a TTL longer than 24 hours, that would be kind of insane, isn't? At least from my own experience when I did a big DNS servers change (changed all the serials) the delay was less than 24 hours for almost all of them.
May the source be with you!
nscd does not obey TTL by default. It uses gethostbyname(), which does not return TTL.
We use nscd quite a bit, as im sure many other providers do. We only cache positives for 30 minutes, so we dont end up ignoring it for too long.
.
Send a plain text email to
dns-subscribe@angrypeoplerule.com
This is a moderated list, and is only for letting people who are interested know when the study will begin, how to participate and the final results.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
They're referring to DNS TTL, not IP TTL.
And then there's the times when I just plain forgot to bump the serial number field. Works great on my master server after I restart it, but nothing else (especially my secondary) notices the change.
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
For example
dig @your-isps-nameserver.net -t A www.example.com
For example:Note the TTL of 7184 seconds (this is how long the nameserver at 192.168.0.1 will continue to use the cached record for before fetching it again from slashdot.org's authoratative nameservers).
Oolite: Elite-like game. For Mac, Linux and Windows
Pity you didn't paste the appropriate part of the wikipedia article.
"TTLs also occur in the Domain Name System (DNS), where they are set by an authoritative nameserver for a particular Resource Record. When a Caching (recursive) nameserver queries the authoritative nameserver for a Resource Record, it will cache that record for the time specified by the TTL."
http://en.wikipedia.org/wiki/Time_to_live
-- perl -e'print pack"H*","6e656d6f406d38792e6f7267"'
(Thanks to my friends and relatives with dial ups and DSL who put up with me and my requests to reboot their machine daily!).
/flushdns
ipconfig
There are many online DNS tools DNS report being one of the best and DNS stuff being very powerful but harder to use. I also like Dig it Man! for simple DNS checks. Also many large internet providers usually have allkinds of online network tools available online on their webpages.
Why did you need to contact your friends/relatives to check whether or not your domain gets propagated?
Couldn't you just query DNS servers directly using nslookup and/or dig?
Querying them directly would eliminate you from wondering if the machine you are checking from has the DNS cached and you wouln't need to flush it (why would you need your friends/relatives to reboot their machines?). Not to mention the amount of time you would spend in having to coordinate this type of testing.
Even if you don't want to use nslookup and/or dig from your Windows/Linux/Mac/whatever, there are tools available via the web that can help as well.
This certainly is not a list of all the tools, or even the best ones... they're just ones that I have used in the past:
dig Web-based "dig" tool
nslookup Web-based "nslookup" tool
DNS Report Checks for DNS errors and provides nicely formatted information on a given domain
DNS Stuff Various web-based DNS tools
"Very funny, Scotty. Now beam down my clothes."
Has anyone done any measurement stats on DNS queries
According to my DNS hosting company's FAQ:
"...or 200MB of usage is used (1 million DNS queries)"
I got a "Your machine is trojaned" e-mail with few details. A thorough scan of my network showed diddley-squat. I finally got to reasonable level support and the issue was poisoning the cache with negative lookups. I was testing the mail, and URLs within the mail as well. I think there was an average of 20 lookups/mail.
People running MailWasher on Windows also got the same warning from RR. All this was probably about a year ago.
Actually, the "TTL" in an IP header is different from the "TTL" in a DNS response (though in both cases the acronym means "time to live" and is intended as a limit on how long data hangs around).
IP header TTL is basically a hop-count, to stop IP packets going round in circles indefinately in the event of routing loops in the network.
Typically, when you look up a name like "www.example.com" your workstation consults a caching DNS server (on the local LAN, or offered by your ISP, or something). This DNS server goes off and talks to the root name servers, which refer it to the "com" name servers, which in turn refer it to the "example.com" name servers, from where it gets an IP address to go with the name. A couple of seconds later you ask for another page from "www.example.com". Your workstation asks the local DNS server for the information again, but the DNS server doesn't go and figure out the answer from scratch - it remembers the answer that it provided last time, and just repeats it. Time-To-Live is an "expiry date" that the authoritative name servers (like the "example.com" name servers) can put on their answers, so that the caching name servers know how long the answer is good for without them rechecking with an authoratative source.
Our company made a DNS change for a download server accessed by customers, over a month passed and multiple tickets opened with several large ISPS (Road Runner being the biggest) with no action taken. We finally had to setup a new server name for customers to be able to access the download server...
In all there were 3 large US isps that were major offenders...
Here in Argentina. We don't have bandwidth problems, bandwidth should be cheap considering the kind of conections that we have. But, all the bandwidth belongs to a few, that are not so interested in letting others grow, so they resell it at really high prices. So, since bandwidth _is_ a problem, many ISPs have Proxys, transparent Proxys, etc. The most dirty thing they are doing now is transparent proxys that never cleans their caches, content seems to never expire, etc. The other is DNSs that updates it's records all at once, every X days, not taking TTLs into account. I worked for about 2 years as a sysadmin for a hosting company, and this was a nightmare. Once, a customer's website was defaced, we cleaned up, restores a backup for him, but many people was still seeing the old website ... for more than a WEEK.
A solution to this problem would be a law, that would create a set of standard services that a comunications company may give, with well defined names and categorys, and it should be MANDATORY for companys to market their services using this names, in their comercials too. So, for example, we would have categorys such as "Full Duplex Simetric DSL Conection", or "ADSL, With Proxy, Blocked Ports".
WTF am I doing replying to an AC at 5 A.M on a Friday night?
Its completely within the spec, and as a fundemental principle I can do whatever I want with my server. So get with the program and understand there are other ways of dealing with the issue. Two weeks before the change, set the new IP address of the mail server as a lower priority (higher number) server, so if the info is cached, it will fall back to the new number when the old one fails. When you make the change, you can purge the old address entirely.
This is DNS maintenance 101, and should not surprise anyone who works on DNS.
Actually that's for TCP's time to live. For DNS TTL, here's the scenario: (and yes this is simplified; there is more that actually happens, but it's not important for this discussion)
:-)
Background
----------
Domain Name Servers (DNS) are usually configured in a heirarchy, such that each server has a parent. This fact will be important below.
Every domain (i.e. slashdot.org) has one or more "authoritative" name servers. These name servers know what web host slashdot.org is hosted on and how to get there.
Other DNS's on the Internet do not know how to get to slashdot.org, because they are not "authoritative" for that particular domain. So they send a request out to their parent asking how to get to slashdot.org. Eventually, one of the parents will know the address of slashdot.org's authoritative name server, and will return this address.
How This Relates To TTL
-----------------------
Here is what happens once the address of the authoritative name server is returned:
A = The name server trying to figure out how to get to slashdot.org
B = The authoritative name server for slashdot.org
A asks B how to get to slashdot.org
B responds to A with an address (66.35.250.150)
A asks B how long this address is valid
B responds to A with a TTL (e.g. 24 hours)
So now name server A will not have to ask for slashdot.org's address again for 24 hours, since it was told by the authoritative name server that it can keep the address for 24 hours.
This "keeping of addresses" is called caching, and name servers that do this are called caching name servers.
I hope this helps.
the root servers aren't recursive resolvers so you aren't really pulling from them in any meaningfull sense. you are just hitting them very occasionally when you use a new tld. Most of your data comes direct to your resolver from the authoritive nameservers. also the root nameservers are things that ABSOLOUTELY MUST STAY UP and measures would be taken to spread the load further if needed (this has already been done with bgp anycast for k-root).
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You could avoid this by pulling from THE root DNS servers, but if everyone did that it would put undue strain on the root servers
That's not how DNS works.
The root servers simply point you into the direction of the authorative DNS server for a given domain name. That is why you have to register who is going to be the DNS server for any given domain so the root servers can point people to it. Your own DNS then caches the response from the DNS server (not the root) locally, only updating it after the TTL is expired (which isn't always happening with the provider's DNS, hence the problem).
The root servers are reliable... they have to be. Sure there have been DoS attacks and the like on them before, but they only need to update themselves for new domain name server registrations (which last I heard is every 5 minutes? So that's a much better "ttl").
My dad uses Comcast and he kept calling me to "make the Internet work" during their recent DNS outages. I just SSH'd in to his router and added a Verizon DNS server (4.2.2.1) to his DHCP info, and his Internet worked right away. His neighbors were complaining they couldn't use the 'Net but he was surfing away just fine.
Grandparent is full of shit or doesn't understand what this thread is about.
Serials are primarily for the two servers do get the same data (primary/secondary), so when the secondary is done waiting it goes to look at the serial on the primary and grabs the new zone transfer if the serial is higher.
TTL on an A record is just a recomendation (a specific setting that over-rides the default TTL for the zone up near the SOA).
IF a server has cached an A record with a TTL of 6000 seconds (just under 2 hours) it should hold and server data for only a maximum of 6000 seconds, and after that time dump the data and go get new data from the authoritative name servers.
If you do a DIG against them, they'll tell you how much time is left on a cached record.
Serial doesnt come into the "when to drop cached data" transaction at all.
Sure, not incrementing the serial can cause all sorts of problems. But that's not what the article is on about.
AOL et. al are ignoring specific A record TTL and putting their OWN TTL on cached information that over-rides mine. (I know this because the tool I use makes it so I CANT forget to incriment the serial, and I still run into TTL problems. What about that smartypants?) So when I set a domain from default to 3600 seconds a day before an MX record (email server) change and they ignore it, email migration from one server to another stays messed up for days rather than the hour my TTL would do. A good admin doesnt abuse TTL (like yahoo apparently does...) and sets it back up higher when finished moving stuff, most of the time I am prefectly happy with the nice long standard cache time. But sometimes you NEED a low TTL.
I got the O'Reilly Grasshopper book right here in front of me and none of the TTL sections mentions SOA needing increment for TTL caching. If someone wants to point out a page number that says I am wrong I'd be happy to shut up. But self-righteous indignation better be fact checked... seriously.
There was an article called On the Responsiveness of DNS-based Network Control presented at the Internet Measurement Conference" last year. It is based on data from the Akamai content distribution network and shows that some DNS servers and even more client applications do not honor DNS TTL information.
To be even more specific, here is how a typical lookup happens (assuming NO cached data):
....." ...." ... google.com NS ns1.google.com"
Specifics per implementation might be off, but either way it ends in the same result:
Recursive -> Root Server: "ANY? www.google.com"
Root Server -> Recursive: "com NS a.gtld-servers.net
Recursive -> a.gtld-servers.net: "ANY? www.google.com"
a.gtld-servers.net -> Recursive: "google.com NS ns1.google.com
Recursive -> ns1.google.com: "ANY? www.google.com"
ns1.google.com -> Recursive: "www.google.com A 1.2.3.4
As you can see, the root server only provides information for the top level domains. Those being com, org, us, uk, au, etc.
It's commonly thought that they handle things like 'google.com' which isn't true. google.com, in thise case, would be known by {a,b,c,d,etc}.gtld-servers.net. Each TLD has its own nameservers, obviously. But com and net use those.
As for the TTL issue. I do offer Dynamic DNS which has a default TTL of 180 seconds, however I have not run into this personally. Or myself and my users just haven't noticed it.
Regards,
-JD-