Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
Let me rephrase it slightly. What is the point of dnsmasq NAKing client responses to other servers if the clients are being programmed to ignore the NAKs? On the surface it looks like it's either pointless behavior on the server's part or incorrect logic in the DHCP client. Am I missing something? On Mon, Jun 1, 2015 at 2:58 AM, Vladislav Grishenko themi...@mail.ru wrote: Hi Kevin, why do DHCP servers like dnsmasq generate them in the first place? Because it’s per dnsmasq configuration and the effects are well-described in the man. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html *-K, --dhcp-authoritative* Should be set when *dnsmasq is definitely the only DHCP server on a network*. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum). you definitely have multiple dhcp servers, so this option is misused under your circumstances, not? Best Regards, Vladislav Grishenko *From:* Kevin Benton [mailto:blak...@gmail.com] *Sent:* Monday, June 01, 2015 2:02 PM *To:* Vladislav Grishenko *Cc:* Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk *Subject:* Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue 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? 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. On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko themi...@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:blak...@gmail.com] *Sent:* Wednesday, May 27, 2015 9:32 AM *To:* Vladislav Grishenko *Cc:* Brian Haley; Simon Kelley; dnsmasq-discuss@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 themi...@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
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
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). Oh definitely. DHCPNAKs are definitely not a good way to protect against rogue DHCP servers. Packet filtering (e.g. DHCP snooping or UDP drop rules) are much better at that. I was just pointing out that if we are teaching clients to ignore NAKs from other servers, we might as well have the servers stop sending NAKs in response to traffic to other servers. dhcp authoritative in the dnsmasq case would then just mean it accepts any renewal. 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. Right, so then wouldn't the referenced busy-box patch be making the client non-compliant? http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0 On Mon, Jun 1, 2015 at 2:51 AM, Albert ARIBAUD albert.arib...@free.fr wrote: Hi Kevin, Le Mon, 1 Jun 2015 02:02:27 -0700, Kevin Benton blak...@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 themi...@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:blak...@gmail.com] *Sent:* Wednesday, May 27, 2015 9:32 AM *To:* Vladislav Grishenko *Cc:* Brian Haley; Simon Kelley; dnsmasq-discuss@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 themi...@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
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
Hi Kevin, Le Mon, 1 Jun 2015 02:02:27 -0700, Kevin Benton blak...@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 themi...@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:blak...@gmail.com] *Sent:* Wednesday, May 27, 2015 9:32 AM *To:* Vladislav Grishenko *Cc:* Brian Haley; Simon Kelley; dnsmasq-discuss@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 themi...@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@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Kevin Benton Amicalement, -- Albert. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
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? 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. On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko themi...@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:blak...@gmail.com] *Sent:* Wednesday, May 27, 2015 9:32 AM *To:* Vladislav Grishenko *Cc:* Brian Haley; Simon Kelley; dnsmasq-discuss@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 themi...@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@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Kevin Benton -- Kevin Benton ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
Hi Kevin, why do DHCP servers like dnsmasq generate them in the first place? Because it’s per dnsmasq configuration and the effects are well-described in the man. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -K, --dhcp-authoritative Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum). you definitely have multiple dhcp servers, so this option is misused under your circumstances, not? Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com] Sent: Monday, June 01, 2015 2:02 PM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue 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? 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. On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko themi...@mail.ru mailto:themi...@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:blak...@gmail.com mailto:blak...@gmail.com ] Sent: Wednesday, May 27, 2015 9:32 AM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk mailto:dnsmasq-discuss@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 themi...@mail.ru mailto:themi...@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 http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0 e588c0 Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk mailto:Dnsmasq-discuss@lists.thekelleys.org.uk http
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
On the surface it looks like it's either pointless behavior on the server's part or incorrect logic in the DHCP client. Am I missing something? Yes, without overriding serverid to one from incoming request packet, the server’s nak could be pointless. But with overriding, it’ll introduce the same naking issue even with clients which were checking server id and ignoring naks from non-selected servers. Dnsmasq starts to nak request from selecting clients in 2.46, see the story here http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q4/002476.html Point of busybox’s udhcpc changes is described here https://bugs.busybox.net/show_bug.cgi?id=4267 As for ISC DHCP, it’s known client ignores NAK from non-selected servers in SELECTING state. As for server, it allow run-time control over weither or not a server, participating in failover, verifies server id option. This commit contains the old and new descriptions https://source.isc.org/cgi-bin/gitweb.cgi?p=dhcp.git;a=commitdiff;h=7116a34fc9b1fb307bcdca22e6963254289ecb80 Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com] Sent: Monday, June 01, 2015 5:15 PM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue Let me rephrase it slightly. What is the point of dnsmasq NAKing client responses to other servers if the clients are being programmed to ignore the NAKs? On the surface it looks like it's either pointless behavior on the server's part or incorrect logic in the DHCP client. Am I missing something? On Mon, Jun 1, 2015 at 2:58 AM, Vladislav Grishenko themi...@mail.ru mailto:themi...@mail.ru wrote: Hi Kevin, ы why do DHCP servers like dnsmasq generate them in the first place? Because it’s per dnsmasq configuration and the effects are well-described in the man. http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html -K, --dhcp-authoritative Should be set when dnsmasq is definitely the only DHCP server on a network. For DHCPv4, it changes the behaviour from strict RFC compliance so that DHCP requests on unknown leases from unknown hosts are not ignored. This allows new hosts to get a lease without a tedious timeout under all circumstances. It also allows dnsmasq to rebuild its lease database without each client needing to reacquire a lease, if the database is lost. For DHCPv6 it sets the priority in replies to 255 (the maximum) instead of 0 (the minimum). you definitely have multiple dhcp servers, so this option is misused under your circumstances, not? Best Regards, Vladislav Grishenko From: Kevin Benton [mailto:blak...@gmail.com mailto:blak...@gmail.com ] Sent: Monday, June 01, 2015 2:02 PM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk mailto:dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue 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? 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. On Tue, May 26, 2015 at 10:40 PM, Vladislav Grishenko themi...@mail.ru mailto:themi...@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:blak...@gmail.com mailto:blak...@gmail.com ] Sent: Wednesday, May 27, 2015 9:32 AM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@lists.thekelleys.org.uk mailto:dnsmasq-discuss@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 themi...@mail.ru mailto:themi...@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
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
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:blak...@gmail.com] Sent: Wednesday, May 27, 2015 9:32 AM To: Vladislav Grishenko Cc: Brian Haley; Simon Kelley; dnsmasq-discuss@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 themi...@mail.ru mailto:themi...@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 http://git.busybox.net/busybox/commit/?id=e2318bbad786d6f9ebff704490246bfe52e588c0 e588c0 Best Regards, Vladislav Grishenko ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk mailto:Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Kevin Benton ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
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 themi...@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@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Kevin Benton ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
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 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
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@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/02/15 19:50, Brian Haley wrote: Hi, There have been a number of people chasing an issue in Openstack where dnsmasq was sending DHCPNAK's after it was restarted since it's being started with --leasefile-ro (https://launchpad.net/bugs/1345947). I guess the first question is why you're giving yourself these problems in the first place? If you allow dnsmasq to have a lease file, or keep a lease database otherwise, then you'll have solved the source of the problem. The first solution was to create a script that could be called to re-populate the database inside dnsmasq based on the current contents of the hosts file that had been created (https://review.openstack.org/#/c/108272/). But then today someone else found the --dhcp-authoritative option (https://review.openstack.org/#/c/152080/) that seems to be an even easier solution. Since when Openstack is managing the DHCP service it *is* the authoritative server, this seems like the correct fix. Does anyone see any problem with this approach even when there are multiple dnsmasq processes being run (for HA), since both are under control of the same DHCP authority? It will probably be fine. The client first unicasts to the DHCP server, and --dhcp-authoritative means that the server will re-create the lost lease, rather then erroring. The problem is if the client broadcasts a renewal. In that case _both_ instances would reply. Exactly what happens in that case I'm not quite clear, I guess it would depend on the client. Maybe worth an experiment. Cheers, Simon. I'm hoping not as this would be a much easier fix. Thoughts? Thanks, -Brian ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUz95fAAoJEBXN2mrhkTWiCQ8P/RZ/EP9kUDwVry0dxwwrX4HH QrtypFn6F3ajD2fR03+qgYmIw5TU/12hwd0pRUYySrEsrou0DegldhFwpTPmD6Ix ooF15/OWyglZIH0L8Ze0xCPS16wYpfJ7kUhC8FFDMEgt937KJd1Pb3oI/WYoU4Em z9CgNaUaXZTxvbT9vR0FgpVGPEbctYMbI85pui8A9fZjE6DBS7E5Wn6KljkQAxgE ZgMQIjYXGD7Lslq0lgd1pZi/k/By7Nr+udaf/uf1uKOr2rLGzdtw4v195AT+qfjE 4t5KKYL/ZhUZhAHXlUzZZW+nGPHQtmKazOsDVaP48rPdA1da2Q5xKWgT4aRktGcn 8gqGeKGaJu794132ohfBOVBTWZ57ev4MqrcEKCCLaO5sbo3+jSpNCsdmd8e3Ekv4 X9tWW5bvEFEExqWTkQAhP5P6k8dU8bNwtS9UxEvtVl9CstoHP0toU3lgQABpbgFy KIzvblFyygExNZku2CdcTdvqK0+p9U8yBdoxpyVkHXAXG5n/VflFOMlyliwhatMW yb7eWi0Fp7BFYtrdvoEAV9n/9+Wene4PG4JjifRenofn++0ELLOwLIK+e5o4SlWk a7Up5e0IxrNTYpIAN6yRZzBD7X7w1utBKE0+Z/RVLZ5bcGbJ8+Yv4gCEWXqJrsYu Y+HnlB0xk+8MRGXqFbgv =LiWk -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/02/15 22:20, 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. dhcp-authoritative gives permission to dnsmasq to violate the RFC in a way which is useful in certain circumstances. Cheers, Simon. I'll test it anyways. -Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUz/qPAAoJEBXN2mrhkTWi8TEQAI3t0LDjKOEWwuyzDwCDG+Qy BXpYCZzsNgGzMycSztqm/OAsDoYzY71MvclT7UJZPIcT0P+xi6BZ6ow8xWG8GcuV 7NSeitolKQCXY0GYTxM8rQrfDCRLdHRfAzGAsAVQKwztVgDbURGTgt3aJ/uZSvBt Y1adYQ2O+miDK2iyfEKLZoadKj6VEXl86ep49kPXqnLEw7/gYOEHe2zmt6p8Laaj lcyovTxapofYuK0szeknWiuYjA66M6nTTsxM/mEJ9I+z2jZV00z9QUo/jvvJsFvo 0YcIqyjmwgSFqTKz4JxIwTqUWekxH1Y6fyillm9ius122oBlF7aTy6oVkZ6c6PVp vxrDXUu25T3vuwIMDQInA9hHZUAqAjgncV0Pps5A8yy6jYzNknzGM4H85gYhs81A qwUhF9Ed7TJ+TMyUcog1wKlvENZ/CDukf6mOaJMCB0ctUaK8Vhv5TiWqBa3IwNK+ 50To19DWlBGX7ogYiFOU/a0TQd69kaChbhvXj9iv+pyRbGRPDfR9EdU/rmpTmqKs YsXBNeQ/ztUtJrqxzpaDrVv/UpZxu5KAOBxItOq5vLcIMjnDqShdaVk4mIM/91Ot 5ePiBBoFhMRL7PEIBOi+gYXy/1Nqw+R075bHmJ+ts7Cl4S5fJF9iHrxspzHYwTg0 8/rVDG2bG0pjKllT0MGK =1gj+ -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/2015 05:30 PM, Simon Kelley wrote: On 02/02/15 22:20, 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. - -Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUz/5wAAoJEIYQqpVulyUo4/IH/RTpPryLt+1JPmYQTPtUz1vC sU0FBEGTzrg956zQeTSJjBOudVZ1od1RltU0hJ9rKJsQrJylnV9/ucu8iF7VHQwH x678qXK5+0wQADT/Ebd0CfVVIKrbUGlnv+01w0XmlRDaqMXxPAbU3qq0vLyKKi2o 4CR5Q2p70/oKq8lzowWNAej+pnOPg0zFdA2bDKZnFbrdqoFvoUOVhe1FSktwX3Kp OC4hCrbUVcm+f7R3b5yluHKpMr9H6bmgAwx7sKHqYCXFMXW4qm667G6aK/dui2Mt JPOMlq2igm6xcli/OfVAMDLZA36n+yaevTQJIOnhrS8EuYqOV7FkF80T9/wZUns= =hC+F -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Query about solving a DHCPNAK issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/02/2015 03:30 PM, Simon Kelley wrote: On 02/02/15 19:50, Brian Haley wrote: Hi, There have been a number of people chasing an issue in Openstack where dnsmasq was sending DHCPNAK's after it was restarted since it's being started with --leasefile-ro (https://launchpad.net/bugs/1345947). I guess the first question is why you're giving yourself these problems in the first place? If you allow dnsmasq to have a lease file, or keep a lease database otherwise, then you'll have solved the source of the problem. I don't have the complete changelog or discussion on why it was changed (lost during project re-name), but can take a guess: 1) Neutron didn't want to store this info in it's own DB since it's updated too often by too many processes 2) You can migrate where the DHCP server lives, or restart it, so without #1 there's no point seemingly in keeping such info, as the host file contains the things we need to know about The first solution was to create a script that could be called to re-populate the database inside dnsmasq based on the current contents of the hosts file that had been created (https://review.openstack.org/#/c/108272/). But then today someone else found the --dhcp-authoritative option (https://review.openstack.org/#/c/152080/) that seems to be an even easier solution. Since when Openstack is managing the DHCP service it *is* the authoritative server, this seems like the correct fix. Does anyone see any problem with this approach even when there are multiple dnsmasq processes being run (for HA), since both are under control of the same DHCP authority? It will probably be fine. The client first unicasts to the DHCP server, and --dhcp-authoritative means that the server will re-create the lost lease, rather then erroring. The problem is if the client broadcasts a renewal. In that case _both_ instances would reply. Exactly what happens in that case I'm not quite clear, I guess it would depend on the client. Maybe worth an experiment. In this HA case with 1 dnsmasq both will already respond to broadcast anyways, and it seems to work today - the first response is chosen. 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? I'll test it anyways. - -Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUz/grAAoJEIYQqpVulyUowr4H/2mKbwlpEfy+HtWsCRzKULUE R4Uj5wRRDitur0wFX1ZKBfg10+B/9cLNwB9NLRdC/ZjEzfLiqt3tFoxQmTnTNeRF m83m2OnP7HOHYBtyENThiRBxZUhz8AVns6wbHatuU4lLM3OjhQfp8+10gGOejoLm maXs8WE+uh7LzVSy+Sa7zVvszF9KwzG/oyUdccCecG9iOtzsWFOjWSGMXjXGwIMw XKTCSuDe5cwFmHiEdBn+p+5FvWNNddowQdBGvo4lJnh8Z/Uu8XNnBsAqlXFRRt40 h0ysI0nlr+EKh6tPqU1HT3KQCXa6wCGa1B0lq6jIHIEcbkwQhtHwTq2/YLXn1H8= =BkGO -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
