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

[Lorin Weilenmann]

Hi Simon,

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.

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.

Do you think that's feasible?

Cheers,
Lorin

On Wed, 24 Feb 2016 at 23:12 Simon Kelley <simon at thekelleys.org.uk> wrote:

> 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
> >
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160225/a03d5318/attachment-0001.html>