[Dnsmasq-discuss] DNS TTL for responses based on DHCP leases

[Simon Kelley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 11/02/16 07:54, Lorin Weilenmann wrote:
> Hi list,
> 
> Currently, dnsmasq sets the DNS TTL for queries which it answers
> from local sources to 0 (or the value of --local-ttl). While this
> may be okay for entries out of /etc/hosts and addn-host files, it
> seems at least questionable for DHCP leases.
> 
> IMHO, a good DNS TTL for a DHCP lease would be the remaining
> duration of the lease (or half of that, since most DHCP clients
> renew their leases when half the lease time expired). Because many
> DHCP clients don't send a DHCPRELEASE when they disconnect from the
> network (either because they can't in case of wifi, or because they
> just don't), the DHCP server usually has no way invalidating a
> lease before it expires anyway.

You've almost answered your own question: the reason that the TTL is
zero unless over-ridden is that  a client can send a DHCP-RELEASE at
any time: just because a DHCP lease of length n seconds currently
exists, that doesn't guarantee that the lease will not be terminated
long before, and the associated name and/or address re-used. There's
another case where this can happen, which is if a new DHCP lease
arrives, declaring that the client has a name which is already in use
with another DHCP lease. In that case the new lease "steals" the name
from the existing lease, and an IP-name association is abruptly ended
with no warning.


> 
> I'd also love to have an option to set a DNS TTL per host-file
> entry, i.e. with a format like this: 1.2.3.4 host.domain.tld #3600 
> which would mean if the host line is followed by a comment which is
> a number, use that number in seconds as TTL for DNS responses.
> 
> The reason behind my request is the following: I have significant
> LAN traffic based on DNS, which results in unnecessary load on
> dnsmasq as it always responds with TTL 0 and thus prevents local
> caching. This also means that the entire LAN immediately "dies" if
> I the dnsmasq box isn't available even for a very short period
> (reboot). Setting --local-ttl is also not a feasible in my case
> because I have a backup internet connection, and one of my
> /etc/hosts entries points to the current external IP. This DNS
> response should go out with TTL 0. This way, the LAN clients can
> receive the new external IP immediately. By increasing --local-ttl,
> they'd get the "news" only after local-ttl seconds.
> 
> Any thoughts on my suggestions?

Rather than re-purpose comments in /etc/hosts files, how about
extending the dnsmasq host-record config option?

- --host-record=<name>[,<name>....],[<IPv4-address>],[<IPv6-address>]

These have exactly the same semantics as /etc/hosts entries, but the
syntax is under our control, so we don't need comment hacks to avoid
upsetting other systems.


Extending it to

- --host-record=<name>[,<name>....],[<IPv4-address>],[<IPv6-address>],[TTL
]

would be easy, since distinguishing an IPv4 pr IPv6 address from a TTL
is deterministic.


Cheers,

Simon.

> 
> Thanks, Lorin
> 
> 
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJWvgJvAAoJEBXN2mrhkTWiJ+QP/1N2irfXcu/VBjLbswPH8xcV
LaFvcwKNiHdypkhEHO/6BZudxa2DSB/tiBM5LTvePgJGe8Lw0XgR0rJRugKgTb+P
lxkVs1Q0Tb5y1EOC7mLAGW34yPLV9wRY5upyhXhJ4ZsVdaVoN2jyhGLn3URuJAhh
jliFXrWdbfAOjv+G5twNiTepcxGNU1LzvM08tFRDfLMMc7Ow/Gd/IiNAigiVihZt
4uzd5/4di2Y/08juKYMQCF6OgE6zH8dos+3gyqZ072WDYNd+OofeI06XelenPY/a
eYih/rH2IPs72DKa114eNNdOIiypxLGG68WblUG1d7JwibAQv2YSpgqvM/ogIocV
DAKLIYb+p68DTDViWZkTqhHaUacbqP6teJmHI7ggogFYqpCmXXT5rVcSiFooikiW
SDKAGWp5VS7vFcMH1QvND/9GuF2pTh57gmG+8ApLEv/xSKyarlMWfHue+kP9KQn6
dJNr4e/1GcuIFjgGlAMBO6xn2Q/uWEO2hwdo7k0wm+PmRBjkCEBouMMCVX3PcD8j
nhXWMzRx3OZGE5/ie9QhEup3eKRYdBJ7G5e3UdCIv6w550yIATgWyPNrgMYEoQxX
ITbk7xJ0VYOdIW2h2nNJspQcDvNsepO1YkFJ7ZoqYPnmOllomW0ZERV7WlTJV9G1
o+21KgJiWjtNiCgSstBZ
=hQFG
-----END PGP SIGNATURE-----