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

Fri Feb 26 21:59:50 GMT 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/02/16 11:13, Lorin Weilenmann wrote:
> 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?
> 

No sooner said, than done. Seems a sensible addition.

Cheers,

Simon.

> 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, crecp->ttd - now
>> 
>> 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-a
ddr>][,<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
>> 
> 
> 
> 
> _______________________________________________ Dnsmasq-discuss
> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk 
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCAAGBQJW0MrWAAoJEBXN2mrhkTWiYjwP/1VGFAsyPXFj9oMiRJmQUFuX
QjDukorWUTi8XnjNjOqX7c/yxvgrxeAWdwNvcZS88w3V9bnuTx0zoTuQv8c/qAN/
Alp353uSFhvjI0uYZq6EhHCW3F210qhbKWsA1685Ay4MHNVkzcHYfAkch1Ex6TrH
wPZMZ5kWhvsISRXTEnkA0C5afSLh9mr0NuHGzHh6jAyNrpj1+RMsI3UgaSG8otGf
T8PL3xel5KnFxmp0egQuaRc9caG2hKntyOJCkHcbSX9fzoYmVtcqjGk21KiBmM6i
AeIhFudeSOYIC5BAA0bhLwfmyAODo9hd/dL3QvdsvYTLIx3nO8f0HZbeyWORtUef
jxAGSNFmKX7ZtC+5jjDJ7ZvkYQQwW0Kp0LbV6i83W/sFKAbJe1Mf8QoZC6CN9VYG
ghUnKddW1geeUupqp0lEoGAIdUWNAMbONM6fuNzON9sWlD5kh19LY9/hXpt28h/d
q0EvALHyNDpoH33RjoxY/wGDnND0MJmZmxVhrLgEDGBNFXcgTLwj6gJQ/nnpTK5g
2+fUFbyqGWohis40ljcOwrusa9i/IC0pPNIuNT3vz7SBpzVzKHhUssctX92pJCny
BkJP9QiW2QT73yMPj2WitE4i9Ap/Sf5k/SJLnFzQakzhl60s+gO7zA3SIX123HCn
c3k8b6popuTNJr6RezN3
=JEe4
-----END PGP SIGNATURE-----