Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Providers Ignoring DNS TTL?

Cliff posted more than 9 years ago | from the stale-results dept.

The Internet 445

cluge asks: "It seems that several large providers give their users DNS servers that simply ignore DNS time to live (TTL). Over the past decade I've seen this from time to time. Recently it seems to be a pandemic, affecting very large cable/broadband and dial up networks. Performing a few tests against our broadband cable provider has shown that only one of the three provided DNS servers picked up a change in seven days or less. After turning in a trouble ticket with that provider - two of the three provided DNS servers were responding correct - while the third was still providing bad information more than two weeks after that specific change. What DNS caches ignore TTL by default? Is there a valid technical reason to ignore TTL?""This struck me as odd, and I decided to run a few tests using my own domain. Lowering the TTL to twenty four hours, and making changes and then checking to see when a change was picked up. I queried twelve outside DNS servers/caches that I had access to (Thanks to my friends and relatives with dial ups and DSL who put up with me and my requests to reboot their machine daily!). Checks performed against these outside DNS servers indicate that it may take as much as four to five weeks before a DNS change is picked up! Most DNS servers picked up the change within 48 hours. A small number did not (three out of twelve - that's a quarter of them!)

This merits more study, and prompts a few questions. So, before I begin with a more serious broad study, I'd like to get some feedback on the problem as I've seen it. I know the tin foil hat crowd will see the failure to propagate DNS correctly as censorship, and the OS/bind/djb/whatever zealots will simply see this as an argument for their particular religion.

Based on the responses I get, I will then setup and test a couple of domains with different DNS servers for 6 weeks and report back the findings. [volunteers welcome!]"

cancel ×

445 comments

Sorry! There are no comments related to the filter you selected.

Faulty system (1, Interesting)

