[Dnsmasq-discuss] TTL override for clients?

[Fredrik Ringertz]

Hi Simon,

Thank you very much! That worked almost perfectly! I realised I was using the source from Debian Lenny Stable which is only version 2.45 but I now have version 2.52 which has crec_ttl in it :)

The only problem I have is that the first query to dnsmasq now returns the original ttl, and every query after that seems to return my fixed value until the original ttl has been reached. I am assuming it probably uses another function somewhere when it is a brand new query that it needs to add to the cache as well? Any idea where about it might be located?


Thanks ever so much!


Best Regards

Fredrik

-----Original Message-----
From: Simon Kelley [mailto:simon at thekelleys.org.uk] 
Sent: 19 April 2010 15:23
To: Fredrik Ringertz
Cc: dnsmasq-discuss at lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] TTL override for clients?

Fredrik Ringertz wrote:
> Hi All,
> 
> I am currently using dnsmasq with a few Perl scripts which
> automatically reloads dnsmasq with different options on the fly. I
> use this to allow the user switch different firewall profiles which
> add/removes different "--address" options to redirect certain
> websites (I redirect windows update etc to another IP address if the
> user wants to block it temporarily etc).
> 
> The only problem with this method is that the clients OS caches the
> response for the period of time specified in the TTL. I therefore
> want to get around this issue by overriding the TTL given to them.
> However I don't want to change the actual TTL added to the dnsmasq
> cache (I don't want to add additional load to the upstream DNS
> servers, I just want my local clients to query dnsmasq more often).
> So I am interested in somehow changing the TTL given to the client,
> rather then the TTL added to the cache list.
> 
> Where is a good place for me to start? Could someone familiar with
> the source code point me in the right direction where I could hard
> code this option (and then I will later add a configurable
> parameter)? 


The function crec_ttl() in src/rfc1035.c should be all you need: just
implement your  ceiling  as part of the final return statement.


> Also what are people's general opinions on this? Does
> this break any RFC standards? I can imagine this might be a useful
> feature for a lot of other people so if I manage to do this in a tidy
> way then I could release this as a patch for other people to use?

As long as you don't allow TTL _longer_ than would otherwise be the
case, I can't see any objection on standards grounds. Don't forget that
making the TTL zero is valid and means "never cache this data locally"
so that's useful.

I don't know how generally useful this would be, but it's not a big
addition, so the bar is pretty low.


Cheers,

Simon.