<div dir="ltr"><div>Hi Simon,</div><div><br></div><div>Thanks for taking the time and for your reply!</div><div><br></div>>>You've almost answered your own question: the reason that the TTL is<div>>>zero unless over-ridden is that  a client can send a DHCP-RELEASE at<br>>>any time: just because a DHCP lease of length n seconds currently<br>>>exists, that doesn't guarantee that the lease will not be terminated<br>>>long before, and the associated name and/or address re-used.</div><div><br></div><div>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.</div><div><br></div><div>>>There's<br>>>another case where this can happen, which is if a new DHCP lease<br>>>arrives, declaring that the client has a name which is already in use<br>>>with another DHCP lease. In that case the new lease "steals" the name<br>>>from the existing lease, and an IP-name association is abruptly ended</div><div>>>with no warning.</div><div>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".<br></div><div><br></div><div>However, your proposal to my next point got me thinking: What would you say about extending the --dhcp-range option to the following:</div><div><br></div><div>--dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-addr>[,<end-addr>][,<mode>][,<netmask>[,<broadcast>]][,<lease time>[,<dns ttl>]]</div><div><br></div><div>(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)</div><div><br></div><div>Alternatively, there could be an new option:</div><div><br></div><div>--dhcp-dns-ttl=[tag:<tag>,[tag:<tag>,]]<dns ttl></div><div><br></div><div>The actual TTL in DNS answers would be calculated as:</div><div>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).</div><div><br></div><div>>>Rather than re-purpose comments in /etc/hosts files, how about<br>>>extending the dnsmasq host-record config option? [...]<br></div><div>>> --host-record=<name>[,<name>....],[<IPv4-address>],[<IPv6-address>],[TTL]<br>>><br>>>would be easy, since distinguishing an IPv4 pr IPv6 address from a TTL<br>>>is deterministic.<br></div><div><br></div><div>I like this proposal very much. It's much better than parsing comments of a hosts file.</div><div><br></div><div>Cheers,</div><div>Lorin</div></div>