Quasar1999 (520073) | more than 9 years ago | (#12282066)

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.

Re:Faulty system (5, Insightful)

wiredlogic (135348) | more than 9 years ago | (#12282092)

DNS isn't about "the web". It's much bigger than that.

Re:Faulty system (2, Funny)

AndroidCat (229562) | more than 9 years ago | (#12282147)

Quick! Someone tell that to NetSol before they route all .com/.net typos to their server again.

Re:Faulty system (0)

Anonymous Coward | more than 9 years ago | (#12282233)

Shut up.

Bypass their DNS (4, Interesting)

kherr (602366) | more than 9 years ago | (#12282326)

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.

ELOGICFAULT (5, Insightful)

Anonymous Coward | more than 9 years ago | (#12282330)

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

Re:Faulty system (4, Insightful)

MightyMartian (840721) | more than 9 years ago | (#12282362)

Screwing around with DNS TTLs has a larger effect than the web. Quite commonly when we're doing a major change, particularly with mail servers, we set our TTL low a few days in advance. If some idiot running a DNS sets it up so that my TTL is ignored, then guess what, whoever is using that DNS is suddenly not going to be able to get mail to my server.

It's irresponsible tampering, it's that simple.

Re:Faulty system (3, Informative)

Anonymous Coward | more than 9 years ago | (#12282462)

It's irresponsible tampering, it's that simple.

Its completely within the spec, and as a fundemental principle I can do whatever I want with my server. So get with the program and understand there are other ways of dealing with the issue. Two weeks before the change, set the new IP address of the mail server as a lower priority (higher number) server, so if the info is cached, it will fall back to the new number when the old one fails. When you make the change, you can purge the old address entirely.

This is DNS maintenance 101, and should not surprise anyone who works on DNS.

First Post?!?!? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12282071)

Please god, let me have it!!!

-DT

Re:First Post?!?!? (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12282252)

OMG rofl wtf omfgroflol ianal FWIW TTYL IIRC RAM roflOLROFlolwtfomgomgwtf DHCP 5UXX0|2Z!!!!!blowme1!!!1!!1

Re:First Post?!?!? (0)

Anonymous Coward | more than 9 years ago | (#12282338)

No, last post. But not any more.

Your god has failed you.. (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#12282259)

Please kill yourself at your earliest convenience.
Thank You

Dumb question (4, Interesting)

BoneFlower (107640) | more than 9 years ago | (#12282077)

How would I check my ISPs DNS servers for this?

Re:Dumb question (5, Informative)

Alioth (221270) | more than 9 years ago | (#12282170)

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 (5, Informative)

Dtyst (790737) | more than 9 years ago | (#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 (5, Funny)

dlhm (739554) | more than 9 years ago | (#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... (3, Interesting)

sqlrob (173498) | more than 9 years ago | (#12282079)

RoadRunner

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

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

Re:Let me guess... (1)

gid (5195) | more than 9 years ago | (#12282154)

Hmmm, I have Road Runner and I run spam assassin through sa-exim. I've never heard a peep out of them.

Re:Let me guess... (3, Informative)

sqlrob (173498) | more than 9 years ago | (#12282321)

I got a "Your machine is trojaned" e-mail with few details. A thorough scan of my network showed diddley-squat. I finally got to reasonable level support and the issue was poisoning the cache with negative lookups. I was testing the mail, and URLs within the mail as well. I think there was an average of 20 lookups/mail.

People running MailWasher on Windows also got the same warning from RR. All this was probably about a year ago.

I Noticed Too (4, Insightful)

ArchAngel21x (678202) | more than 9 years ago | (#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.

Re:I Noticed Too (1, Funny)

RLW (662014) | more than 9 years ago | (#12282142)

Don't speculate. Assert. You know it's true. Couple that with ignorance and you've got the typical large ISP admin.

Re:I Noticed Too (1)

ReelOddeeo (115880) | more than 9 years ago | (#12282370)

Don't speculate. Assert. You know it's true. Couple that with ignorance and you've got the typical large ISP admin.

Do their DNS servers run on Windows, and hence we are discussing Windows admins?

Or maybe they don't run Windows for DNS. In that case... Never attribute to ignorance what can be explained by malice.

Re:I Noticed Too (4, Insightful)

Alioth (221270) | more than 9 years ago | (#12282205)

The thing is if the server admins were lazy, the default configuration of any caching DNS server that I've come across is to do the Right Thing. Therefore if you have a lazy admin, it should be working.

They've actually had to go to extra effort to break it on purpose.

Re:I Noticed Too (1)

tomhudson (43916) | more than 9 years ago | (#12282428)

I thought (I may be wrong) that the TTL was originally supposed to be 11 minutes.

I know that for my home ISP (videotron), the changes propagage within 5 minutes (sometimes a lot less), but they're also doing VoIP and VoD, and ther latency is super low.

The ISP at work isn't so bad, either (aibn - sympatico for business - yeah, it really grinds me having to say anything nice about ma bell ... )

24 hours ? (4, Informative)

Anonymous Coward | more than 9 years ago | (#12282089)

in VOIP networks TTLs can be as low as 10 minutes

DNS practices (5, Informative)

LynXmaN (4317) | more than 9 years ago | (#12282090)

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 (2, Informative)

toddbu (748790) | more than 9 years ago | (#12282374)

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 want to be able to take it out of the loop in a timely fashion. We're ok with a 15 minute TTL, but not with a day.

Part of the problem with short TTL is that there is no really good mechanism in the Internet today for failing over a cluster of web servers short of buying expensive routing hardware. If you want to run a web server with a backup then having a short TTL is probably the best option around. What we need is a better DNS failover strategy and then many short-lived TTLs will probably go away. The current solution is crummy anyway. When Internap died here in Seattle and we were down for 45 minutes (along with LiveJournal [slashdot.org] ), a high priced router/load balancer wouldn't have done us a bit of good.

nscd (3, Informative)

epiphani (254981) | more than 9 years ago | (#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 (2, Informative)

photon317 (208409) | more than 9 years ago | (#12282183)


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.

Mediacom sucks.. (1)

jk0 (859377) | more than 9 years ago | (#12282099)

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.

It's a strange pandemic... (1, Funny)

LegendOfLink (574790) | more than 9 years ago | (#12282106)

called laziness.

Re:It's a strange pandemic... (1, Insightful)

Anonymous Coward | more than 9 years ago | (#12282188)

Given that you pretty much have to intentionally misconfigure a server to behave this way, it'd be hard to call it laziness.

Not laziness (1)

wiredog (43288) | more than 9 years ago | (#12282198)

apathy.

Re:It's a strange pandemic... (3, Funny)

justforaday (560408) | more than 9 years ago | (#12282222)

I would counter your argument, but it's too much effort...

For non geeks (0, Offtopic)

Nurseman (161297) | more than 9 years ago | (#12282121)

from Wikipedia

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 :-)

Re:For non geeks (5, Informative)

Anonymous Coward | more than 9 years ago | (#12282153)

They're referring to DNS TTL, not IP TTL.

Re:For non geeks (2, Informative)

eyegor (148503) | more than 9 years ago | (#12282195)

From this site [menandmice.com] : Time To Live, the number of seconds remaining on a cached record before it is purged. For authoritative records the TTL is fixed at a specific length. If a record is cached, the server providing the record will provide the time remaining on the TTL rather then the original length it was given.

Re:For non geeks Actually (1, Informative)

Anonymous Coward | more than 9 years ago | (#12282201)

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.

So close... (4, Informative)

Derek Pomery (2028) | more than 9 years ago | (#12282207)

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

Re:For non geeks (1)

pla (258480) | more than 9 years ago | (#12282216)

Hope thaty helps someone beside me :-)

I hope that didn't help you, since it refers to the wrong kind of TTL.

TTL for DNS servers means (informally) how long they will consider a given resolved IP address as still-good. After that, the DNS server itself will do a DNS lookup to try to get a fresher address.

Re:For non geeks (1)

phoebus1553 (522577) | more than 9 years ago | (#12282253)

These are unrealted topics...

The first is relating to IP packet TTL, or hopcount. That is, how many routers can this packet cross before its discarded, as OP states. This is only valid on the layer in question (3 I think) and applies only to packets. The goal here is to short circuit router loops and also bring some semblance of speed in that if a conversation gets translated to too many networks, it will simply die.

The second thing you state is an application level TTL, not at all related to the first. TTL WRT DNS is how long you'll answer questions out of your cache before you go ask the authoritative server for a new answer to the same question. I believe it also has an effect on slave DNS boxes in that they will ask the master of the zone for a full update when the TTL expires, regardless of whether or not someone is asking a question about it.

MOD -1, Just Plain Wrong (0)

Anonymous Coward | more than 9 years ago | (#12282331)

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.

Re:For non geeks (3, Informative)

Neil (7455) | more than 9 years ago | (#12282365)

Actually, the "TTL" in an IP header is different from the "TTL" in a DNS response (though in both cases the acronym means "time to live" and is intended as a limit on how long data hangs around).

IP header TTL is basically a hop-count, to stop IP packets going round in circles indefinately in the event of routing loops in the network.

Typically, when you look up a name like "www.example.com" your workstation consults a caching DNS server (on the local LAN, or offered by your ISP, or something). This DNS server goes off and talks to the root name servers, which refer it to the "com" name servers, which in turn refer it to the "example.com" name servers, from where it gets an IP address to go with the name. A couple of seconds later you ask for another page from "www.example.com". Your workstation asks the local DNS server for the information again, but the DNS server doesn't go and figure out the answer from scratch - it remembers the answer that it provided last time, and just repeats it. Time-To-Live is an "expiry date" that the authoritative name servers (like the "example.com" name servers) can put on their answers, so that the caching name servers know how long the answer is good for without them rechecking with an authoratative source.

Re:For non geeks (3, Informative)

Shopko (872100) | more than 9 years ago | (#12282469)

Actually that's for TCP's time to live. For DNS TTL, here's the scenario: (and yes this is simplified; there is more that actually happens, but it's not important for this discussion)

Background
----------
Domain Name Servers (DNS) are usually configured in a heirarchy, such that each server has a parent. This fact will be important below.

Every domain (i.e. slashdot.org) has one or more "authoritative" name servers. These name servers know what web host slashdot.org is hosted on and how to get there.

Other DNS's on the Internet do not know how to get to slashdot.org, because they are not "authoritative" for that particular domain. So they send a request out to their parent asking how to get to slashdot.org. Eventually, one of the parents will know the address of slashdot.org's authoritative name server, and will return this address.

How This Relates To TTL
-----------------------
Here is what happens once the address of the authoritative name server is returned:

A = The name server trying to figure out how to get to slashdot.org
B = The authoritative name server for slashdot.org

A asks B how to get to slashdot.org
B responds to A with an address (66.35.250.150)
A asks B how long this address is valid
B responds to A with a TTL (e.g. 24 hours)

So now name server A will not have to ask for slashdot.org's address again for 24 hours, since it was told by the authoritative name server that it can keep the address for 24 hours.

This "keeping of addresses" is called caching, and name servers that do this are called caching name servers.

I hope this helps. :-)

maybe a consequence of the cache poisoning attacks (2, Interesting)

ehanuise (672994) | more than 9 years ago | (#12282122)

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

Spammer zombies too (2, Interesting)

AndroidCat (229562) | more than 9 years ago | (#12282284)

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! (5, Funny)

Anonymous Coward | more than 9 years ago | (#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.

Re:You can use TTL to keep customers from leaving! (3, Interesting)

markv242 (622209) | more than 9 years ago | (#12282294)

Parent is the answer to why some providers ignore TTL, to prevent nutjobs like this from breaking the Internet.

old TTL? (3, Insightful)

l33td00d42 (873726) | more than 9 years ago | (#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?

TTL is useless, so who cares? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12282134)

Give me one good reason why TTL is useful.

It's not, therefore, it doesn't really matter if caches ignore it. I'd rather have stuff ignore my TTLs, that way I don't have to wait whenever I update IPs.

Re:TTL is useless, so who cares? (1, Flamebait)

Kupek (75469) | more than 9 years ago | (#12282203)

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.

Re:TTL is useless, so who cares? (1)

thomasa (17495) | more than 9 years ago | (#12282340)

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.

Re:TTL is useless, so who cares? (0)

Anonymous Coward | more than 9 years ago | (#12282394)

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.

How about *gasp* giving a valid reply??

Haha, does the truth hurt you or .. what?

Re:TTL is useless, so who cares? (1)

jd34 (599131) | more than 9 years ago | (#12282437)

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

If you want to help then (5, Informative)

cluge (114877) | more than 9 years ago | (#12282143)

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.

informativ.e maremaFre (-1, Troll)

Anonymous Coward | more than 9 years ago | (#12282157)

old data (4, Informative)

b1t r0t (216468) | more than 9 years ago | (#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.

The reason is quite simple (0, Funny)

Anonymous Coward | more than 9 years ago | (#12282165)

"Titty" is an adult word and therefore TTL is censored by many ISPs.

TTL or bad zones? (0)

Anonymous Coward | more than 9 years ago | (#12282184)

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

Efficiency reasons ? (2, Interesting)

TwentyTwo (876854) | more than 9 years ago | (#12282189)

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 ?

What's the point of not updating anyway... (5, Interesting)

GSloop (165220) | more than 9 years ago | (#12282192)

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

Re:What's the point of not updating anyway... (4, Informative)

MadRocketScientist (792254) | more than 9 years ago | (#12282318)

Has anyone done any measurement stats on DNS queries

According to my DNS hosting company's FAQ [zoneedit.com] :

"...or 200MB of usage is used (1 million DNS queries)"

Re:What's the point of not updating anyway... (2, Interesting)

GSloop (165220) | more than 9 years ago | (#12282467)

I just captured some DNS traffic. This isn't a recurrsive root DNS search, but just a client request.

The Request for www.cnn.com was 71 bytes.
The reply was 312 bytes.

I think EasyDNS's estimation of traffic required to fulfill a DNS query is massively over estimated. I can't see one taking even 1K bytes, much less the 2K bytes they're "estimating."

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

muckdog (607284) | more than 9 years ago | (#12282196)

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.

Is there a valid technical reason to ignore TTL? (1)

retro128 (318602) | more than 9 years ago | (#12282199)

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. :-/

Re:Is there a valid technical reason to ignore TTL (1)

robnator (250608) | more than 9 years ago | (#12282349)

you are simply NOT a huge ISP if your "bandwidth" is impacted by DNS traffic.

Yes there is (0, Offtopic)

NicolaiBSD (460297) | more than 9 years ago | (#12282212)

Is there a valid technical reason to ignore TTL?

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.

Re:Yes there is (4, Insightful)

Kupek (75469) | more than 9 years ago | (#12282258)

Caching, at all levels of computing, gives enormous performance gains. In the DNS world, without caching, everyone would hit top level domains which would introduce a serious bottleneck to what should be a distributed system.

Re:Yes there is (0)

Anonymous Coward | more than 9 years ago | (#12282380)

This is not a valid technical reason to ignore TTL, this is a gross misunderstanding of the purpose of caching.

Be a good citizen. Turn your caches back on. And please read up on DNS if you're administering DNS server.

reboot? (5, Informative)

grazzy (56382) | more than 9 years ago | (#12282221)

(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 (2, Insightful)

whackco (599646) | more than 9 years ago | (#12282243)

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

TTL timings (0)

Anonymous Coward | more than 9 years ago | (#12282268)


Lowering the TTL to twenty four hours, and making changes and then checking to see when a change was picked up.

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?

Classical Economics (1)

cyngus (753668) | more than 9 years ago | (#12282282)

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.

Test case (4, Insightful)

Other (29546) | more than 9 years ago | (#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? (4, Insightful)

Karma Farmer (595141) | more than 9 years ago | (#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 (2, Informative)

gelwood (852074) | more than 9 years ago | (#12282298)

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

How to check your DNS (4, Informative)

jkujath (587282) | more than 9 years ago | (#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 (3, Interesting)

Mustang Matt (133426) | more than 9 years ago | (#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.

Spam still coming to old IP address (1)

G4from128k (686170) | more than 9 years ago | (#12282309)

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.

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

Evro (18923) | more than 9 years ago | (#12282317)

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.

Re:People abusing it on the other end... (2, Insightful)

sabat (23293) | more than 9 years ago | (#12282399)

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.

dnscache, BIND, and Windows DNS (0)

Anonymous Coward | more than 9 years ago | (#12282319)

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.

not uncommon (1)

buddha42 (539539) | more than 9 years ago | (#12282342)

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.

Annoying, but true. (1)

BrotherPope (8102) | more than 9 years ago | (#12282359)

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.

ISP DNS? (1)

cBrewer (876427) | more than 9 years ago | (#12282373)

Top Tier - 4.2.2.1
4.2.2.2

Exactly one reason to ignore TTL (0)

Anonymous Coward | more than 9 years ago | (#12282376)

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

Wait.... (0)

Anonymous Coward | more than 9 years ago | (#12282385)

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.

Re:Wait.... (1)

sabat (23293) | more than 9 years ago | (#12282476)

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.


That's precisely how it does work.

You did what? (2, Insightful)

SamMichaels (213605) | more than 9 years ago | (#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? (2, Insightful)

sabat (23293) | more than 9 years ago | (#12282434)

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 (5, Informative)

wo1verin3 (473094) | more than 9 years ago | (#12282395)

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

We have had this issue for years .. (3, Informative)

GNUALMAFUERTE (697061) | more than 9 years ago | (#12282407)

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 (3, Funny)

Anonymous Coward | more than 9 years ago | (#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.

been a problem for a long time (1)

rcpitt (711863) | more than 9 years ago | (#12282425)

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

Bandwidth Savings (0)

Anonymous Coward | more than 9 years ago | (#12282433)

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.

DNS TTL (0)

Anonymous Coward | more than 9 years ago | (#12282444)

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.

TTL Ignorance (2, Interesting)

zoontf (64411) | more than 9 years ago | (#12282456)

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.

DNS Load Balance / Failover (1)

packethead (322873) | more than 9 years ago | (#12282463)

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

Solution: run Djbdns and cache DNS yourself (0)

bad_outlook (868902) | more than 9 years ago | (#12282468)

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:

http://ask.slashdot.org/comments.pl?sid=145460&cid =12178906 [slashdot.org]

http://ask.slashdot.org/comments.pl?sid=145189&cid =12156398 [slashdot.org]

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
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>