[Dnsmasq-discuss] Per entry TTL override

[Olivier Mauras]

On Thu, 2014-04-03 at 21:37 +0100, Simon Kelley wrote:
> On 02/04/14 22:32, Olivier Mauras wrote:
> > 
> > 
> > On Mon, 2014-03-31 at 12:59 +0200, Olivier Mauras wrote:
> >> Hello,
> >> 
> >> Is it thinkable to allow a per entry TTL override system ? I have
> >> actually two different needs that i'd like to discuss. First
> >> NXDOMAINS. I'd like to cache NXDOMAIN from some forwarded domains
> >> to a specific value. Cache time based on default SOA TTL may be
> >> too long in some cases and requires a manual cache refresh :( 
> >> Easy example: Infra team provisions a new server and ping the
> >> hostname asked to see if it's not already taken - Yes they could
> >> act differently It's not, so result is cached and will stay for
> >> 1H - default SOA TTL. Server provisioning takes 10mn, and
> >> hostname is still cached as NX for 50mn :(
> >> 
> >> Second is entry override. Some specific DNS entries could have a 
> >> different TTL than the default one - But not globally per entry
> >> gives much more flexibility :)
> >> 
> >> 
> >> Would that make sense to have a binding for request replies -
> >> like the dhcp lua script support - or would this make more sense
> >> as specific harcoded options? If this makes any sense at all
> >> indeed :)
> >> 
> >> 
> >> Thanks, Olivier
> >> 
> >> 
> >> _______________________________________________ Dnsmasq-discuss
> >> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> > 
> > Seemed like i had a double neg-ttl declared in my config and my
> > command line at the same time which make it to not be correctly
> > handled... Also seems that no matter what neg-ttl is set to, the
> > first NXDOMAIN on a cold cache, always get the SOA TTL, am i
> > missing something ?
> 
> neg-ttl does not override the SOA TTL, it provides a TTL for NXDOMAIN
> if the upstream server doesn't include an SOA. (Lots of ISP
> nameservers seem to strip that information for "bandwidth saving") If
> you upstream servers include SOA, as they should, then neg-ttl will
> have no effect.
> > 
> > 
> > Any feedback on per entry TTL override
> 
> I'm not sure about that, it seems to me to be fiddly and prone to
> errors. You first example could be fixed by using --no-negcache. It
> would be less efficient, but it would always work. If you're going to
> set a TTL in that case, what's the correct value that will always
> work? I don't think there is one.
> 
> I'm interested in other opinions.
> 
> 
> Cheers,
> 
> 
> Simon.
> 
> > 
> > 
> > Thanks, Olivier
> > 
> > 
> > 
> > _______________________________________________ Dnsmasq-discuss
> > mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> > 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

True that no-negcache would fix my first example, but wouldn't caching
for a definite time be more efficient?

I actually have weird behavior when cascading dnsmasq instances.
127.0.0.1 forwarding to a dnsmasq instance, forwarding to an unbound
server...
127.0.0.1 on first query receives the SOA TTL, but as the forwarded
dnsmasq instance has cached, it returns 0 as TTL.
So clearing cache on 127.0.0.1 and asking again same query will return
with neg-ttl as the TTL.
I agree it's pretty particular but having a "neg-cache-ttl" would
prevent this _and_ be efficient enough :)

That was for NXDOMAINS, what about overriding TTL for standard entry?
opinions?


Thanks,
Olivier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20140404/f75284f7/attachment.sig>