Minimum TTL?

[Mukund Sivaraman]

On Thu, Feb 08, 2018 at 04:39:36PM +0100, Reindl Harald wrote:
> 
> 
> Am 08.02.2018 um 16:34 schrieb Mukund Sivaraman:
> > On Thu, Feb 08, 2018 at 01:30:04PM +0200, Michelle Konzack wrote:
> > > Hello Harald,
> > > Am 2018-02-08 hackte Reindl Harald in die Tasten:
> > > > you miss the topic
> > > > 
> > > > many DNSBL's have a very short TTL and at the same time a limit of
> > > > queries froma single IP until you need to pay for the service
> > > > 
> > > > so if you have a inbound MX and the RBL has 2 seconds TTL and a botnet
> > > > is trying to deliver spam to you override the 2 scodn TTL with 90
> > > > seconds or whatever makes sense reduces the total amount of DNS requests
> > > > dramatically
> > > 
> > > Sounds logic.
> > > 
> > > And this feature was rejected by the Bind Developers?
> > 
> > If the RRset wants a TTL of N seconds, then that is the authoritative
> > instruction from the owner of the zone about how the data should be
> > used. We have to follow that. The RFCs so far do not allow increasing
> > TTL, though they allow decreasing it.
> > 
> > If a DNSBL zone has a TTL of 2 seconds, then talk to the zone owner
> > about why it is so. There ought to be a reason from their perspective
> > why it is set to 2s
> 
> so what - nobody can force me to ask him the same question every 2 seconds
> and as long it's a local resolver for my own services the one i have to ask
> about any why in doubt is the person i face in the mirror every morning

I doubt the zone owner is forcing you to use their zone. You can nix
fetches to it. If you want the zone data, then follow what the zone
owner requires.

> yes, you are free to decide that named don't need to support the users
> wish of such a feature. but the result is that the user stops to use
> named at all on a inbound-mailserver and is done

Also, just for argument's sake, one user wants to extend TTLs to
5s. Another wants 60s TTLs. What is OK and what is going too far?

It really is something for the zone owner to consider.

		Mukund