Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet Bug

Providers Ignoring DNS TTL? 445

Posted by Cliff from the stale-results dept.
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 discussion has been archived. No new comments can be posted.

Providers Ignoring DNS TTL? More

Providers Ignoring DNS TTL?

Comments Filter:

  • Dumb question (Score:5, Interesting)

    by BoneFlower ( 107640 ) <anniethebruce@ g m a i l . c om> on Tuesday April 19, 2005 @11:33AM (#12282077) Journal
    How would I check my ISPs DNS servers for this?

    • Re:Dumb question (Score:5, Informative)

      by Alioth ( 221270 ) <no@spam> on Tuesday April 19, 2005 @11:40AM (#12282170) Journal
      Use the 'dig' and 'host' commands.

      For example

      dig @your-isps-nameserver.net -t A www.example.com

      For example:
      $ dig @192.168.0.1 -t A www.slashdot.org

      ; <<>> DiG 9.2.4 <<>> @192.168.0.1 -t A www.slashdot.org
      ;; global options: printcmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54561
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0

      ;; QUESTION SECTION:
      ;www.slashdot.org. IN A

      ;; ANSWER SECTION:
      www.slashdot.org. 7184 IN A 66.35.250.151

      ;; AUTHORITY SECTION:
      slashdot.org. 7184 IN NS ns2.vasoftware.com.
      slashdot.org. 7184 IN NS ns3.vasoftware.com.
      slashdot.org. 7184 IN NS ns1.osdn.com.
      slashdot.org. 7184 IN NS ns1.vasoftware.com.
      slashdot.org. 7184 IN NS ns2.osdn.com.

      ;; Query time: 3 msec
      ;; SERVER: 192.168.0.1#53(192.168.0.1)
      ;; WHEN: Tue Apr 19 11:38:58 2005
      ;; MSG SIZE rcvd: 159
      Note the TTL of 7184 seconds (this is how long the nameserver at 192.168.0.1 will continue to use the cached record for before fetching it again from slashdot.org's authoratative nameservers).

    • Re:Dumb question (Score:5, Informative)

      by Dtyst ( 790737 ) on Tuesday April 19, 2005 @11:49AM (#12282278)
      There are many online DNS tools DNS report [dnsreport.com] being one of the best and DNS stuff [dnsstuff.com] being very powerful but harder to use. I also like Dig it Man! [menandmice.com] for simple DNS checks. Also many large internet providers usually have allkinds of online network tools available online on their webpages.

  • TTL's (Score:5, Funny)

    by dlhm ( 739554 ) on Tuesday April 19, 2005 @11:33AM (#12282078)
    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.

  • Let me guess... (Score:4, Interesting)

    by sqlrob ( 173498 ) on Tuesday April 19, 2005 @11:33AM (#12282079)
    RoadRunner

    They can't run a DNS server properly to save their lives.

    TTL is ignored, SpamAssassin is a "trojan DDOSing our network"

  • I Noticed Too (Score:4, Insightful)

    by ArchAngel21x ( 678202 ) on Tuesday April 19, 2005 @11:33AM (#12282084)
    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.

  • 24 hours ? (Score:4, Informative)

    by Anonymous Coward on Tuesday April 19, 2005 @11:34AM (#12282089)
    in VOIP networks TTLs can be as low as 10 minutes

    • Re:24 hours ? (Score:4, Informative)

      by gclef ( 96311 ) on Tuesday April 19, 2005 @12:55PM (#12283052)
      heh. Have a look at www.yahoo.com...they're at 60 seconds. Yay Akamai.

      (For those that haven't messed with Akamai, they're intentionally setting the TTL insanely low to force clients to re-request often...Akamai uses the response they give as a way of doing path optimization to clients. It's ugly, but it kinda works.)

      • Re:24 hours ? (Score:3, Interesting)

        by logicnazi ( 169418 )
        Well that sounds like a good explanation for why major ISPs might ignore the TTL. That's alot of wasted lookups and server load. For a large ISP we can expect that someone is going to most Akamai cites every minute so that is at least one lookup per minute per Akamai DNS record.

        If other people do this as well ISPs might not have much of a choice but to ignore TTL and maybe there isn't any easy way to force the machine to use a minimum TTL but respect TTL above that limit.

  • DNS practices (Score:5, Informative)

    by LynXmaN ( 4317 ) * on Tuesday April 19, 2005 @11:34AM (#12282090) Homepage
    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.

    • Re:DNS practices (Score:2, Informative)

      by toddbu ( 748790 )
      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). The problem with someone else deciding on TTL for my zone (whether they're big or small) is that they'll probably get it wrong. How do you know the "right" value to pick for me when you don't know why I picked the value in the first place? Granted, some people pick low TTL "just because", but in our case we round-robin servers and if one goes down then we


    • 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 ret
      • I feel your pain -- I've done my share of idiot tech support questions that should never have been sent to me.

        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
        • Several months ago, we made the mistake of testing a new webmail server using AOL, but forgetting to actually add the DNS record first :-). The negative result is *still* cached at AOL. Bummer for users trying to use the webmail.

          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.

      • 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.

        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 serve

        • Re:DNS practices --- CHANGE THE !@#$%^& serial (Score:5, Informative)

          by jafiwam ( 310805 ) on Tuesday April 19, 2005 @01:43PM (#12283708) Homepage Journal
          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.

          • Nothing new here (Score:4, Interesting)

            by metamatic ( 202216 ) on Tuesday April 19, 2005 @03:04PM (#12284701) Homepage Journal
            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.)

    • Re:DNS practices (Score:3, Interesting)

      by Glendale2x ( 210533 )
      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).

      Why?

  • nscd (Score:4, Informative)

    by epiphani ( 254981 ) <epiphani&dal,net> on Tuesday April 19, 2005 @11:34AM (#12282091)
    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.

    • Re:nscd (Score:3, Informative)

      by photon317 ( 208409 )

      Yeah but nscd just caches for your local server box, it doesn't re-serve the cached results to your remote clients. He's describing actual dns cache/forward servers ignoring TTL and handing outdated/bad data to client machines.
  • 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 servic

    • Spammer zombies too (Score:2, Interesting)

      by AndroidCat ( 229562 )
      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.

  • You can use TTL to keep customers from leaving! (Score:5, Funny)

    by Anonymous Coward on Tuesday April 19, 2005 @11:38AM (#12282131)
    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.

  • old TTL? (Score:3, Insightful)

    by l33td00d42 ( 873726 ) on Tuesday April 19, 2005 @11:38AM (#12282133)
    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?

  • If you want to help then (Score:5, Informative)

    by cluge ( 114877 ) on Tuesday April 19, 2005 @11:39AM (#12282143) Homepage
    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.

  • old data (Score:5, Informative)

    by b1t r0t ( 216468 ) on Tuesday April 19, 2005 @11:39AM (#12282158)
    I've had problems before, but it turned out that it was usually my stupid secondary server which somehow didn't take the slave update (see below), and randomly that would be the one that gets queried and cached.

    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.

  • Efficiency reasons ? (Score:2, Interesting)

    by TwentyTwo ( 876854 )
    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

  • I know AOL used to be an offender, likely still is (Score:5, Interesting)

    by muckdog ( 607284 ) on Tuesday April 19, 2005 @11:42AM (#12282196) Homepage
    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.

    • Re:I know AOL used to be an offender, likely still (Score:5, Insightful)

      by ScentCone ( 795499 ) on Tuesday April 19, 2005 @12:57PM (#12283073)
      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.
  • 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. :-/

  • reboot? (Score:5, Informative)

    by grazzy ( 56382 ) <(ten.ews.ekauq) (ta) (yzzarg)> on Tuesday April 19, 2005 @11:44AM (#12282221) Homepage Journal
    (Thanks to my friends and relatives with dial ups and DSL who put up with me and my requests to reboot their machine daily!).

    ipconfig /flushdns

  • BW (Score:2, Insightful)

    by whackco ( 599646 )
    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...

  • 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 sys

  • Test case (Score:4, Insightful)

    by Other ( 29546 ) on Tuesday April 19, 2005 @11:50AM (#12282291)
    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.

  • Why would you reboot? (Score:5, Insightful)

    by Karma Farmer ( 595141 ) on Tuesday April 19, 2005 @11:51AM (#12282297)
    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.

  • comcast (Score:2, Informative)

    by gelwood ( 852074 )
    Last week, two nights in a row, Comcast's DNS was down NATION(USA) WIDE.

    • quick fix (Score:3, Informative)

      by ap0 ( 587424 )
      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.

  • How to check your DNS (Score:4, Informative)

    by jkujath ( 587282 ) on Tuesday April 19, 2005 @11:51AM (#12282301)
    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!).

    Why did you need to contact your friends/relatives to check whether or not your domain gets propagated?
    Couldn't you just query DNS servers directly using nslookup and/or dig?
    Querying them directly would eliminate you from wondering if the machine you are checking from has the DNS cached and you wouln't need to flush it (why would you need your friends/relatives to reboot their machines?). Not to mention the amount of time you would spend in having to coordinate this type of testing.
    Even if you don't want to use nslookup and/or dig from your Windows/Linux/Mac/whatever, there are tools available via the web that can help as well.
    This certainly is not a list of all the tools, or even the best ones... they're just ones that I have used in the past:

    dig [kloth.net] Web-based "dig" tool
    nslookup [kloth.net] Web-based "nslookup" tool
    DNS Report [dnsreport.com] Checks for DNS errors and provides nicely formatted information on a given domain
    DNS Stuff [dnsstuff.com] Various web-based DNS tools

  • direcway.com SUCKS (Score:4, Interesting)

    by Mustang Matt ( 133426 ) on Tuesday April 19, 2005 @11:51AM (#12282302)
    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.
  • 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 I

  • People abusing it on the other end... (Score:4, Interesting)

    by Evro ( 18923 ) * <evandhoffman.gmail@com> on Tuesday April 19, 2005 @11:52AM (#12282317) Homepage Journal
    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.
    • Setting a low TTL is not abuse; it's good administration. You need a short TTL in case of outages or other emergency actions. The bandwidth is negligible, even if thousands of sites do this. The ISPs are run by idiots.

      • Re:People abusing it on the other end... (Score:4, Insightful)

        by fm6 ( 162816 ) on Tuesday April 19, 2005 @12:55PM (#12283051) Homepage Journal
        The bandwidth is negligible, even if thousands of sites do this.
        But there are millions of sites out there. Still negligible?

        If DNS bandwidth were a non-issue, you wouldn't even be able to set TTL -- it would just be hardwired to a small value. But it is. Don't lapse into spammer logic: "I'm only wasting a tiny amount of resources, so it doesn't matter." But it does matter, because lots of other people are thinking the same thing.

  • 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.
  • 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.

  • You did what? (Score:3, Insightful)

    by SamMichaels ( 213605 ) on Tuesday April 19, 2005 @11:59AM (#12282392)
    Um...

    ipconfig /flushdns
    ipconfig /registerdns

    But wouldn't an easier way be just using dig to directly query the name servers?

    • Re:You did what? (Score:3, Insightful)

      by sabat ( 23293 )
      None of that will help Grandma with her browser. The major ISPs are running cache-ing DNS servers that don't flush their entries when they're told to. That's the problem.

  • Article is right on the money (Score:5, Informative)

    by wo1verin3 ( 473094 ) on Tuesday April 19, 2005 @11:59AM (#12282395) Homepage
    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".

  • save money - set your ttl to 2147483647 (Score:3, Funny)

    by Anonymous Coward on Tuesday April 19, 2005 @12:01PM (#12282420)
    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.
  • I noticed this back in the mid to late '90s. Many times AOL's DNS servers would take more than a month to notice an IP move. Same thing with others but AOL was the worst at the time. We used to caution our customers that if/when they moved to us or away from us, they needed to keep something at the old DNS for some time to redirect to the new one (web server, e-mail server, ftp server, etc.)

    The problem was not consistent, some of their servers displayed it and others (lesser number) did not - I believe tha

  • Spam, spam, spam (Score:5, Interesting)

    by krray ( 605395 ) * on Tuesday April 19, 2005 @12:35PM (#12282799)
    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 :).

    I would expect, now almost two months later, to be getting -0- traffic to the .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.

    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.

  • AOL used to do this (and probably still does) (Score:3, Insightful)

    by lythander ( 21981 ) on Tuesday April 19, 2005 @12:58PM (#12283082)
    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.

  • Where to begin... (Score:3, Insightful)

    by cbreaker ( 561297 ) on Tuesday April 19, 2005 @01:33PM (#12283564) Journal
    Okay first of all this guy doesn't really seem to have much depth of knowledge.

    Asking friends to REBOOT? Why not just ipconfig /flushdns? And For The Love Of God, DNS DOES NOT PROPAGATE. It's a referral system that caches.

    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.

  • New TTL won't take effect until old TTL runs out (Score:4, Insightful)

    by VGPowerlord ( 621254 ) on Tuesday April 19, 2005 @01:38PM (#12283639)
    I haven't seen this mentioned in any of the comments I've read so far, but changing the TTL on your server will not have any immediate effect on other companies servers.

    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!

  • Ignoring TTLs not necessarily intentional (Score:5, Insightful)

    by shirpa_kewl ( 238010 ) on Tuesday April 19, 2005 @01:41PM (#12283671)
    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.

  • Scientific article about this (Score:5, Informative)

    by eram ( 245251 ) on Tuesday April 19, 2005 @02:34PM (#12284315)
    There was an article called On the Responsiveness of DNS-based Network Control [imconf.net] presented at the Internet Measurement Conference" [imconf.net] 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.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close