[Dnsmasq-discuss] Query about solving a DHCPNAK issue

[Albert ARIBAUD]

Hi Kevin,

Le Mon, 1 Jun 2015 02:02:27 -0700, Kevin Benton <blak111 at gmail.com> a
écrit :

> I understand, but that eliminates the whole 'correcting rouge dhcp offers'
> part of the authoritative mode.
> 
> If we are teaching clients to ignore NAKs from other DHCP servers, why do
> DHCP servers like dnsmasq generate them in the first place? Wouldn't it be
> logically consistent to make a change to dnsmasq to prevent it from
> generating a NAK if the client is communicating with a different server?

That's my opinion too (although I can see a flip side to the coin: if
clients honor NAKs from any sever, then a rogue machine could break a
local noetwork by NAKing any and all DHCPREQUESTs, effectively DoSing
the whole segment at least).

> Is the client behavior regarding NAKs outlined in one of the DHCP RFCs? It
> does seem like there is a lot of confusion around what authoritative
> servers should be doing.

RFC 2131 says a server SHOULD send a DHCPNAK if it detects a DHCP
request for e.g. the wrong network. It also says "If the client
receives a DHCPNAK message, the client restarts the configuration
process", which, while there is no "MUST" in it, seems to me like a
non-optional requirement to honor DHCPNAKs.

> On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko <themiron at mail.ru>
> wrote:
> 
> > Hi Kevin,
> >
> > Ignoring all naks – would be, but the fix is different.
> >
> > That fix ignores all naks except from the selected/requested server only,
> > it’s ok.
> >
> >
> >
> > Best Regards, Vladislav Grishenko
> >
> >
> >
> > *From:* Kevin Benton [mailto:blak111 at gmail.com]
> > *Sent:* Wednesday, May 27, 2015 9:32 AM
> > *To:* Vladislav Grishenko
> > *Cc:* Brian Haley; Simon Kelley; dnsmasq-discuss at lists.thekelleys.org.uk
> > *Subject:* Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
> >
> >
> >
> > That fix is interesting. Doesn't ignoring a NAK sort of defeat the point
> > of the 'authoritative' NAKing in the first place?
> >
> >
> >
> > On Tue, May 26, 2015 at 2:26 PM, Vladislav Grishenko <themiron at mail.ru>
> > wrote:
> >
> > > 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?
> > >
> >
> > Hi Brian,
> >
> > Second dnsmasq assume the client request is to another server and responds
> > with NAK in authoritative mode.
> > The root of loop issue is in that busybox 1.20.x udhcpc client, it doesn't
> > check server id for anything but offer packet.
> > Bug is already fixed in bb 1.23.x, see commit
> >
> > http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52
> > e588c0
> >
> > Best Regards, Vladislav Grishenko
> >
> >
> >
> >
> > _______________________________________________
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss at lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
> >
> >
> >
> >
> > --
> >
> > Kevin Benton
> >
> 
> 
> 


Amicalement,
-- 
Albert.