Allow changing max-cache-ttl and max-ncache-ttl

[araemo]

Allow adjusting bind cache maximum ttls for bind caching, so my local names will update more rapidly for clients that roam from wired to wireless.

(Yes, I know I could tweak the TTLs in my domain, but since I previously queried the zone host directly, it was never an issue.. but I probably am going to decrease my TTLs some anyway).

Do NOT set max-cache-ttl to 0, according to a source I can't find anymore - NS records need to be cached long enough to be used during recursive queries... forward only; would fix that though.

[araemo]

I have tested this a bit - it does seem to build it with my specified max-cache-ttl and max-ncache-ttl settings:

$ sudo docker exec -it lancachenettesting_dns_1 grep "cache-ttl" /etc/bind/named.conf.options
        max-cache-ttl 300;
        max-ncache-ttl 300;

[MathewBurnett]

if setting 0 is known to be a problem its probably worth having code to prevent it

[araemo]

I don't disagree - but I also went a step further in my testing and set:

max-cache-ttl 0;
max-ncache-ttl 0;
forward only;

And it works well, so I was thinking about how to make that an option cleanly. I also noticed that one of the ipv6 PRs also sets forward only; though, so I didn't want to cause issues.

Perhaps I'll add another option for forward only, and only allow max-cache-ttl to be 0 if forward only is also set.

[araemo]

Updated to include the FORWARD_ONLY option - and not allowing MAX_DNSCACHE_TTL=0 unless FORWARD_ONLY=true

Not yet tested.

[VibroAxe]

@araemo is this ready to come out of WIP or do you still plan work on it?

[araemo]

I have had no chance to work on this since I started testing the latest version.. but it has been running on my network since june, so it seems to work. :)

[araemo]

I don't think there's any more work to do on this, actually. It works as intended for me, if someone else can test it and validate that it isn't just me that would be ideal.

[araemo]

@VibroAxe - Will this be merged at some point?

[MathewBurnett]

times being what they are it seems we had abandoned this for a bit. However it has again peaked my interest. I am tempted to say that if you have run yours with

max-cache-ttl 0;
max-ncache-ttl 0;

And it seems fine that we use those as a default rather than prevent them. I do recognise it was might suggestion that you do the work i'm now suggesting we remove. What do you think @araemo ?

[araemo]

I tested with both settings to 0 (though I have it set to only allow both to be set to 0 if you have FORWARD_ONLY set).

I did revert my config to 5 minutes (300) after testing that, but eventually I tore lancache out of my network entirely. With my other pull request (DNSSEC related) not accepted, I didn't want to keep having to build my own image to keep up with bug fixes, and I started having issues with microsoft store downloads.

So, I think this works, but I haven't tested it in about a year.

[MathewBurnett]

We are going to play with setting them to 0 with forward only as per #131 then if thats ok we will include that. The discussion between us is that right in that we never need the cache dns to be more than a poison for domains of interest.

[araemo]

Yeah, that's essentially why I made this PR - I didn't want another layer of DNS caching making things more annoying. I have my own local DNS that DHCP clients register to, and lancache adding a 5+ minute cache before those changes could be used was annoying.

I would like to direct some interest at #125 though.. unlike the comment that said it breaks lancache, it doesn't, I had lancache running with #125 in my network for quite a while. I still think that forcing people to do without DNSSEC when you could configure it so they can still get DNSSEC protection is a bad way to provide lancache's benefits.

[VibroAxe]

This has been superceeded by #131 which has now been merged