<div dir="ltr">Hi Simon,<div><br></div><div>Thanks a lot for your effort! I've just built the latest source from git and I'm quite happy with the changes, i.e. I can confirm that --dhcp-ttl and the new host-record additions work well for me.</div><div><br></div><div>I've noticed that replies which get their TTL from the dhcp-ttl option always get the TTL specified in dhcp-ttl. I'd prefer something like max(0, min(<dhcp-ttl>, <lease-expire-time> - <now>)). Otherwise, dns might hand out a high TTL for a dhcp-lease which expires one second later.</div><div><br></div><div>Do you think that's feasible?</div><div><br></div><div>Cheers,</div><div>Lorin<br><br><div class="gmail_quote"><div dir="ltr">On Wed, 24 Feb 2016 at 23:12 Simon Kelley <<a href="mailto:simon@thekelleys.org.uk">simon@thekelleys.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I just pushed changes to git which<br>
<br>
1) Support the TTL parameter in --host-record and --cname<br>
<br>
2) Add --dhcp-ttl, which overrides --local-ttl but only for DHCP-derived<br>
information.<br>
<br>
Between those, I think you should be able configure something suitable.<br>
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
<br>
On 12/02/16 21:56, Lorin Weilenmann wrote:<br>
> Hi Simon,<br>
><br>
> Thanks for taking the time and for your reply!<br>
><br>
>>> You've almost answered your own question: the reason that the TTL is<br>
>>> 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.<br>
><br>
> This is a possible scenario, but a DNS TTL doesn't guarantee that the<br>
> record won't change for TTL seconds (otherwise, you could never change a<br>
> DNS record with TTL > 0 :-) ). But even if a client sends a DHCP-RELEASE<br>
> it's unlikely for the IP to be assigned to another client until the dns ttl<br>
> expires - at least in environments where the dhcp pool is sufficiently<br>
> large. A dns client with a cached entry that has been released would try to<br>
> connect to a non-responsive IP, rather than getting nxdomain from dnsmasq,<br>
> which usually results in the same behavior. Nevertheless, I agree that my<br>
> argument is far perfect.<br>
><br>
>>> 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<br>
>>> with no warning.<br>
> This might lead to a delta between the cache on the client and dnsmasq, but<br>
> the client's record is still valid (as in: a host with the given fqdn<br>
> responds to the IP in the cache). Its the nature of caches to produce<br>
> results which may differ from the actual "source of truth".<br>
><br>
> However, your proposal to my next point got me thinking: What would you say<br>
> about extending the --dhcp-range option to the following:<br>
><br>
> --dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-addr>[,<end-addr>][,<mode>][,<netmask>[,<broadcast>]][,<lease<br>
> time>[,<dns ttl>]]<br>
><br>
> (note that <dns ttl> could only be specified if <lease time> was given<br>
> because otherwise it would not be possible to differentiate between the two)<br>
><br>
> Alternatively, there could be an new option:<br>
><br>
> --dhcp-dns-ttl=[tag:<tag>,[tag:<tag>,]]<dns ttl><br>
><br>
> The actual TTL in DNS answers would be calculated as:<br>
> max(<--local-ttl>, <dns ttl> + <time lease was handed out> - <now>).<br>
> Alternatively (if that's easier), you could just put the DHCP fqdn into the<br>
> DNS cache with TTL <dns ttl>. Once once the cache entry expires, dnsmasq<br>
> would return to resolve the name from "local sources" and use a TTL<br>
> speficied in --local-ttl. (This would only work if dnsmasq first looks in<br>
> the cache for a dns result, which I don't know).<br>
><br>
>>> Rather than re-purpose comments in /etc/hosts files, how about<br>
>>> extending the dnsmasq host-record config option? [...]<br>
>>> --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>
><br>
> I like this proposal very much. It's much better than parsing comments of a<br>
> hosts file.<br>
><br>
> Cheers,<br>
> Lorin<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Dnsmasq-discuss mailing list<br>
> <a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
> <a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
><br>
<br>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
<a href="mailto:Dnsmasq-discuss@lists.thekelleys.org.uk" target="_blank">Dnsmasq-discuss@lists.thekelleys.org.uk</a><br>
<a href="http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss" rel="noreferrer" target="_blank">http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss</a><br>
</blockquote></div></div></div>