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

[Lorin Weilenmann]

Hi Simon,

Thanks for taking the time and for your reply!

>>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.

This is a possible scenario, but a DNS TTL doesn't guarantee that the
record won't change for TTL seconds (otherwise, you could never change a
DNS record with TTL > 0 :-) ). But even if a client sends a DHCP-RELEASE
it's unlikely for the IP to be assigned to another client until the dns ttl
expires - at least in environments where the dhcp pool is sufficiently
large. A dns client with a cached entry that has been released would try to
connect to a non-responsive IP, rather than getting nxdomain from dnsmasq,
which usually results in the same behavior. Nevertheless, I agree that my
argument is far perfect.

>>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.
This might lead to a delta between the cache on the client and dnsmasq, but
the client's record is still valid (as in: a host with the given fqdn
responds to the IP in the cache). Its the nature of caches to produce
results which may differ from the actual "source of truth".

However, your proposal to my next point got me thinking: What would you say
about extending the --dhcp-range option to the following:

--dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-addr>[,<end-addr>][,<mode>][,<netmask>[,<broadcast>]][,<lease
time>[,<dns ttl>]]

(note that <dns ttl> could only be specified if <lease time> was given
because otherwise it would not be possible to differentiate between the two)

Alternatively, there could be an new option:

--dhcp-dns-ttl=[tag:<tag>,[tag:<tag>,]]<dns ttl>

The actual TTL in DNS answers would be calculated as:
max(<--local-ttl>, <dns ttl> + <time lease was handed out> - <now>).
Alternatively (if that's easier), you could just put the DHCP fqdn into the
DNS cache with TTL <dns ttl>. Once once the cache entry expires, dnsmasq
would return to resolve the name from "local sources" and use a TTL
speficied in --local-ttl. (This would only work if dnsmasq first looks in
the cache for a dns result, which I don't know).

>>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>],[TTL]
>>
>>would be easy, since distinguishing an IPv4 pr IPv6 address from a TTL
>>is deterministic.

I like this proposal very much. It's much better than parsing comments of a
hosts file.

Cheers,
Lorin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160212/da1e3a6e/attachment.html>