Providers Ignoring DNS TTL? 445
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!]"
24 hours ? (Score:4, Informative)
DNS practices (Score:5, Informative)
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.
nscd (Score:4, Informative)
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.
If you want to help then (Score:5, Informative)
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.
Re:For non geeks (Score:5, Informative)
old data (Score:5, Informative)
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.
Re:Dumb question (Score:5, Informative)
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).
Re:nscd (Score:3, Informative)
Yeah but nscd just caches for your local server box, it doesn't re-serve the cached results to your remote clients. He's describing actual dns cache/forward servers ignoring TTL and handing outdated/bad data to client machines.
Re:For non geeks (Score:3, Informative)
Re:For non geeks Actually (Score:1, Informative)
So close... (Score:5, Informative)
"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
reboot? (Score:5, Informative)
ipconfig
Re:Dumb question (Score:5, Informative)
comcast (Score:2, Informative)
How to check your DNS (Score:4, Informative)
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 [kloth.net] Web-based "dig" tool
nslookup [kloth.net] Web-based "nslookup" tool
DNS Report [dnsreport.com] Checks for DNS errors and provides nicely formatted information on a given domain
DNS Stuff [dnsstuff.com] Various web-based DNS tools
Re:What's the point of not updating anyway... (Score:4, Informative)
According to my DNS hosting company's FAQ [zoneedit.com]:
"...or 200MB of usage is used (1 million DNS queries)"
Re:Let me guess... (Score:3, Informative)
People running MailWasher on Windows also got the same warning from RR. All this was probably about a year ago.
Re:For non geeks (Score:3, Informative)
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.
Re:DNS practices (Score:2, Informative)
Part of the problem with short TTL is that there is no really good mechanism in the Internet today for failing over a cluster of web servers short of buying expensive routing hardware. If you want to run a web server with a backup then having a short TTL is probably the best option around. What we need is a better DNS failover strategy and then many short-lived TTLs will probably go away. The current solution is crummy anyway. When Internap died here in Seattle and we were down for 45 minutes (along with LiveJournal [slashdot.org]), a high priced router/load balancer wouldn't have done us a bit of good.
Article is right on the money (Score:5, Informative)
In all there were 3 large US isps that were major offenders...
We have had this issue for years .. (Score:3, Informative)
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".
Re:Faulty system (Score:3, Informative)
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.
Re:For non geeks (Score:3, Informative)
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.
Re:How to check your DNS (Score:2, Informative)
Re:Bypass their DNS (Score:3, Informative)
Re:Bypass their DNS (Score:5, Informative)
My two cents on the issue (Score:2, Informative)
What i found is if the TTL is set to less than 3 hours it is automaticly reset to 3 weeks.
As a result I have set all of out TTLs to at least the 3 hour minimum.
Re:DNS practices (Score:2, Informative)
Therefore overriding TTL can break things for your customer.
I can see raising any TTL of less than an hour to an hour, I can't see raising it to 24 hours or more. This would limit what breaks for your customers.
Re:Bypass their DNS (Score:3, Informative)
Re:24 hours ? (Score:4, Informative)
(For those that haven't messed with Akamai, they're intentionally setting the TTL insanely low to force clients to re-request often...Akamai uses the response they give as a way of doing path optimization to clients. It's ugly, but it kinda works.)
Re:Submitter is Correct, it's happening (Score:3, Informative)
What's the easiest way to check to see if your machine does indeed fetch records from another server? dig?
Re:Bypass their DNS (Score:5, Informative)
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").
Re:DNS practices --- CHANGE THE !@#$%^& serial (Score:3, Informative)
Ok, can you point me to anywhere in RFC1034/RFC1035/RFC2308/etc that says that the SOA record has anything to do with the TTL? The nTTL, yes, but not the TTL. Yeah, if they don't change the serial number, their secondary name servers will take a long time to expire (could be weeks), but again, this doesn't have anything to do with your claim that if the serial number doesn't change, then the TTL is ignored.
Have I just been trolled?
Re:Bypass their DNS (Score:3, Informative)
Re:reboot? (Score:1, Informative)
sc stop dnscache
sc start dnscache
or, just use
ipconfig
like the GP suggested and save yourself some typing
quick fix (Score:3, Informative)
Re:DNS practices --- CHANGE THE !@#$%^& serial (Score:5, Informative)
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.
Scientific article about this (Score:5, Informative)
Re:Bypass their DNS (Score:5, Informative)
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-
A French lesson. (Score:2, Informative)
Actually, the word du does mean "of the". It's the equivalent of de and le together. It's le jour because it's masculine.
Re:Bypass their DNS (Score:3, Informative)
Setting up a proper DNS server isn't too hard (as indicated by the number of posters that have done just that). However, it does take a bit of knowledge about how DNS really works. To that end I suggest you read some books about Networking, and DNS in particular.
I've found the O'Reilly books to be fairly easy to read while providing a great starting point for those that have a broad, basic understanding of how networks (and computers) operate. Specifically, I'd recommend DNS and BIND [amazon.com]. This assumes that you have some LAN experience, this is a great place to start. It does tend to focus a bit on BIND (Berkley Internet Name Domain), but most DNS servers are based on it's general feature-set and configuration, anyway.
By itself, this book won't allow you to set up your own DNS server. However, it will help you get that core understanding of HOW DNS actually works and what you can get it to do for you. You'll have a choice of software on a number of differnet platforms, but the general operation will pretty much be the same across them all.
And there are plenty of other books and publications on DNS, so don't limit yourself if O'Reilly doesn't do it for you.
This probably wasn't the answer you were looking for, but it really is what you needed.
Re:Bypass their DNS (Score:3, Informative)
That is to say, if i query a.gtld-servers.net for www.bob.com IN A, and bob.com is delegated to ns1.bob.com and ns2.bob.com, the registry will know the IP addresses of bob.com's two nameservers and return them in the 'additional' section (otherwise nobody would ever be able to find anything under bob.com, including ns1 and ns2.bob.com).
If bob.com is delegated to ns1.foo.com and ns2.foo.com, but foo.com is delegated somewhere else, then ns1/ns2.foo.com's A records WILL NOT be returned as glue, and your resolver will have to recursively query for those, as well.
It's amazing that DNS works at all.