[Dnsmasq-discuss] Query about solving a DHCPNAK issue

[Brian Haley]

On 02/02/2015 05:47 PM, Brian Haley wrote:
>>
>>> The one thing I'm curious about is if dnsmasq is restarted while a VM
>>> holds a lease, how will it respond?  As someone else has pointed-out to
>>> me - isc-dhcp will respond with a DHCPNAK in that case, and wondered why
>>> there would be a difference with dnsmasq. Different interpretation of an
>>> RFC?
>>
>>
>> If by "dnsmasq is restarted" you mean "dnsmasq is restarted and therefore
>> has its lease database deleted", then the RFC says that if a server gets a
>> renewal for an unknown lease, it should return DHCPNAK. That's what dnsmasq
>> does _unless_ --dhcp-authoritative is set, when instead it quietly
>> re-creates the lease.
>
> Yes, your assumption is correct, as --leasefile-ro is used it knows of no
> current leases, and by default get a DHCPNAK.
>
>> dhcp-authoritative gives permission to dnsmasq to violate the RFC in a way
>> which is useful in certain circumstances.
>
> Thanks, it does seem to do what I want with my initial testing.

Hi Simon,

Replying to my old thread since using --dhcp-authoritative seems to have 
introduced an issue where a DHCP client can get a NAK when using multiple 
dnsmasq servers on the same subnet (they both have the same host information, >1 
running just to get HA).

Short story is that both dnsmasq's return the same lease info, but when the 
client ACKs (sending to broadcast), one agent ACKs and the other agent NAKs. 
The tcpdump shows this better than I'm describing:

https://launchpadlibrarian.net/207180476/dhcp_neutron_bug.html

Does that seem like normal operation to you?  Does this second dnsmasq assume 
this response is from a rogue server and NAKs since it didn't send out the offer?

Thanks,

-Brian