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!]"
The whole thing about the web is it's based on trust... it's amazing it works as well as it does... I can see providors not obeying TTL simply to keep their DNS servers from being stuffed (or whatever the word du jour is)... It's all about trust, and the lack of it nowadays on the web... get used to this sorta thing happening more and more.
---
Programming is like sex... Make one mistake and support it the rest of your life.
How would I check my ISPs DNS servers for this?
Of course there is a reason, To save bandwidth, and to provide the 3rd world internet service we have come to expect here in the USA.
Ad eundum quo nemo ante iit!
RoadRunner
They can't run a DNS server properly to save their lives.
TTL is ignored, SpamAssassin is a "trojan DDOSing our network"
It kind of defeats the point of root DNS servers being updated so fast if the ISPs are going to drag their feet and take their time updating their cache. I speculate it is server admin laziness.
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.
.
Mediacom is no better when it comes to rehashing. It too them over a week for changes to take effect on a domain of mine.
called laziness.
IGB: More fun than eating oatmeal!
Time to live (TTL) is an 8-bit field in the Internet Protocol (IP) header that indicates how many more hops this packet should be allowed to make before being discarded or returned. It is the 9th octet of 20 in the IP header.
and
Shorter TTLs can cause heavier loads on an authoritative nameserver, but can be useful when changing the address of critical services like web servers or MX records, and therefore are often lowered by the DNS administrator prior to a service being moved, in order to minimise disruption
Hope thaty helps someone beside me :-)
Save a Life. Donate Blood. Please.
There have been DNS security concerns lately, specifically the 'cache poisoning' vulnerabilities reported by cert, sans et al.
Maybe some ISPs have altered their DNS servers to provide better protection, and in the process caused the 'ttl' problem ? (improbable imo, but who knows...)
It'd be interesting to know if this is recent or if it's already an old problem.
Knowing if it appeared suddenly or progressively would help as well.
Too bad there isn't such a thing as the wayback machine for dns and other services...
I remember once I had the TTL set on a bunch of domains to over a year. I found out its a great way to retain customers, because their domains will not work anywhere else.
it sounds possible the OP lowered the TTL on entries expecting that to have a retroactive effect on servers with the entries already cached. can we get confirmation that this is not what is happening?
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.
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
"Titty" is an adult word and therefore TTL is censored by many ISPs.
Could this be caused by improper setup of NS1 and NS2 servers? I've seen a few examples of this myself, everything from server's having their AXFR open to everyone, and yet not replicating, to admin's not removing obsolete NS server's from their server's.
I predict DNS server's will be the next rogue type server similar to the DHCP server plagues..
Perhaps this measure is meant to save some ressources on IPS's DNS servers if they have to query a lot of foreign DNS with low (and possibly overestimated) TTLs ?
I don't really know in-depth DNS mechanisms, but maybe ISPs are keeping a minimum TTL according to the average time between two updates of a given DNS entry ?
DNS queries are figgin tiny...
So, what's it really save you, even if you're a massive ISP to not obey the TTL's?
The only thing it's going to save you is from having to go out to the root servers and pull it again when the TTL expires. And, I speculate that this really is a very, *very* small amount of traffic compared to the other traffic to those servers.
I'd expect the highest bandwidth/resource users, by a very large margin, to be standard "in-TTL" answers to DNS clients.
So, these cranks, for lack of a better term, simply bork the systems they manage for no appreciable gain from doing so. Reducing spam by 0.0001% would have vastly more impact on the servers they maintain than ignoring TTL's.
Has anyone done any measurement stats on DNS queries. How much of the total traffic is DNS. I can't imagine it's even 0.5% of an average ISP.
Cheers,
Greg
Saving bandwidth is the only reason. It still a pain in the ass though. I found out the hard way when I though I was moving a website to a different IP address for the first time. I normally set the TTL to 7 days. So 7 day before the planned move I set the TTL to 1 hour. We switched the IP address and everthing was fine using ISP that followed DNS rules. AOL still had the address cached though. We didn't find out about teh problem with AOL right away. Our additude at the time was well screw the AOL users, there's no one importing using AOL anyways. I think it took a month before AOL finally updated to the right IP address. This definately makes it hard to do dns moves. At least with smtp you can add the mx record of the new server in advanced.
apathy.
Best Slashdot Co
I'd say so. If you are running a huge ISP, the bandwidth savings you'd get from caching DNS entries longer could be significant. It's a double edged sword, though...It'd certainly raise hell with dynamic DNS hosts, or networks that were in the process of changing ISPs and purposefully reduced their TTL to a very short time period to facilitate the switchover.
:-/
But then, if you are a huge ISP, you probably don't care much about such things. As always, money trumps common courtesy.
-R
Time to Live (TTL) when in relation to DNS issues is the maximum amount of time in seconds that a cacheing nameserver should cache an answer before going and checking again from an authorative source before handing it out.
Give me one good reason why TTL is useful.
It allows caching.
If you don't understand why that's an excellent reason or why it's useful, then you have an even poorer understanding of how DNS works and why it's around than I do, and I admit my understanding is rudimentary.
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"'
Yes there is, the other way around though. I used to maintain DNS servers for ISPs in the Netherlands and turned of caching completely. That way you prevent update problems and cache poisoning.
DNS caching was invented when bandwidth and CPU time were expensive. Not the case anymore. Caching is silly.
(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
Because its the 'save $0.05 a million times' attitude for alot of them. The CTO recognizes that by saving that little tiny bit of bandwidth he can save a fraction of a penny, accumulated over a period of time.
The other problem is lazy or incompetant sysadmins...
Lowering the TTL from what? Perhaps the former TTL had not expired, in which case all your tests were bogus. Did you wait for 2 times your former TTL before beginning your tests, to ensure all DNS servers out there would see your new 24-hour TTL?
Its a classical economic tradeoff. You have less accurate information, but you use less resources to get it. Quickly updated DNS servers means bandwidth and processing power. The queston is how to find the amount of time that is "good enough" for the target users. Honestly, how often should a domain's IP be changing? Maybe every day at most, and I think this is pushing it. If you've got a domain that changes more often than that, perhaps you should be relying on something other than the global DNS system to route your changes down to users. Special needs require special software.
Some spammers setup DNS for web sites so that it's continually rotating through a number of different IPs, probably a number of them zombied PCs with web servers. The real stuff like transactions gets passed to other servers, but these disposable boxes act as lightning rods: A spam run won't be wasted if a few of them get complaints and taken down.
One line blog. I hear that they're called Twitters now.
I'm a bit curious about this test case. It says the TTL was changed TO 24 hours and then checked to see how long it took for results to propogate. What was the TTL set to for these entries before the change? If it was set to 2 weeks and was just queried before the change occured, there is no reason for the server to recheck just because it was changed to 24 hours.
The TTL should stay the same for a while and then try simply making a change without modifying any other configuration to avoid any other problems with this test.
Thanks to my friends and relatives with dial ups and DSL who put up with me and my requests to reboot their machine daily!
If you're rebooting client machines to check DNS records, then I'm forced to view your entire study with caution.
Last week, two nights in a row, Comcast's DNS was down NATION(USA) WIDE.
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."
I submitted a story similar to this one about a month ago regarding my experiences with direcway.com.
One of my customers was behind their network and we moved his email to our server. They couldn't access their domain name of course since it didn't exist on the server direcway's dns pointed to.
So I called them. Huge mistake. I spent hours on the phone escalating through foreign phone monkies until I made it to someone in management. Her attitude was that I was in the wrong regardless of what I had to say. Finally she lowered her defense just long enough to see that I was right but told me there was nothing they could do and that I wasn't allowed to talk to the people that run the DNS servers.
So I wrote a nasty little letter to corporate. 4 days later it was fixed. Not sure if the letter helped or not.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
We switched mail servers at our web host and that changed the IP addy of our mail. Two weeks later I looked at the mailboxes on the old server and find that they were still getting about a 10-20 spams per day.
As an aside, whitelisting our valid email accounts and filtering mail "received from" our own IP addy knocks out about 20-30% of our spam. It appears spammers try to sneek one past by spoofing the header to look like it came from inside. If so, spammers use DNS to get IP addys and then use the IP. I doubt they even think about TTL.
Two wrongs don't make a right, but three lefts do.
I've heard from a few people that many people are setting their TTL to like 5 minutes; due to this the ISPs are ignoring the TTL.
rooooar
I actually just tested dnscache, BIND, and Windows DNS, and by default they all respect A record and CNAME TTLs. one of theme (i forget which one, Windows DNS, or BIND, actually drop the cache entry 1 second before the TTL is about to expire).
Browsers caches are a different story, however. Try to figure out Internet Explorer's caching strategy. it took me a few days before I realized it uses a floating 2 minute TTL.
I solved the problem by routing around the providers' poor DNS servers by pointing my home LAN to my own DNS server on my colo box. I run a DNS server in my house which then identifies my colo DNS server(s) with the forwarders option. Instead of relying on who-knows-what from the ISPs I use my own DNS server that I set up and am responsible for.
I know it's not a solution for everyone, but it does let me avoid stupidity. And having my own, reliable DNS server sure came in handy recently since Comcast has been having bad DNS problems the last couple of weeks.
If it's all about trust, then you don't want to extend the TTL, you want to *shorten* it. That way if you're hit with a cache-poisioning attack, you get the correct record *faster*, instead of holding on to crap for weeks.
Besides, this behavior blows up all sorts of geographical load balancing, datacenter failover, etc. type solutions (google for a F5 3DNS device sometime).
Bad stuff, mucking about with the TTL that someone has assigned to a record. It's not arbitrary information. To those fucking with TTLs, how about we arbitrarily alter the numbers in your paycheck? Oh? What's that? That doesn't seem like a good idea? Gee. Go Fig. HANDS OFF MY TTL, ASSHAT.
-AC
You quoted the IP TTL info, not the DNS TTL info. Although they are both called "time to live", they are unrelated and trigger very different behavior from their respective protocols.
No, last post. But not any more.
It allow changing the IP address of a server name dynamically - set the TTL to 60 seconds. There are some fail-over mechanisms that use this as a backup method. If you set up your own DNS servers for your domain then you only have to worry about client computers using their own cache which might be old.
My old employer used to lower the DNS TTL time of records to five minutes for switching services over from one server to another. There were often cases where entire ISP's would ignore it and the users would be SOL for the 24 - 48 hours it took for them to update their record. Frankly, I agree with any ISP setting a floor on TTLs, otherwise it exponentially increases the load on the DNS servers.
you are simply NOT a huge ISP if your "bandwidth" is impacted by DNS traffic.
"If...you can't be a good example, then you'll just have to be a horrible warning" - Catherine Aird
Sysadmins of large, public websites know this one all too well. Well planned data center moves may set the TTL to 5 minutes, but that doesn't mean anyone will respect your TTL.
Once it's in DNS, it's going to stay there for a long time. Any transition plan has to monitor traffic on the old IP over the course of days to see when 99% of the traffic has tailed off. It sucks, but there it is. He who owns the DNS server, 0wnz the net.
Top Tier - 4.2.2.1
4.2.2.2
That reason is "didn't receive NXDOMAIN, received delegation information, but I can't reach the server that the domain is delegated to in order to get new information so I'll return the old information and hope its still right."
Works great in these days of DNS servers with poor stability (for whatever reason).
TTL is not the same as a proactive refresh mechanism, no? In other words, once an entry passes it's TTL, it's NOT the case that the DNS server in question immediatly sends out a query to the root name server to update it's cache.
How this SHOULD work is that, if a request comes in, the DNS server will first check it's cache. If there is a cache entry AND that cache entry is not past it's TTL, return the cached entry. Otherwise, refer to the parent nameserver and cache the response, starting the TTL timer over.
In other words, stale entries should be expected--they won't be removed until someone actually requests this domain again.
Um...
/flushdns /registerdns
ipconfig
ipconfig
But wouldn't an easier way be just using dig to directly query the name servers?
Ahhh the geek mentality. Someone posts a very insightful opinion that TTL is useless and geeks get their panties in a bunch and haul off to mark someone as troll.
.. what?
How about *gasp* giving a valid reply??
Haha, does the truth hurt you or
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?
this greatly reduces network traffic, as your records will be cached for over 68 years. if caching worked as described in the rfcs, you could probably even forget about keeping your domain registered after a few years, most folks would still come to you even if someone else bought your domain. of course ipv6 is coming any day now and that will probably ruin my evil plan.
The problem was not consistent, some of their servers displayed it and others (lesser number) did not - I believe that the ones that actually did use TTL properly were in fact the newest ones, and that at some time they were pushed into the mold of the old ones after they were put into service.
Been there, done that, paid for the T-shirt
and didn't get it
Caching DNS queries beyond the TTL value decreases the amount of bandwidth that an ISP must allocate to DNS by reducing the number of DNS requests that generate internet-bound traffic.
Basically, they can shove more customers onto one connection if they break DNS in this fashion.
Makes for a pretty good test of a providers clue vs. greed, come to think of it.
*sigh*
This post is a troll... but in case the poster came by their lack of clue honestly I'll bite...
1) to spread the dns serving load, keeping the answer to "what is the ip address of google.com" in a nearby dns server for "awhile" is a good thing
2) the operator of the nearby dns server could decide that "awhile" is a week... but then your dynamically updated dns entry for your PPPoE connection won't be updated by the time you get to work and want to listen to your MP3s
3) the operator could decide that "awhile" is an hour, and then the authoritative server for "google.com" would be buried in requests
4) Better to let the operator of the authoritative server tell the nearby servers how long "awhile" should be.
The issue isn't that the clueless "nearby" DNS administrators ignore TTLs and do not cache at all... the issue is that they ignore what the authoritative server suggests is appropriate but they cache anyway... so you can't listen to your MP3s because your work computer thinks your collection is still where it used to be a week ago, even though the authoritative DNS entry has changed an hour ago.
The TTL is only for non-authoritative nameservers, not secondaries (slaves). It tells the nameserver exactly how long to keep a record in its cache after doing a recursive query to lookup that record on behalf of a client. The TTL countdown begins the second that a nameserver receives a reply back from its query. If you change a zone file and refresh your secondaries, that has absolutely no effect on any cached record until the initial TTL expires and that record is automatically removed from cache, or the cache is purged. Then (and only then) will a subsequent lookup retrieve a fresh record. Only authoritative nameservers will retrieve fresh records via a zone transfer (or partial zone transfer) when the serial number is incremented for that zone, but that has nothing to do with the TTL.
Your original post does not specify what the original TTL was before you changed it. Was it two weeks, or longer? If so, then you should not expect any records to expire from anyone's cache until that TTL is reached, even if you change the TTL in the zone or for a specific record. Only authoritative nameservers receive NOTIFY messages that a zone has changed. Caching nameservers that are not authoritative do not, and it would be self-defeating for them to check with the authoritative nameserver every time they receive a request for a record that they have in their cache. That is the way DNS is supposed to behave and it is not a conspiracy.
Just to be on the record, a number of local ISPs here in Vermont don't update DNS records for 2-3 weeks. Sovernet, our big local provider, is among them. Very frustrating.
This of course breaks those expensive DNS appliances that cut the TTL to zer0 for the purpose of wide area failover. This is why I chose to run BGP intead of making F-5 rich...
.sig
This has come up a few times lately, but I'm now running Djbdns and caching DNS directly from rootservers. I've given up on ISP's DNS staying up to date. Here are the previous threads:
d =12178906
d =12156398
http://ask.slashdot.org/comments.pl?sid=145460&ci
http://ask.slashdot.org/comments.pl?sid=145189&ci
The more this comes up, the more I think that I (and many others) are on the right path of running such things like this, as well as web, email servers, etc, is the right way to go. How much of the 'joe users' out there that would want to do this? Probably none, but I think it points to a niche market were some geeky types could get together and provide these services (basically anything that is outside, or *free extras* from an ISP). So DNS, web hosting, email, spam, virus, chat, etc - run by ppl that want to do that the best, and not run an ISP. Leave it to Speakeasy to run a great ISP, but leave it to others to run a great services based Co-lo. Hmmm...I would like to do that.
bo
bad_outlook
--
Is this vague enough for you?
... I havent' yet seen. DNS uses UDP.
While I am no master in these areas, are DNS updates also using UDP? If so, with the congestion in the networks of today, could it be that DNS UDP update packets simply have got lost?
Still not a plausible explanation for the times of day a decent DNS cache would request authorative info from upstream, especially for several weeks with a very short DNS TTL. The cache should get it at least once in 472 (or whatever) attempts, right?
Another thing I've recently noticed that you might want to study is corporate IT departments (and even one major ISP) putting their DNS servers behind a firewall that black-lists "public" (dhcp/dialup) IP addresses and doesn't respond to them.
This is very disconcerting when you have your own caching resolver locally because you know that your upstream provider has a DNS server that is broken (too long TTL for example)
I have my /etc/resolv.conf pointing at my own named because I use it to monitor the DNS servers I administer out in a couple of colocates. I can't resolve (for example) our local gas company's web address because their DNS servers are behind their firewall and won't talk to my IP address off my cable modem. Doing a lookup from my colocate addresses works fine.
This is very much an issue now that cable and DSL is being used for corporate feeds.
Been there, done that, paid for the T-shirt
and didn't get it
I work for a large mortgage company, and we just got screwed with this a few weeks ago. An admin accidentally made a change to our external DNS when the change was supposed to be internal only. Our TTL was set at 24 hours and it was not changed. An incorrect A record for our site was put in place for maybe 30 minutes, and then corrected. Our off-site monitoring (third-party) sites picked up the change in DNS and kept the incorrect IP for almost TWO WEEKS until our correct IP finally got picked up again. They swore up and down that they ran plain vanilla BIND DNS, but I don't see any other explanation other than caching time. I did check all of our slaves, and they did receive the correction right away. I wish people would just follow the rules!
I get a flamebait for a response to a troll? Nice.
I run a DNS server for around 470 domains. I have this problem with our telco/dsl provider(Large Canadian Monopoly).
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.
I have a client who's mail servers I migrated to a Co-Lo facility. I changed the name server TTL way low about 2 weeks in advance.
The day I moved them (friday at 5:00) I pointed all the DNS records to the CO-Lo facility.
The next Wednesday the owner of a competing business (the business who serves my clients' peer company) accused me of changing the domain in the middle of the week. It seems that his Microsoft Exchange server had cached the OLD IP address and would not look up the new one.
I told his engineer to reboot their Exchange server - had a 20 minute argument with him about. He finally did and it re-looked up the DNS for the new server. Problem solved.
However the idiot owner of the other company still blamed it on me, said I was incompetent for doing the change in the middle of the week (friday?!?!?) and all that.
Grrrr...
= Grow a brain...
I serve web and mail for a whole bunch of domains off of two servers which are far apart and unrelated (geographically and in terms of network topology). Under normal conditions one is primary and the other secondary; the two of them sync up via cron and rsync at ten-minute intervals. The A records for web sites point to the primary, it has a higher-preference MX and so on. Both machines are authoritative DNS for all domains.
I have TTLs on all the domains set to 120 (yep, two minutes). The idea is that in case of failure of the primary, the secondary will reconfigure itself as primary and begin handling all traffic, while the end user will experience a maximum of two minutes downtime.
With 278 days uptime on the primary though and great service from the colo provider, I've never had to implement this scenario. Is my planning fundamentally flawed? Is this an unadvisable practice?
-ben
myselfmusic
When this happens, our own product throws away any records apart from A, CNAME and MX and puts them into a default record structure. The default structure has a 14 day TTL, however we felt sustaining the sanitized record was preferable to reproducing data that could be hazardous to DNS clients. Since many of our largest customers are ISPs, this protection is especially important.
That SBC, and Comcast are the worst. Comcast literally being the worst. Not only due to poorly updated DNS servers, but the proxy servers also pose a bit of a problem.
As an ISP that's also a host, I can't tell you how many times I'll have a customer call up. "We just moved our website to you, but we can't see it. What's going on?" 99 times out of a hundred they are on SBC/Yahoo DSL or Comcast cable. I've even had some of our webhost resellers argue this point with me. Facts are facts, if I can see the site using my DNS servers, the TLD is pointing to MY DNS servers, it's there and working. If that customer pings their URL and comes back with some other IP than mine, it's obviously going to the wrong location.
This is only one of the MANY reasons I tell customers to pay a little more for service from a smaller company that pays attention to detail and cares more about quality of service than how much money is going into their pocket.
There are plenty of smaller providers out there that ARE knowledgable, with help desks in the US, and aren't "technically challenged" that think they can do it because they can work on their own computers without breaking them (which is often not the case anyway).
My advice before bothering to do any of this crap. Show them your disgust and find a local company. It might cost you $10 more a month, and it might even be cheaper. If you're cable, I'm sure it WILL be cheaper. Not only will you get better service, things will just work right. When you have a problem you'll talk to someone who can actually FIX it instead of making you take 2 days walking through stuff on your computer knowing full well it's a network problem on their end.
Basically, stop being a cheapskate, then complaining about the level of service you're getting. You get what you pay for.
Just as a side note, since we're talking about DNS. Over where I work, we have a check with nagios that verifies if our DNS server is up by asking it to resolve www.google.com.
Everyday for about a minute or 2, google's dns server will return a SERVFAIL error. Another symptom is that the problem re-occurs every 24 hours and 2 minutes. So everyday the problem re-occurs with an increment of 2 minutes.
We also run the check with a few more host and only www.google.com gives us an error.
Can I use dig to find all the addresses for a domain?
i used to be able to do this with nslookup, but have forgotten how, and I hate having to login to my DNS server to figure out what addresses I have open.
Here's my experience with TTLs. (Keep in mind I am a relative newbie when it comes to DNS, I had bind working on Win32 for a couple years for about 300 domains and have since moved to cooperating with a local ISP to use their DNS on RH.)
There are five types of TTL problems;
1) the ISP is a large one (AOL, RR, Earthlink) etc. and they have deliberately ignored TTLs on A records or entire zones. Typically it's up to 4 days more than default but they do cycle eventually. Nothing to do but show a few web tools to those people complaining and tell em it's not my fault.
2) the ISP is a large one that just has crappy DNS servers (Charter Communications, other cable) Resolution as hopeless as above. The crappy part is that Charter in particular FILTERS traffic on port 53 so you CANT use any other DNS servers aside from theirs. Morons, unfilter or fix it.
3) the ISP is a small local with some high-school part timer admining their servers. In this case, the DNS server is usually just screwed up in other ways too. TTL and old cached inforamation is just part of it. Sometimes you can get their customers to biatch at them to reset the service. I have had to explain how and what to do several times to the OWNERs or CTO of these ISPs. (See newbie comment above)
4) there is a DNS server somewhere on a medium sized or small LAN and the LAN admin has no frecking clue it is there. Often this is a domain controller for Active Directory, but sometimes its something else. Often resolution is "well, wait until everbody leaves and reboot all your servers and machines"
5) Individual Windows machines that do not let go of DNS data (I dont think the DNS client service in Windows honors TTLs, I think it uses "window is still open so keep DNS" type rules instead.
Most often, I run into #4 and less so #2, but the number of large ISPs that dishonor TTLs (even reasonable ones) is growing.
There's a term for it. "being trolled"
Waaa.. Waaa.. somebody ignored my TTL.
Listen -- We are SOA for around 11,000 domains. Both myself and the other uber-admins get tickets like this "escalated" when some clueless newbie wet behind the ears freaking junior admin DOESN'T RTFM and doesn't realize that if the serial #'s don't change then TTL is ignored.
We interface with nearly every major ISP -- I assure you, their name servers are configured just fine --- It's yours that is broke.
For those of you who just aren't DNS afficiandos -- so how retarded is this? Well here is another story ideas for slashdot that is along the same lines:
OMG! Two major RG vendors (NetGear and Dlink) don't follow RFC798 (TCP). See when I block port 80 on my firewall, the web stops working -- Imagine the whole web stops working by blocking just one little port. This is a huge problem! It needs to be addressed!
How about this little doosey:
I've just uncovered a SCO/Microsoft conspiracy. They've apparently teamed up because after reinstalling Windows XP onto another partition XP disabled my Linux partition -- the boot menu doesn't come up anymore. Clearly Microsoft is doing this to help SCO protect their intellectual property! Quick tell Groklaw!!!!
If you don't get either of the two above -- I can't help you. (seriously -- WTF are you reading slashdot for??)
I swear
the OS/bind/djb/whatever zealots will simply see this as an argument for their particular religion
djbdns advocacy is definitely not a religion.
Each of the many reasons that djbdns is better than BIND are straightforward and easy for any intelligent, open-minded person to grasp. No blind belief is required.
What was the original TTL on the record? Let me guess, it was the default one? Let me also guess, you did not check to see just how the request went from the headend to the DNS server? Guess what? The servers were most likely doing exactly what they were supposed to do.
You created an original new record with a default TTL of say... 7 days?
You queried it form a location that relied on the caching server. That entered the record into the cache with the expiration of 7 days. Why, on earth, would you believe that changing a TTL now would have any effect? That record had been already cached! It wont be re-queried until the TTL expires, no matter how often you change your TTL on the original record. You also need to know how the DNS infrastructure is setup on your providers side.
Lets see.. what else?
Ah, savings on bandwidth. DNS bandwidth is very small ever for large networks. IP transit is currently priced at around or under $20K per 1Gbit/sec. If the DNS infrastructure is engineered correctly, even if the TTL is set to 60 seconds for a domain such as www.google.com the load on the DNS servers is not going to bring them to the crawl. Engineering the DNS infrastructure correctly does not mean buying a box from servermatrix and using C-Panel to activate DNS.
Now... the reason why TTLs should be low is to provide higher availability services. Of course, I encourage my competition to use very high TTL.
I've recently "disconnected" my .COM version of my home domain (solely using the .US version now). As I get -0- spam to the .US address' (so far :) it is very apparent that a LOT of DNS servers [world wide] simply ignore TTL. A couple of weeks before the "switch" I set the TTL very low (60 seconds) -- I can easily handle the DNS traffic across my DNS servers (peppered here and there :).
.COM domain as I set _everything_ to IP address 127.0.0.1 (just to screw with the spammers high-jacked computers). Yet the spam [attempts] still come in. Every minute.
I would expect, now almost two months later, to be getting -0- traffic to the
Technically -- even running your own DNS servers there is nothing you can do if you move/add/delete something and others out there decide not to honor it. Everybody loses.
Yeah you're right. I was just thinking that if you had millions of users you could put a lid on a lot of DNS traffic just by ignoring TTLs. Maybe rather than bandwidth, it would have been better for me to say it would ease the load on the DNS servers.
-R
How can I prevent Road Rnner from sending a DNS lookup to my machine about 1 time a minute?
My firewall log has hundreds if not thousands of them.
I used the Linux Advanced Routing & Traffic Control utilities to set up the split access stuff. This allowed me to send all packets from the old ISP back through their link, while packets from the new ISP went on the new link. I changed the DNS entries and then I monitored the traffic going through the old link. After one TTL period, almost all of my traffic was using the new link. The main exception was NTP clients, which run for a very long time and only do their DNS lookups on startup.
I run a (non-tech) website that is used by many people, and also a the authoratiatve name server for a domain that gets a couple million lookups per day from tens of thousands of caching name servers. If there were widespread problems, I think I would have noticed it.
I'm not saying that there aren't a lot of really broken name servers out there, just that they don't appear to be rampant.
SPF support for most open source mail servers can be found at libspf2.
- globally set by the server, period or
- globally set by the server to a sane random interval (to avoid overloading the root servers at predictable intervals)
In any event, is there any real necessary gain by having the record creator specify the TTL?...En að Besta Sem Guð Hefur Skapað Er Nýr Dagur
I handle DNS for a large government agency. We have a lot of remote offices who are connected by ISP instead of our WAN. In our case they would even stop resolving our whole domain. I have been handling these issues for over 2 years since I arrived here and often I was often blamed for these problems. I decided to get aggressive with ISPs and insist on being escalated to thier higher tiers. I began to uncover over a years time that many of theses ISPs had this problem. Large ISPs would often not tell me what the fix was but it would simply get resolved after a few hours. One very large ISP told me to set up my remote offices to use a different DNS server, the one we were using was not supposed to be used acccording to their engineer. For curiousity sake I checked back with the old DNS server a week later and it was still up and not resolving anything in our domain. I have had to walk a DNS admin at a small 'mom and pop' ISP on how to use nslookup correctly. "What's dig?" I have found that there are a lot of people out there running DNS who do not know what they are doing and/or do not care about how this affects their customers.
Yep -- we're seeing similar kinds of things. Recently, in preparation to migrating to some new servers we lowered our TTLs on the web server entries. Yesterday, we switched them over, and found that it wouldn't switch the traffic over within the TTL specs. Very frustrating to be sure, and we came to the same conclusion ... many (most?) Internet providers are ignoring DNS TTL.
Thanks,
Neil Ticktin
Publisher, MacTech Magazine
About 6 months ago we were switching a wireless application back end from one datacenter to another. I set several records to a very low TTL (15 minutes) about three months before -- just to be safe.
The application completely broke on one particular carrier -- it was still resolving to the old IP. Every other DNS server in the world picked it up but theirs.
It required a direct phone call to several network engineers to correct the problem. Given their clueless responses and complete misunderstanding of how DNS even works, I suspected it was a misconfiguration of their caches.
How did they fix it? They just rebooted the nameserver to clear the DNS cache! How crafty.
Oh how I can't wait to work with this carrier again!
I fully appreciate the value of naming, and I've even worn the hat of a DNS admin for many years. But I've never really understood why naming was so important that it became inconceivable to do without it.
An IP4 address is only two more digits than a phone number, but we work with phone numbers just fine. But if you try to make the case that we could work with IP numbers just like phone numbers, it's an insane suggestion.
So what we have is, instead of the idiom of an index from name to number, we've got the idiom where the name *is* the address. I've never been convinced that scheme has the value that it's believed to have, and even less so when most "domain names" end up being nothing more than a single ARecord for a website.
-fb Everything not expressly forbidden is now mandatory.
A huuuuuuuuuuuuuuuuuuuge number of sysadmins out there have no clue what so ever.
> DNS queries are figgin tiny...
They are round trips and over a modem line that's a pretty significant delay. Now consider that I visit the very same sites day after day and that their IP addresses almost never change. Running a caching nameserver speeded up browsing considerably, and if I could set it up to just keep the addresses until told otherwise, it would have been very nice indeed. Sadly, bind does not save its DNS cache anywhere and it was a major pet peeve with me, since I don't want to run my computer twenty four hours a day.
I was talking to the person who wrote the story.
It's not supposed to help grandma. It's removing the dns cache from the machine and putting all the dns events in the event viewer. Do that instead of rebooting.
I've been involved with a colocation facility move recently. Nearly all traffic to our old servers died out within 48 hours. After a week we shut down the old servers a week earlier than we had budgetted for. This doesn't seem like much of a problem to me.
I've always heard your tag line the other way 'round. That's a very nice zinger. I'll save that one for a special occasion.
______________________________________
There are 10 kinds of people,
Those who know binary and those who don't.
I recently moved all my domains to a new server, updating dns AND DNS servers in some cases. Road Runner totally screwed this process up for me. I don't host with them, but a lot of people that visit my websites use them as an ISP.
Over two weeks after dns had propogated succesfully elsewhere, roadrunner was still serving up old IP's. This affected about 5 of my sites adversely. Some of which had owners using RR, some had clients using RR. Basically a huge cluster@#*! And of course, RR techsupport had no idea what I was talking about, and couldn't direct me to someone that did.
Our additude at the time was well screw the AOL users, there's no one importing using AOL anyways
I'd be curious who's the audience for the site(s) you're talking about. I'm pretty uncomfortable calling tens of millions of users unimportant, especially when it comes to e-commerce. Different "additude", I guess. Or attitude, even.
I maintain an ancient AOL account specifically so I can see things the way that some of my customers' customers see them. But it has one other advantage: if I've just made DNS changes to domain I care about, I set up a temporary new A record (like X.whatever.com) and then surf to it through AOL's proxies. This seems to get their name servers to notice that the SOA record is new, and it flushes out the rest of their cache. This seems to work on all sorts of servers, most of the time.
Don't disappoint your bird dog. Go to the range.
Simple. Response time and bandwidth.
Caching provides a response much more quickly (albeit not always right), and for a large scale ISP, DNS lookups consume not-insignificant amounts of bandwidth. This used to cost much more than it does today, and I'll bet much of this continues out of intertia.
Here's a little tidbit that most people don't realize...
The Sun JVM implementation implements it's own DNS caching for any name resolution done by the networking APIs. By default the TTL for cached entries is... FOREVER. Not only that, but they will cache NEGATIVE LOOKUPS, so that if your resolution fails the first time it will fail forever.
The only solution is to restart your app (duh) or set the TTL as a system property on JVM startup.
I personally spent a few minutes staring at the monitor in shock when I first found this behavior by debugging a problem all the way down to the Java API source. Boggles the mind. Everyone else I've read who've 'discovered' this little known problem have had similar reactions.
This is unrelated to the TTL issue discussed in the article, but I try to take every opportunity possible to scream 'WTF Sun!?!?'
> 3) the operator could decide that "awhile" is
...stuff that in your ISC pipe and smoke it.
> an hour, and then the authoritative server for
> "google.com" would be buried in requests
servers at google spend most of their life burried under one type of request or another; what's so damned special about DNS?
> 4) Better to let the operator of the
> authoritative server tell the nearby servers
> how long "awhile" should be.
Uh, that's what i want... some yahoo out on the internet deciding how long it should take for me to effect a change on my infrastructure. That's routing into damage, not around it.
The point that everyone is missing is that client TCP state tables are completely divorced from DNS's distributed database parameter (TTL) that dictates how quickly infrastructure can be executed. This is a fundamental flaw in DNS and directly impacts trust relationships on the internet. Anyone who tells you differently either doesn't know what the fsck their talking about or is in love with the code the wrote.
The whole thing about the web is it's based on trust... it's amazing it works as well as it does... I can see providors not obeying TTL simply to keep their DNS servers from being stuffed (or whatever the word du jour is)... It's all about trust, and the lack of it nowadays on the web... get used to this sorta thing happening more and more.
What a trivial comment... and yet it's rated 5. The author has a habit of posting two and three line comments within the first 5 minutes after a topic appears, and many of them end up with ratings of 5. In this case, the comment was posted at 8:32 AM on a topic that appeared at 8:30.
Please, moderators, use your judgement more carefully. Don't give a 5 rating to these generic and nearly content-free postings. The web is based on trust... well, duh. That's not insightful or interesting! It's only because it was posted early that moderators gave it a boost, and then other moderators followed suit.
Let's save high level moderation for comments that actually offer some unexpected information or unusual insights, not ones that just restate platitudes that anyone could see are true.
you seem a little stressed. *grin*
The world according to SComps
You sure you tested it correctly? You did change serial numbers each time you changed your zone info? If you haven't, than DNS server you were testing detected that serial number hasn't changed, and did the right thing (continumed to use cached copy for next TTL period of time). The thing that remote DNS picked up the change eventually (after several weeks, or after you opened ticket with ISP) might be simply due to the fact they restarted DNS server (which would discard all cached entries).
If your test was performed correctly, than overriding TTL certanly breaks number of things. As most people already noted, experienced system admins will temporarely set TTL low for their domains in preparation for big changes (and raise it once the changes are done).
Another thing that will break is dynamic DNS. Dynamic DNS uses low TTL (sometimes as low as one minute, or even several seconds) since A records are pointing to IP addresses that change on daily (sometimes hourly, or even shorter) basis. Anybody using any form of dynamic DNS would be hit by this very hard.
Of course, it also opens a whole bunch of security related issues, for domains that are managed by dynamic DNS services, and/or users (big and small) with static IP addresses when they are switching providers (which usually includes new set of IP addresses being assigned).
First time I ran into this is when I was learning TCP/IP and DNS by setting up my own small business network. I kept experimenting with DNS files and setting a very small TTL so that I could make frequent changes. Almost drove me mad when I had the correct configuration on my side but the ISP had cached the wrong one. The least they could have done was inform their Support Department that this was something people might call about, all I heard was: "Everything is always right on our side."
Comment removed based on user account deletion
Treewalk - brilliant - foolproof (well almost)
run your own caching DNS server and bypass the problems of slow and incorrectly configured ISP's DNS servers!
http://www.ntcanuck.com/
HTH
If you know what nameserver their proxy uses, you can do this with nslookup and the 'server' command... No AOL account required.
I feel your pain -- I've done my share of idiot tech support questions that should never have been sent to me.
... but we have no clue how the outside world found out about the development DNS servers. (or why the hell they weren't firewalled off, but that's another story).
But I have seen once when we had changed the serial, we had lowered the TTL for the week preceeding, and yet there were DNS servers out there that just refused to update. (AOL being one of them).
After we hit two weeks, and the IP still hadn't propagated, I did some digging -- somehow, 4 of the root name servers were forwarding queries to two development DNS servers that someone had set up, which weren't being maintained and getting updates. So yes, it was not the fault of the remote DNS servers that weren't taking the updates
But it's not always just a matter of changing the serial.... other things can go wrong with DNS.
Build it, and they will come^Hplain.
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?
SPF support for most open source mail servers can be found at libspf2.
Comment removed based on user account deletion
So rather than bitching about how stupid everyone is, why not take the time to explain why it is done this way? Take 5 minutes out of your busy escalated-ticket day, and tell us why it works the way it does - at least make an effort, rather than complaining about how much better you are than the rest of the world.
I have seen such server two or three years ago. It was one of main Latvian nameservers. Its misbehaviour made serious damage to our business. Their admins ignored my complaints.
This winter, another very important nameserver was sure that our domain doesn't exist at all and ignored any changes (which is defined in SOA). 1/3 of Latvian users couldn't visit our site. I've called their admins five or six times! The server was fixed next morning. That day we lost some customers.
There should be a protocol by which a client that knows or strongly suspects it is being handed an obsolete IPADDR can request the DNS server to update its cache. In the case of a timeout or connection refusal at the old address, the request can be automatic with the DNS server responding only if the cached address is more than a few hours old and some number, say a hundered or so, such complaint/requests from different clients have been logged. Browsers and other clients might also have an application layer interface for manual requests as well.
While this might be a new avenue for DOS attacks on DNS servers, they are already open to DOS by ordinary lookup requests anyhow so how much difference could it make?
"Obtuse Anger is that which is greater than Right Anger" - Lewis Carroll
I now ran several times into the problem of sites which do not respond correctly (or at all) with fragmentation requests, see for example IP-Masq-HOWTO.
/. rant: :-)
Its a very similar problem and causes some websites/tcp connections to hang without any apparent reason. Why the hell can't they configure this properly? It is not like that an immediate DOS attack results from sending back fragmentation requests...
To start the typical
IMHO it is neccessary to have some kind of "RAW IP" consumer label which would guarantee that:
1. my or my peers packets are not blocked willingly (no port filtering etc.)
2. my packets are not traffic shaped, at least not in other ways than I specify by setting TOS fields. I'm not arguing about the possibility of different TOS due to different prices, but rather a telephone/ISP combination slowing down my VoIP traffic to the competition. General disparity in handling traffic should be marked as such, though!
3. DNS and all other provided 'additional' services (eMail accounts etc.) follow all RFCs and other standards (i.e. this TTL problem).
Of course, such a label could come in different forms (for example for people really wanting to have a firewall which blocks traffic for them).
But one needs to be informed to make the decision for the right ISP. The current situation is rather
intransparent and it steadily gets worse.
And websites deserve a similar label too. There are "HTML x/y compliant" stickers on some sites, but they are rare and this should be only the beginning.
I'm still not really sure about who would own these labels (if at all), though.
I have this same DNS issue as the author from time to time.
I have seen Microsoft DNS servers set the TTL to be a very long time. I am not sure of the exact amount. But months will pass and the Microsoft DNS server still have the old entrys.
While it is amazing that the Microsoft DNS server has been up for months in the first place, this is always something I have to deal with when I make DNS changes. I mention this because rebooting the server would flush the cache.
We have two remote location that use Microsoft DNS servers, and I have to flush their cache from time to time myself due to this issue.
I have yet to see it get resolved. (grin)
If you know what nameserver their proxy uses, you can do this with nslookup and the 'server' command... No AOL account required.
Right. The problem is, they have dozens of proxies, and who knows how many name servers - with pretty much no way to know where they are. So, it's easier just to tickle their system through their normal user interface. On other name servers, where I DO know the IP address, I've often done just what you say.
Don't disappoint your bird dog. Go to the range.
Okay first of all this guy doesn't really seem to have much depth of knowledge.
/flushdns? And For The Love Of God, DNS DOES NOT PROPAGATE. It's a referral system that caches.
Asking friends to REBOOT? Why not just ipconfig
I also have a really hard time taking someone seriously that, in the opening question, mentions something like "well, zealots will argue, and tin foil hats will bitch" or whatever. Yea, he's really unbiased..
TTL affects the time you should cache the records, at least he seems to get this. So, he can't think of one reason why a large ISP might want to ignore TTL's?
I'll name a couple and leave it to this guy to fill in the rest:
A) Because a lot of really terrible DNS admins set the value way too low and leave it there?
B) Because ISP's might have a need to keep their cache database activity to a resonable level?
GO on with your study! The results will probably prove to be very uninteresting.
- It's not the Macs I hate. It's Digg users. -
The TTL operates entirely around the serial number.
The DNS server that has cached the value knows three things - it has a cached value good until time X, with serial number 12345, and the record is Y.abc.com=Z.
When the TTL gets close (halfway, I believe is the standard), the caching server asks what the current serial nuber is. This is more efficient than asking per record, because per the spec, you can't change records without changing the serial number. No serial change, no change to recache.
I got sick of waiting for the DNS for a few domains I registered to propigate. I waited a month, and it still hadn't happened. I ended up setting up my own caching DNS server for here at home. This is definitely an issue that needs to be addressed. It really doesn't take hardly ANY traffic to refresh the cache, but if the TTL is modified to something more like an hour, it'd be allright.
In fact, servers that are obeying TTL won't see the new record until the old record's TTL expires.
The querent doesn't say whether or not there was any wait for the old TTL to expire. They don't even mention what the old TTL was!
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
I work at a hugeISP and we sometimes receive tickets accusing us of ignoring TTLs. However, it has always boiled down to one of three things.
1. Change in the hosting of a domain to new DNS servers without properly removing the domain from the old hosting DNS servers.
When this happens, a DNS server caching a domain's info will continue to check the old servers until the old server stops answering.
2. A change in the TTL of a domain to a lesser value.
If you change the TTL of a domain from 7 days to 1 hour, DNS servers currently caching that domain's information will hold onto it for 7 days before discovering the new TTL.
3. A bug in BIND 8 that prevents it from pulling updated information from the primary DNS server for a domain.
We see this rarely, but it requires a restart of an affected DNS server. We have not diagnosed the specific cause yet since we're moving servers to BIND 9.
We are in the process of changing ISP's at my company. They have had a website for about 5 years but didn't use the domain for email.
About 2 years ago they set up a mail server in house for the first time and everything has been fine. In planning the switch I set up a new A record for the mail server with the ip address from the new ISP.
Because I am still in the evaluation phase, I set up the MX records for both systems and would play with priority when needed for testing.
The old mail server address pointed to mail.*****.com and the new address points to smtp.****.com. Should be pretty straight forward. All of a sudden, one of our sales people can't forward email to work anymore from his home account. That ISP (which hosts our web site) long ago added smtp.*****.com as an A record on their DNS server. Since they never hosted email service for this company, I am baffled by it. But it explains why there have been a handful of customers in the area who could never email us.
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.
Personally speaking, I've never had a problem with my DNS servers being ignored. Then again, I took the time to educate myself on how DNS actually works. I got the O'Reilly book 'BIND', read the faqs on djbdns, played with MS dns until I got sick (so, like under 5 minutes with that one), and set up some real world, hard working name servers. I ran into many problems along the - I couldn't see the DNS changes outside of my network, they weren't updating correctly, etc...
So you know what did about? I fixed my damn mistakes, and the shinizzle started to work just fine. Yeah, that's right. I made some mistakes setting things up for the first time. I can admit it, I'm a big man (and I was young and needed the money).
Anyway, my point is this - It doesn't matter what DNS server you use (as long as it's not MS DNS), or what your religion is - If you read the documentation, and I mean read it, don't just skim over it and say "Uh huh.. oh that's interesting, I knew that.. ble. This book was written by a monkey, I don't need to make my crap work right", and you set up (initially at least) per the documentation - THEN IT WILL WORK.
Update your serials, most cach's just check the SOA - this is quicker and less costly than pulling the record down. If the serials match, then no change was made. You can even use a tool for administration (Webmin? not my thing, but you know...) that does this for you. PUT THE DAMN DOTS AFTER THE RECORDS.. this is the biggest problem newbs seen to have with dns. Yes, it's a period, just like ending a sentence. Oh, thats right, you learned l337 sp34k in skool. Yeah, you're useless (not you per se, but a generalization of the 90's generation).
Check out www.dns.net, it's a great resource, really.
Most importantly, make sure your stuff works before you complain about how the world doesn't like you. If you don't, it's incompetence, and I've fired people for less.
Sorry for the harsh tone of the message, but I'm a bitter sysadmin with the HIPAA dedline tomorrow and fresh-out-of-college grad that needs to be trained, and I had to vent somewhere... I mean, I'm saving that "Another insane UNIX sysadmin killed is co-workers" headline for another Slashdot day...
http://www.accelerateglobalwarming.com
Is there a valid technical reason to ignore TTL?
Yes, there is. Both law enforcement and spook surveillance beaurocracies are rather slow with internal processing and more dynamic DNS changes would undermine most of their investigations.
There you are, staring at me again.
We run djbdns on all our caches, pretty much an out-of the box config, except boosting the cache by quite a bit. Our zones have a 2 hour TTL, as well as for customers. Never heard of any problems, also, the only time we've been compromised was via bind, which I haven't had to worry about for four years now, during which time there has not been any vulnerabilities found in djbdns.
A similar preliminary study on this topic was presented at last year's Internet Measurement Conference:
On the Responsiveness of DNS based Network Control
They used access logs from Akamai's servers and some webservers at IBM to show that quite a few caching DNS servers don't respect TTLs, sometimes by days or more. In particular, the paper argues that because of this problem, DNS can't be relied on for things like Akamai's load balancing, since it requires using TTLs of only 10s of seconds (IIRC, Akamai DNS TTL's are about 20 seconds).
The study had a fairly large coverage of caching DNS servers (several 100k). Though it would be interesting to reproduce the results.
Good timing.
http://www.justworksnh.com
Sadly, 'the web' appears to be slowly mutating into 'the internet'. I've seen it on technical documents and even the somewhat mocking 'interweb' used.
It's like DMZ or hacker. Not worth fighting, since I'm sure that 90% of the people who use the term automatically include mail and other applications in that term.
(Hey. Mail is web, right? Just look at Yahoo!, Hotmail or even Outlook Web Access!)
I read this and thought...
If you changed your DNS from something larger to 24 hours, you would have to wait the larger number before begining your tests... The reason being is that your DNS servers do not magically go out and tell the ISP DNS servers "Hey you, I updated my TTL, so please update yours".
Basically, if the value you changed from was originally 7 days, it would make sense that the other DNS servers where incorrect a week later.
Maybe I read that wrong, but that was my take.
...for my grandmother. Or the vast majority of people for that matter. I'm sure its simply to reduce the load on provider's nameservers (not justifying, just explaining). The fewer times they have to update a record the better (for them, insofar as bandwidth and processing power is concerned).
Yes, I run my own DNS at home, luckily, I also run the DNS for my company. So I can at least guarantee we aren't handing out absurdly stale responses.
It really is a sad state of affairs. How much would another nameserver cost to distribute the load? A few thousand bucks? Pathetic, absolutely pathetic.
I'm not sure it's related to a TTL issue, but the (appallingly slow and unreliable) DNS from my ISP (BT OpenWoe - no, not my choice!) b0rked on pretty much every highly Akamai-sed site I know about.
.com would). Image servers for yahoo, IMDB and a boatload of others were nowhere to be seen. Miscellaneous other sites would slow to a crawl as my router struggled to resolve fifteen different ad servers.
:)
Google.co.uk wouldn't resolve (although
I set up Bind a week ago just for a laugh, and haven't had a single problem ever since. Can someone more fluent in the wherefores of DNS explain if this has anything to do with the TTL issue? I thought it might be that the IP addresses for the servers in question changed frequently and that British Telecom's notoriously bad DNS wasn't catching up fast enough, but if anyone has a better explanantion I'd love to hear it
Moderation Total: -1 Troll, +3 Goat
There are just too many people out there in charge of DNS boxes that don't know what they are doing. A few years ago I was one of those people. Then I discovered dnsstuff.com. After that I decided it might be a good idea for me to read up on BIND. DNS is a complex system and if you aren't a CLI jockey, thances are that yours is misconfigured.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
We, too, have noticed these problems, and more. Both Comcast and Verizon DSL have consistent problems with their DNS servers. It has not only become extremely frustrating for us here at DynDNS who use those ISPs at home, but we've also received numerous queries from our customers asking if there is anything that can be done to solve the problem.
0 5/ 04/587.html
To that end, we are now offering a recursive DNS service for customers who wish to ditch their ISPs unreliable servers and sign up for a DNS service that actually works.
DNS is what we do and we're dedicated to providing the best service possible.
Check here for more details:
http://www.dyndns.org/news/releases/archives/20
This was like 6-7 years ago for a small telecom company. My spelling still sucks but, my attitude is less snobbish to the AOLers now that I'm older, wiser and have better understand how business works. Most of our audience was larger telecom companies that likely had their own internet connections. It sounds like AOL has gotten better (I'm surprised). I believe we tried that trick back then with less successful results.
For British Telecom 'lost'/or had stolen there reverse dns servers that where refered to by ripe.net
The thing was apperently on 217.32.105.90 whether it is still down is something I gave up caring about.
Send Peter Clifford Francis Macrae comdoms to 23 Bedford St, St.Neots, PE19 1AX, England
Sounds like the submitter forgot to increment his serial number before reloading the zone.
Messing with TTL can render DNS RBLs completely useless. When an IP is blacklisted we want the shortest possible notice. I don't care about a blacklisted IP after 7 days.
TTL is a major issue when it comes to DNS Failover, a very low-cost solution for server uptime. Today, service providers will charge around $100 per month on fail-over (and load balancing, which is not required by everyone). If DNS servers would refresh on a timely manner, failover would just be a matter of having more than one server online, a good monitoring service (which you need, anyways) and a dns-entry switch to the backup server. Sadly, since TTL is ignored, our company now is forced to spend an additional $100 per month for this extra .01% of uptime. Such is life.
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.
Wow .. Okay for the record -- I didn't mean to start a troll war. Arrgh.. trolls. Hate trolls.
.. first off I was up late last night hacking a Third Party TAPI service provider that integrates as a SIP Proxy (hobby), and then I got abruptly woken up because our VOIP carrier decided to magically change our rates and disable our account because they blew through our prepaid balance. (Arrgh!) .. bad morning. To the individual who pointed out I was angry -- bonus points.
.. I apologize to all who had to read this .. I broke the first rule of Slashdot.. Don't read slashdot angry -- because slashdot posts will do little to calm your nerves.
I apologize
In my sleep deprived state -- I *incorrectly* expressed what I was trying to say, or if you go back and re-read it, I misconstrued that perhaps the serial # has something to do with TTL. FOR THE RECORD: TTL AND SERIAL # ARE NOT RELATED. That isn't what I meant (you all should know that?!?!?), what I meant was that if you don't bump the TTL then your own nameserver if you do a SIGHUP won't show the changes and you can set the TTL to whatever you want and it won't do a bit of good. Classic newbie mistake.
Also while we're on the subject of TTL's I that our nameserver is actually setup to increase TTL's less than 24 hours to 24 hours.
I believe thats in an RFC or best practices guide I read somewhere. I do know that TTL is a recommendation, thats all. It should be set to a sane and reasonable number, and so if you don't set it to something I consider SANE and REASONABLE, I will do it for you.
As far as the astute individual who pointed out that ridiculously low TTL's are necessary for things like MX record cut overs -- yeah, well little grasshopper -- please stop lecturing me and go get me my coffee.
See with MX records, if the primary isn't reachable, it's possible to have a secondary. And you probably ought to think about leaving the first box there, setup to forward mail to the NEW BOX --- since (call it a hunch) there's at least one piece of mail that is going to be sent by a screwed up mailserver.
Heck.. i'm just happy when they attempt to send mail to my MX record instead of my A record (Thanks Micro$oft!)
Anyway
Hmm.. or is the first rule of slashdot - don't talk about slashdot?
Comment removed based on user account deletion
Its certainly something that happens a bit around this country (UK) with certain ISPs. Had problems due to it myself when updating domains. I also remember having fun in my planetarion days, when we did DNS updates, some places around the world had to acces the game or portal etc via IP for weeks after changes were made. Annoying yes, pointless... probably. Not like DNS traffic is large or anything. Suppose its down to saving every little bite of traffic though as bandwidth costs.
Tim (http://tim.igoe.me.uk)
Computers are like Air-con, open windows and they stop working!
Has anyone ran into this issue of TTL's trying to implement GSLB? I work for a company that is planning to go active active across two geo locations using GSLB. The ttl is going to very low probly in the 60 second range. I've been trying to get some numbers from venders F5. Foundry, etc. on how many people will get left behind in a failover scenerio, but nobody seems to have a real awnser.
I will ask you the same thing I asked the grandparent:
Can you point me to anywhere in RFC1034/RFC1035/RFC2308/etc that says that the SOA record has anything to do with the TTL?
I have read most of the DNS RFCs, and the important ones very closely. I have looked carefully at DNS packets and I am working on a proposed RFC that will create a new DNS record type (for SPF).
I don't know everything about DNS, so I'm always willing to learn more, but if you can't back up what you say with references to RFCs, I'm not going to believe you. Especially when you claim such bizarre things like a caching name server will know the serial number for all domain names that it has cached.
SPF support for most open source mail servers can be found at libspf2.
I hate to bear bad news, but there's nothing new here. Back in the 90s I observed similar situations--that no matter what the TTL, and even if you were careful to increment your version IDs, there were plenty of DNS servers that wouldn't notice DNS changes for weeks.
Hence whenever someone tells me that they're going to move their web hosting, I always advise them to allow for a couple of weeks of overlap, so that they don't lose a ton of traffic. Often they ignore my advice, because of course they have set their TTL low so their changes will take effect immediately, or so they think.
And then they wonder why they're getting hundreds of e-mails from people telling them that the site is down. And I forward them a copy of the e-mail I sent them beforehand warning them of the problem.
My gut feeling is that screaming about other people's DNS servers refusing to observe your TTLs is going to get you about as far as screaming about other people's SMTP servers refusing to deliver your spam. It's their server, they can do what they like. For instance, any TTL under 24 hours will be ignored by my caching DNS server. (RFCs say TTLs should be at least a day, more like 1-2 weeks.)
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
-1, biter.
At the ISP I work for, we recently changed the TTLs from about a day to an hour or so. Works out well.
If we make a change and someone calls up because they haven't seen it yet (even within the hour), I'll just tell them to call their ISP.
If your ISP does odd things with the TTLs, that's their choice... but what ISP you use is your choice. It's probably something normal like caching servers. If you don't like XYZ about your ISP, then go to another that doesn't do XYZ. Simple.
FLR
no problem...
what I meant was that if you don't bump the TTL then your own nameserver if you do a SIGHUP won't show the changes and you can set the TTL to whatever you want and it won't do a bit of good. Classic newbie mistake.
I'm pretty sure you meant to say that if you don't bump the serial number, not the TTL.
Also while we're on the subject of TTL's I that our nameserver is actually setup to increase TTL's less than 24 hours to 24 hours. I believe thats in an RFC or best practices guide I read somewhere.
Yes, RFC1033 and RFC1912 recommend a minimum TTL of one day, but that is just a recommendation. There are times when shorter TTLs are very important, for example many anti-spam DNSBLs have very short TTLs so that machines can be delisted quickly.
I can understand having minimum and maximum TTL values for caching purposes, but I think 1 hour is probably far more appropriate than 1 day. The bandwidth savings for a 1 day minimum isn't going to be very much but the problems caused could be fairly large.
SPF support for most open source mail servers can be found at libspf2.
First off, I can't believe this got modded a 2.
/etc/hosts (yes, its \windows\system32\drivers\etc\hosts for you windoze dweebs) for each and every single site you visit? Nope, don't think so. additionally,, sites change IP addresses from time to time. We just did it, (took about a month and a half to stop getting calls about can't hit the site from people who's dns servers ignored ttl) so when sites change, you can't get to them until you edit your file again with the new IP address, which you can't get to anyway without removing it from your hosts file, looking up the new IP address, and adding it again.
Now for the reasons.
Reason 1... how many sites do you visit a day? Do you want to put an entry in
Just three more hours seapeople and you can finally take me away from this crappy God Damned planet full of hippies
One thing to keep in mind is that a lot of caches will increase the minimul TTL in order to minimize traffic and load on a DNS server. Another thing to keep in mind is that some broken DNS setups with have a TTL under five minutes long, which will just break DNS caches in certain setups [1].
Another issue is that chains DNS server that don't implement TTL aging (reducing the visible TTL for a record as the record's expiration approaches) will cause the TLL record to be artificially long.
I notice a lot of people complaining about this; yet I see no offers to give their ISPs more computers to allow for more processing of DNS traffic, nor do I see offers from people to pay more for their ISP so their ISP can buy more DNS servers.
Really, if a minimum TTL makes you upset, run a recursive DNS server on your own computer and make the minimul TTL something short like five minutes.
Dynamic DNS and other means of using an ISP account not meant to be used for running servers to run servers is something that the design of DNS never originally accounted for.
[1] Think question "example.com 0 A" answer "example.com 0 CNAME example.net"; since we can't cache the CNAME, we can't answer the question, barring a setup that makes writing a recursive DNS server much harder.
Let us know when you find a way to make that happen.
"Obtuse Anger is that which is greater than Right Anger" - Lewis Carroll
If you were resetting the computers to flush the dns entries in the local cache, there is an easier way...
/flushdns
ipconfig
Yes, RFC1033 and RFC1912 recommend a minimum TTL of one day,
NO, they do NOT, RFC 1033 specifically states:
Then, if you know some data will be changing in the near future, set the TTL for that RR down to a lower value (an hour to a day) until the change takes place,
It couldn't be much more clear, if you need the TTL to be low you should be able to rely on it being observed specifically so that your changes can be properly propogated.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
To the best of my knowledge, all of the information you provided is BS.
Actually, he is correct. That is the behavior exhibited by most dns servers.
Can you point me to anywhere in RFC1034/RFC1035/RFC2308/etc that says that the SOA record has anything to do with the TTL?
I can't because it's not there. I can however point to where it says the Serial # in the SOA needs to be changed for every record update in a zone. The fact that DNS cache's rely on the SOA serial changing to determine whether to expire old records or honor the TTL does not go against the RFC, but it's not explicity stated.
I have read most of the DNS RFCs, and the important ones very closely. I have looked carefully at DNS packets and I am working on a proposed RFC that will create a new DNS record type (for SPF).
Might be a good idea to look at the DNS servers from an administrative point of view. There's a lot you don't get from just reading RFC's and looking at packets.
Can I get an eye poke?
Dog House Forum
Follow the money, do bears shit in the forests, is the new pope catholic, etc.
Lowering the TTL to twenty four hours, and making changes and then checking to see when a change was picked up.
To my knowledge, downstream caching nameservers will not check for changes in TTL before the latest cached TTL expires. Consequently, if the TTL is set to one year, then changed to 24h, the changed TTL will go on unnoticed for up to a year.
So I would like to know if the OP did allow the old TTL to expire after changing it, before he carried out the test. If not, the results of the test may be misleading.
On the plus side, I've used AOL to find out what the IP of names *used* to be while researching problems. Kind of handy that way.
< AFDB > /AFDB >
to screw up dyndns and force people to pay extra for static IP addresses.
<
More likely it's a case of "I know better than you".
Too many people set TTL's that are too low ("I know better than the guy who wrote the recomendations"), arguably dyndns among them (DNS was never meant to be _that_ dynamic (OTOH a lot of stuff is doing what it was never meant to do))
ISP admins ("I know better than the guy who set his TTL so low") override the TTL
As usual, the only loosers are those actally following the rules; admins who set short TTL's in preparation for moving stuff.
We built a new web server, but kept the one at the old IP address sending redirects to the new server. Redirects were by IP, not by name, so it was all good.
A month later I remembered the old web server, and went to go take it down. I decided to check the access log first, just in case, and it turns out that it was *still* being hit. A couple of hundred times a day, in fact. It took nearly two months for all traffic to drop off.
Lesson? Don't ever lose an IP address.
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.
"Ein Volk, ein Reich, ein Führer." -Adolf Hitler
"We are one Nation, we are one People." -The One 'leader'
One advantage of looking at the packets and the source to things like bind, is that you will discover that (*except in a few cases like NXDOMAIN) the SOA record is not sent with the answer. Therefore, no matter what you might believe, it is impossible for most DNS caching software to depend on the SOA values.
Feel free to show me where in bind/djbdns/etc. that this SOA cache dependancy happens, or to show an actual test case. I would love to see it. Maybe there are DNS servers that do an extra query for the SOA record, but I kind of doubt it.
SPF support for most open source mail servers can be found at libspf2.
This isn't just a problem for end users. It's also a problem on the support end. I worked as a Tier 2 support tech for a broadband company and I seemed to be the only one there that understood there was a problem with the DNS servers. I would constantly get calls that had been passed back and forth through customer service, tier 2 and to the ISP's network support then back down the chain. A simple ipconfig
The cable ISP I subscribe to has the problem also. They don't have their own DNS servers. They use a DNS subscription service which is to many hops away for my liking. I was having to clear my DNS cache several times a day and then I decided to traceroute to see who the ISP's provider was. I grabbed their DNS address, hard coded it into my router and the problem was solved along with having faster DNS lookup. - Andrea -
*It's not what you can do for the Dark Side but what the Dark Side can do for you!*
There is one thing to do.
Runs newspaper articles (online or in the print media) telling how AOL either hired techies not worth even an indian salary, or how they are trying to destroy the Internet.
The serial number needs to be updated so that bind will pick up the new zone, and so that secondary servers replicating from it will also see the change.
It's got nothing at all to do with 3rd party servers on the net caching responses.
GP admitted to n00bness WRT DNS. No point taking a 'tude about it, 'cos that's just n00bsniping.
Putting IPs into a hosts file isn't always a bad idea. If your DNS server is unreliable, and you MUST MUST MUST get through, this would work. (So would adding more reliable DNS servers to your search order, of course.) The downside is that it will work poorly in the case of multi-home (DNS round-robin) sites, or dynamically-IP'd ones.
Besides, the actual article is about how DNS is often no better than putting static IP addresses into your static hosts file. You did RTFA, didn't you?
Welcome to the Panopticon. Used to be a prison, now it's your home.
You see, the Internet is no longer a bunch of DARPA nerds playing with ftp and gopher. It's an important part of people's lives, often as important as the telephone. (More important for a considerable number of people.) I will only become more important. Capriciously blocking chunks of the network to save a few dimes on bandwidth and DNS server RAM is simply unacceptable. Seriously: the average mail transaction is thousands of bytes, the average web transaction is tens of kilobytes, and the average DNS transaction is under two hundred bytes. The bandwidth is negligible, and gigabytes of cache RAM are utterly cheap these days.
It's pretty easy to tell the professional internet companies from the ones run in someone's closet by digging around in their name server records for a while. Check out the ones for hotmail sometime -- now THERE's a solid setup. I'm pretty sure it indicates that Microsoft is holding some UNIX guys hostage in some basement somewhere, so we might want to think about taking up arms to liberate the guys...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
2 weeks seems to be way too long to be keeping DNS records. In my experience, if an old IP is sticking around for that long, I'd re-examine your DNS setup. Often people try to do strange things with 4 different DNS servers and one of them somewhere still has an old DNS server ip which has an old A recrod somewhere.
Im willing to bet 2 weeks after every DNS server updates to the new IP, hes going to see the old IP pop back up again and have to figure it out.
Bzzzt. TTL is absolute maximum. Serial numbers change or not, when you've reached TTL, you go to the authoritative interface.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
"slashdot these days"...
Have to look a fair way up the page to find a number higher than 782948...
> servers at google spend most of their life burried under
... and it is also when caching pays off... for YOU. Remember... DNS is distributed... the client isn't the only node that benefits from caching.
...stuff that in your ISC
> one type of request or another; what's so damned special
> about DNS?
This is a fascinating example of "I can't make up my mind what I want".... here you seem to be arguing that we might as well not have any caching at all (since it isn't special), but below you complain about "yahoos" deciding how often you
should refresh your cache.
> Uh, that's what i want... some yahoo out on the internet
> deciding how long it should take for me to effect a change
> on my infrastructure. That's routing into damage, not around it.
> The point that everyone is missing
I wish your explanation were more clear, then...
> is that client TCP state tables are completely divorced from
> DNS's distributed database parameter (TTL) that dictates how
> quickly infrastructure can be executed.
prior to a connection, the TCP state tables are undefined. That is precisely when you need DNS data (you have to specify a destination IP address, Holmes!)
> This is a fundamental flaw in DNS and directly impacts
> trust relationships on the internet.
Let me get this straight... you could not cache at all, or you could gain some benefit (faster dns response, lower bandwidth use) and still keep your users happy, yet you think it is better to put your ego in the picture and tell your users
how often they need to learn of changes? Static IP addresses are getting scarce, bub... and your users are going to want to keep up with the dynamic ones.
> Anyone who tells you
> differently either doesn't know what the fsck their talking about
> or is in love with the code the wrote.
> pipe and smoke it.
Chill, man... one minute you're tryin' to argue coherently, and the next you're usin' fightin' words.
Attention Slashdot user gru3hunt3r, if that is your real name. You are guilty of:
* Referring to yourself as an "uber-admin";
* Complaining about people who never once blamed you for high TTLs by name;
* Insisting that those who know enough to know what a TTL is are merely "wet behind the ears freaking junior admins";
* Making up two completely unrelated and inapplicable analogies;
* Using "l3375p33k" in your nickname;
* Butchering well-known English spelling, capitalization, grammar, and punctuation rules; and
* Being an all-around dufus.
That is all. Return now to the games section. Moderation will be swift and painless. (For us.)
I think that they are likely ignoring ttl as a very poor hack to get around cache poisoning attacks. If you ignore the ttl, records basically last for an infinite time, and can't be poisoned.
Makes it very hard to change them though!
> you complain about "yahoos" deciding how often
> you should refresh your cache.
No, actually I think he was arguing that DNS admins else where should respect his decisions about how long to cache lookups for his address/name space... even if they do feel a miniute increase in bandwidth utilization. Maybe DNS admins (or the folks who write the bind code) should set up a decaying/backed-off TTL parameter linked to the number of queries rather than setting some simple minded constant parameter.
> prior to a connection, the TCP state tables are
> undefined.
Not if you get a stale response to your initial DNS query. If you do, then the problem will be passed on to the resulting network connections that are attempted by the application to that old address. Usually stale information will result in incomplete connections (timeouts, re-sends, etc.). Of course, there could be a new web (or whatever) server at the old IP address (as you point out address space is a finite resource), then you have to look at the delivered web content to figure out what's going on... nobody want to attempt to solve that problem, nor should they.
The smart admin will keep both servers up when transitioning and provide redirect at the old end to the new end. Like a friend of my said about girlfriends and apartments: You don't move your shit on to the street and then go apartment hunting. Then again, that's an ideal that rarely happens. How many folks have had to switch providers due to unsatisfactory performance or expiring domains or a need for more bandwidth that they're current provider can deliver, etc.? More than a few, I bet.
Remember that the article author's actual observation was that old DNS records were being given out. He did not use tools like dig to verify that servers were ignoring the TTL; it was merely a hypothesis. He seems rather ignorant of DNS. He did things like suggesting to people that they reboot to see DNS changes and report back to him, rather than (A) checking himself (B) issuing a command to flush their local cache (C) asking them to hardcode working DNS servers, if the ISP's servers really are broken.
I'd guess that (at least) one of these two things happened:
Neither of these support the hypothesis, but they do explain the observed data.
web records are being looked up by an http client running on an arbitrary user machine. So they'll normally hit the popular and overloaded ISP DNS servers.
MX records are being looked up by a mail SERVER. Such server is much more likely to do it's own root lookups or otherwise use a superior system, because it doesn't have to accept DNS lookups from 3 million possibly hacked DSL machines.
The mail servers are run by the ISPs. Who would screw with the TTL for THEIR OWN lookups? That'd be kindof silly.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
I assure you, their name servers are configured just fine --- It's yours that is broke.
Prove it!
Since you won't be able to... take it down a few hundred notches.
That isn't what I meant (you all should know that?!?!?), what I meant was that if you don't bump the TTL then your own nameserver if you do a SIGHUP won't show the changes and you can set the TTL to whatever you want and it won't do a bit of good.
I don't know why you assume everyone should know what you meant. The rest of your hateful post made you look uninformed so folks probably generally presumed you were just a newbie admin with an inflated ego.
And why would they bump the TTL on their nameserver, anyway? Could you possibly mean that they should bump the serial number? I think you keep confusing record caching with zone transfers to secondary servers.
Also while we're on the subject of TTL's I that our nameserver is actually setup to increase TTL's less than 24 hours to 24 hours. I believe thats in an RFC or best practices guide I read somewhere.
I presume you know nothing about global load balancing. Global load balancers, which are really just fancy DNS servers, work by varying the A records returned from queries. The GLBs monitor the servers (or more likely load balancer farms) and if one goes down the GLB will no longer resolve to that IP address. For that to work, the TTL must be set to a very short time. If an ISP ignores the TTL, it will cause problems for any of their customers who access the domain with the short TTLs. Many large sites with multiple data centers make use of GLBs to balance traffic accross their data centers. You should not ignore TTLs or you may find that folks who rely on your DNS servers will occasionally be unable to access various sites. Since GLBs also tend to direct traffic toward less busy data centers, you will find that ignoring TTLs will also result in slower access for your clients to their favorite web sites. And if that's in a best practices guide, you might consider throwing that guide away.
I do know that TTL is a recommendation, thats all.
And I suppose stopping when the guard rail drops at a train track is technically just a recommendation, too. People have good reasons for lowering TTLs even if you don't seem to think so. Ignoring them can cause real problems.
I don't know why you need to interject the condescending, hateful speech in your posts. I would have blown it off with your apology, but then you included that unnecessary "you all should know that?!?!?)" crack in your latest post. You act like a genius and then make mistake after mistake in your technical statements, making you look like a buffoon. Why don't you relax and humble yourself a bit. Your ego is too inflated.
Send/track messages to 100K people: www.xPressAlert.com
> > you complain about "yahoos" deciding how often
> > you should refresh your cache.
>
> No, actually I think he was arguing that DNS admins else where should
> respect his decisions about how long to cache lookups for his
> address/name space... even if they do feel a miniute increase in bandwidth
> utilization.
If that is the case, he mis-read my original comments (which I still think clearly described authoritative servers telling "nearby" caching servers how long to cache), and I interpreted his use of the term "infrastructure" to mean his caching server. However, since he later attacked the existing DNS design, I don't think we misunderstood each other... we just disagreed.
> Maybe DNS admins (or the folks who write the bind code)
> should set up a decaying/backed-off TTL parameter linked
> to the number of queries rather than setting some simple
> minded constant parameter.
Unlike congestion relief, I don't think DNS name changes are affected by traffic... they are more of a characteristic of the way IP addresses for the server are handled.
> > prior to a connection, the TCP state tables are
> > undefined.
>
> Not if you get a stale response to your initial DNS query. If you do,
> then the problem will be passed on to the resulting network connections
> that are attempted by the application to that old address.
My point is that your initial DNS query is a totally separate network interaction than the one associated with opening the connection to the target you REALLY wanted.
The previous poster tried to argue that this is a broken design, but from the network interaction perspective merging the DNS lookup and target connection state table initialization would look identical... that is, a separate DNS packet exchange of some sort would have to have been completed if the local cache was stale before the target packets could be sent, so why bother merging the two?
From what I've seen, BIND's recursion stuff has been broken for a very, very long time. It doesn't seem to obey record TTLs for cached records. Unfortunately I haven't dug into the reasons why; however, if I use a different recursor I don't see the problems I do using BIND. I've been told I'm nuts, but I'll stick with alternative nameservers from here on out.
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Some spammers have enough brain left to filter aginst "127.0.0.1" or even "127.0.0". Remember, loopback is 127.0.0.0/8 - and be creative...
The load won't rise by having them wait for other DNS servers to answer. And more users = more effective cache - one user might hit www.google.com 10 times per day (more for geeks), where as a thousand users might hit www.google.com 10000 times per day.
> My point is that your initial DNS query is a
> totally separate network interaction than the
> one associated with opening the connection to
> the target you REALLY wanted.
Hence the trust issue. DNS should, above all else, return the host that you intend to connect to. Not the one that your DNS thinks I want to connect to. Cache posioning, either intentially or as an unindented side-effect of some esoteric, sub-optimal, unnecessary bind configuration, will always lead to a crisis in trust. Applications inherently "trust" DNS, even when the trust is unwarranted... and that's what ignoring people's TTLs does... it undermines the trust applications usually assume.
Of course, this is why things like secure DNS were invented, but how many people are ready and willing to switch to that monster and when will the client level support begin to appear?
In the mean time, clueless ISPs can continue to subvert the DNS-application trust relationship all they want. I personally don't care, since the market tends to self-correct for ignorance and malfeasance. I worry about two things:
1 - the window of exposure is so slight that the market won't adjust as it should.
2 - some cleaver, dishonest person will realize that a well leveraged trust gap would greatly assist his phishing expedition.
On point number two: think about what would happen to an ISP were it to be sued in civil court by, say, a bank because it didn't respect their TTLs and the bank's cutomers were hurt because of that. So, go ahead big ISP, ingore away! Your day (in court) may indeed come sooner that you think.
if they don't change the serial number, their secondary name servers will take a long time to expire (could be weeks)
No, actually. If they don't change (increase) the serial, their secondary name servers will never update. Not "weeks" - never. Because they check the SOA for the serialnumber, and it hasn't updated, so they don't AXFR.
Hmmm...
I'm thinking mid 20's...
First job after McD's or the help desk...
Some college, no degree, "Smarter then everyone else"...(ITT?)
Writes perl scripts...badly...
Thinks the "king of the world" guy from the movie "GoldenEye" is cool...
Has at least 1 t-shirt from thinkgeek...(Probably "Got Root?")
Bad haircut...
Will probably get fired when his boss finds out what he did to the DNS server.
Dan
1. the relationships between TTLs and DNS record update frequencies for different kinds of domains and different kinds of records;
2. the relationships between TTLs and freshness of cached records.
More than 15000 domain names and around 9000 DNS caches were examed in the first set and second set of experiments. Our experiments confirmed your concern in the effectiveness of TTL-based solution. Based on the measurements, we further proposed a new protocol DNSCUP (DNS Cache Update Protocol) to address this issue.
You can find more information at: http://www.cs.wm.edu/~xinchen/DNScup.html
Does that properly belong to Ed Howd? And are you him?
I prefer the "u" in honour as it seems to be missing these days.