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

[Simon Kelley]

I just pushed changes to git which

1) Support the TTL parameter in --host-record and --cname

2) Add --dhcp-ttl, which overrides --local-ttl but only for DHCP-derived
information.

Between those, I think you should be able configure something suitable.


Cheers,

Simon.


On 12/02/16 21:56, Lorin Weilenmann wrote:
> 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
> 
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>