Hi
because some of TTL of zones are low
I wanna to increase TTL variable in cached zones (zones that is cached from other name servers) in BIND.But i do not know to do this task
please guide me for this purpose
thanks for any guidance

You can't change the TTL on cached zones, the owner of the zone sets the TTL value, and you can't alter it.

Why worry about how quickly somebody sets the TTL of their zones? That is done so that if a server crashes, they have the ability to quickly change the web traffic to a server that is still up. They create virtually no work for your server, the work is on their servers to handle the frequent requests.

IF you don't like that, you have the option of creating your own zone. If for example, you are unhappy that google only has a 300 second TTL, you can define your own google.com zone. This is a stupid thing to do, as setting a zone you don't own as a static address, you may try to connect to a server that is down. If google needs to shut down one of their load balancers, they correct that by removing that A record from their zone. But since you don't like their low TTL, you static them to a given address, then you timeout trying to connect to something that was down, and if you had just left them to determine their own TTL, you'd never have a problem. Long story short, you're talking about such a minute amount of data traffic, there is absolutely no need to change the setup of DNS settings by someone else.

Peace,
JimBass

thanks for your attention
some of zones have low TTL that make problem for our adsl costumer.
Is there any way in order to increase TTL amount in BIND? even changing the source of BIND?
for example 4.2.2.4 always resolve the domains that their name severs is down or have problem,probably 4.2.2.4 increase the TTL amount of zone so that cached zones later expire

BIND was developed at a time when most computers internet connection was a phone modem. If they had enough bandwidth to make DNS queries on a phone, then even with the lowest ADSL connection, they still have ample bandwidth to make DNS queries.

the DNS server at 4.2.2.4 doesn't affect the cache time at all. I own the domain jimmcnamara.net. I don't run anything with that name, so I asked 4.2.2.4 for the info about my zone -

They have the answer cached for 2 hours, which is exactly how long I set the TTL to. I checked about 15 seconds later, and you can see they now have it cached for 7183 seconds, so they aren't changing the cached values at all. -

The reason you think they are caching answers is because a ton of people use them as resolvers. Those nameservers probably see several hundred times the volume of queries that a "normal" to small nameserver sees. If an authoritative nameserver goes down, any other server that has the values cached keeps them until the TTL expired. So even if all of my jimmcnamara.net nameservers went down, 4.2.2.4 would keep on resolving my domain name until the TTL expired, but then it would stop.

You can't change this functionality of BIND, short of tons of coding knowledge. Allowing the owner of a zone to set the TTL is the only way to do it. You're barking up the wrong tree here. You don't want to ever cache someone's info longer than they want you to. The DNS system has been in place for 2+ decades now. There is no reason to make the change you're asking about. You see in my requests above how small the data sent from 4.2.2.4 is? 49 bytes. Not kilobytes, 49 bytes. That is so less than nothing, that even people with phone modems can still resolve names easily. Its a fine system, breaking the TTL is not going to improve it in the least.

Peace,
JimBass

Ok, so lets place the question at other point of view:

spamhaus.org does limit the queries to their RBL list, so if I could cache the known listed hostnames from them for a higher time, I would reduce my queries to their list over time.

the only down-site that doesn't matter much: when a host gets delisted from them will take a bit longer to be delisted from the cache (which is obvious).

That is it.

Now something I saw on the reply to this post that I also see all the time over the internet (and mostly why I replied so I could say):

It is awful how people tries to prove the questioner's that they are wrong or doing a bad practice instead of answering their questions because they can't see it from a higher point of view.

Everybody should improve their small minds ...

Answering "You can't change this functionality of BIND." at the first time would had been enough imho, who cares about modem, adsl, fiber channel or byte counting...

Hello, Eduardo.

Your idea of improving one's mind is fine, but I don't believe you're correct in the rest of your assessment.

You COULD write a script that grabs any zone your BIND server caches from elsewhere, and create it as a local (to your server) zone file, set the TTL to whatever you want, restart BIND, and now you're resolving just the record you queried from a domain for as long as you see fit. BIND doesn't have that functionality built in, but you could make it happen with very little skill. Just telling the first poster (who wrote his post in November of 2008, you've really pulled this thread out of the graveyard) "no you can't" wouldn't be accurate. You absolutely could do it, but you shouldn't. That is why I went into the explaination that I did. TTLs exist for a reason, and within DNS, the only people who get to determine the TTL of a zone is the domain owner through their authoritative DNS. If you can alter a TTL record, then why not an A or MX record?

The folks at the spamhaus RBL are asking you to pay for high query volume because of the service they provide. They make the call on if a domain belongs on or off the RBL. You admitted yourself that you'd miss a site going off the RBL if you add TTL to a cached reply of theirs. Also mirroring the entier RBL zone cost money the last time I looked at it, and if you're paying to mirror the entire zone, it would make no sense to alter the TTLs. If you just cache the subset of IP addresses on the RBL that you've queried, you don't have the full RBL so you would still have to query them for any new connection made to your server, only saving yourself requerying them when the same IP hits your mail server again. I don't have statistics on it, but I bet then number of requeries to the RBL is rather low for a mail server. If the same remote server keeps trying to feed you spam, then any number of options exist to block that connection at a firewall, or simply have your MX not answer the call from theirs, saving you the RBL query.

The philosophy of why or why not is important in most cases, particularly one like this where you could do it if you really need to.

1 members found this post helpful.