-----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 <si...@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@lists.thekelleys.org.uk >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >>> >> >> >> >>> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > > > > _______________________________________________ Dnsmasq-discuss > mailing list Dnsmasq-discuss@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----- _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss