Re: [Dnsmasq-discuss] dhcp-name-match ?
On 05/12/2019 22:48, Simon Kelley wrote: > On 15/11/2019 03:53, James Feeney wrote: >> Hey Simon >> >> On 11/8/19 4:36 PM, Simon Kelley wrote: >>> If there's no name configured in the dnsmasq configuration, then the >>> client-provided name will be matched. However if there is a name >>> configured in the dnsmasq configuration, selected by MAC address or >>> client-id, then that will be used in preference. To an extent, what the >>> client chooses to use as its name is secondary: dnsmasq determines the >>> client's name so that it can be inserted into the DNS. If the >>> configuration specifies that name, then that's what dnsmasq puts in the >>> DNS, and it's what dnsmasq uses with dhcp-name-match. >> >> Hmm - ok. Still, it seems to me that that behavior is not an "intuitive" >> interpretation of the option "dhcp-name-match", such that that explanation >> should definitely be added to the dnsmasq man page, at >> "--dhcp-name-match=...". >> >> In particular, it should be made clear that the client-provided name will >> *not* be matched under some circumstances. In other words, sometimes it >> will "work", and sometimes it will not, and the administrator should not >> expect consistency. >> >> It should also be made clear that the client's idea of its own host name has >> nothing to do with the host name that dnsmasq will use in its own DNS >> registry, and that this will be most noticeable when the client chooses to >> ignore the host name offered to the client by dnsmasq. > > This behaviour (name configured in dnsmasq trumps name supplied by > client) is of very long standing, and could not, in all conscience, be > changed now it would break too many existing configurations. It's > pretty difficult to see how it would be confusing: you configure dnsmasq > to give the host with MAC address name and it does it. It also > returns that name on DHCP replies to the host, so it can use it too, if > so configured. > >> >> To be clear, I disagree with your approach. I would prefer that the >> "tagging" function simply be intuitively predictable and consistent, and >> *independent* of how dnsmasq determines the client's name and then inserts >> that name into the DNS registry. > > I may have to eat my words here. Reading the existing man page shows > that matching the client-supplied name was probably the original > intention, and the two examples of how it could be used are certainly > useful, and require that the name matched is the one supplied by the client. > > Quote: "Set the tag if the given name is supplied by a dhcp client. > There may be a single trailing wildcard *, which has the usual meaning. > Combined with dhcp-ignore or dhcp-ignore-names this gives the ability to > ignore certain clients by name, or disallow certain hostnames from being > claimed by a client." > > Looks like I have to revise my fix.. > > > Cheers, > > Simon. > Revised fix committed. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
On 15/11/2019 03:53, James Feeney wrote: > Hey Simon > > On 11/8/19 4:36 PM, Simon Kelley wrote: >> If there's no name configured in the dnsmasq configuration, then the >> client-provided name will be matched. However if there is a name >> configured in the dnsmasq configuration, selected by MAC address or >> client-id, then that will be used in preference. To an extent, what the >> client chooses to use as its name is secondary: dnsmasq determines the >> client's name so that it can be inserted into the DNS. If the >> configuration specifies that name, then that's what dnsmasq puts in the >> DNS, and it's what dnsmasq uses with dhcp-name-match. > > Hmm - ok. Still, it seems to me that that behavior is not an "intuitive" > interpretation of the option "dhcp-name-match", such that that explanation > should definitely be added to the dnsmasq man page, at > "--dhcp-name-match=...". > > In particular, it should be made clear that the client-provided name will > *not* be matched under some circumstances. In other words, sometimes it will > "work", and sometimes it will not, and the administrator should not expect > consistency. > > It should also be made clear that the client's idea of its own host name has > nothing to do with the host name that dnsmasq will use in its own DNS > registry, and that this will be most noticeable when the client chooses to > ignore the host name offered to the client by dnsmasq. This behaviour (name configured in dnsmasq trumps name supplied by client) is of very long standing, and could not, in all conscience, be changed now it would break too many existing configurations. It's pretty difficult to see how it would be confusing: you configure dnsmasq to give the host with MAC address name and it does it. It also returns that name on DHCP replies to the host, so it can use it too, if so configured. > > To be clear, I disagree with your approach. I would prefer that the > "tagging" function simply be intuitively predictable and consistent, and > *independent* of how dnsmasq determines the client's name and then inserts > that name into the DNS registry. I may have to eat my words here. Reading the existing man page shows that matching the client-supplied name was probably the original intention, and the two examples of how it could be used are certainly useful, and require that the name matched is the one supplied by the client. Quote: "Set the tag if the given name is supplied by a dhcp client. There may be a single trailing wildcard *, which has the usual meaning. Combined with dhcp-ignore or dhcp-ignore-names this gives the ability to ignore certain clients by name, or disallow certain hostnames from being claimed by a client." Looks like I have to revise my fix.. Cheers, Simon. > > James > ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
On 11/17/19 9:58 AM, James Feeney wrote: On 11/14/19 10:17 PM, Geert Stappers wrote: I look forward to the change proposal. Learn to read English for comprehension, and then refer back to the post you quoted. he's saying submit a patch and see what happens ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
On 11/14/19 10:17 PM, Geert Stappers wrote: > I look forward to the change proposal. Learn to read English for comprehension, and then refer back to the post you quoted. > Zero fuck giving how much disagreement there might be. > What matters is where we agree. We may agree that dnsmasq is Simon's project, and that Simon should choose to have dnsmasq function exactly as he thinks best. James ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
On Thu, Nov 14, 2019 at 08:53:07PM -0700, James Feeney wrote: > On 11/8/19 4:36 PM, Simon Kelley wrote: > > If there's no name configured in the dnsmasq configuration, then the > > client-provided name will be matched. However if there is a name > > configured in the dnsmasq configuration, selected by MAC address or > > client-id, then that will be used in preference. To an extent, what the > > client chooses to use as its name is secondary: dnsmasq determines the > > client's name so that it can be inserted into the DNS. If the > > configuration specifies that name, then that's what dnsmasq puts in the > > DNS, and it's what dnsmasq uses with dhcp-name-match. > > Hmm - ok. Still, it seems to me that that behavior is not an > "intuitive" interpretation of the option "dhcp-name-match", such that > that explanation should definitely be added to the dnsmasq man page, > at "--dhcp-name-match=...". > > In particular, it should be made clear that the client-provided > name will *not* be matched under some circumstances. In other > words, sometimes it will "work", and sometimes it will not, and the > administrator should not expect consistency. > > It should also be made clear that the client's idea of its own host > name has nothing to do with the host name that dnsmasq will use in > its own DNS registry, and that this will be most noticeable when the > client chooses to ignore the host name offered to the client by dnsmasq. > > To be clear, I disagree with your approach. I would prefer that the > "tagging" function simply be intuitively predictable and consistent, > and *independent* of how dnsmasq determines the client's name and then > inserts that name into the DNS registry. I look forward to the change proposal. Decoded version: Zero fuck giving how much disagreement there might be. What matters is where we agree. Groeten Geert Stappers -- Leven en laten leven signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
Hey Simon On 11/8/19 4:36 PM, Simon Kelley wrote: > If there's no name configured in the dnsmasq configuration, then the > client-provided name will be matched. However if there is a name > configured in the dnsmasq configuration, selected by MAC address or > client-id, then that will be used in preference. To an extent, what the > client chooses to use as its name is secondary: dnsmasq determines the > client's name so that it can be inserted into the DNS. If the > configuration specifies that name, then that's what dnsmasq puts in the > DNS, and it's what dnsmasq uses with dhcp-name-match. Hmm - ok. Still, it seems to me that that behavior is not an "intuitive" interpretation of the option "dhcp-name-match", such that that explanation should definitely be added to the dnsmasq man page, at "--dhcp-name-match=...". In particular, it should be made clear that the client-provided name will *not* be matched under some circumstances. In other words, sometimes it will "work", and sometimes it will not, and the administrator should not expect consistency. It should also be made clear that the client's idea of its own host name has nothing to do with the host name that dnsmasq will use in its own DNS registry, and that this will be most noticeable when the client chooses to ignore the host name offered to the client by dnsmasq. To be clear, I disagree with your approach. I would prefer that the "tagging" function simply be intuitively predictable and consistent, and *independent* of how dnsmasq determines the client's name and then inserts that name into the DNS registry. James ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
On Wed, Oct 30, 2019 at 09:32:14PM +, Simon Kelley wrote: > On 28/10/2019 02:45, James Feeney wrote: > > Hey Simon > > > > Thanks for that. Yes, that's it. > > > > I tried simply removing the dhcp-host hostname, and then the tag is > > added, as expected. > > > > Yes, that does not seem to be an "expected" behavior, dhcp-host > > interacting with dhcp-name-match. > > > >>From reading the man page, at dhcp-host: > > > > This allows a machine with a particular hardware address to be > > always allocated the same hostname, IP address and lease time. A > > hostname specified like this overrides any supplied by the DHCP > > client on the machine. > > > > This would seem to imply that dnsmasq would just offer the dhcp-host > > specified hostname in the options returned, and not otherwise > > discriminate against the client. > > > > *Without* the dhcp-host hostname, dnsmasq simply "reflects" the > > hostname provided by the client: option: 12 hostname NPI8C840E > > > > And *with* the dhcp-host hostname specified, "NPI8C840E" in this > > case, dnsmasq simply offers that dhcp-host hostname, but converted > > to lower-case - where DNS is not case sensitive, of course: option: > > 12 hostname npi8c840e > > > > It seems to make no difference whether the dhcp-host hostname is > > specified with just the hostname part, or as a FQDN, with both the > > hostname part "dot" the domain name part. > > > > So, all in all, I'd interpret that as a bug, that dhcp-name-match is > > failing when a dhcp-host hostname is specified. Even if the "client > > provides name:" value were something wild, and nothing to do with > > the specified hostname, I don't know that there would be any reason > > to ignore that wild client provided name. I could imagine that some > > appliance might both provide a client name and, at the same time, > > always ignore the offered dhcp hostname. We might still want to be > > able to "tag" that appliance. > > > > What do you think? > > I think it's a definite bug. If the dhcp-host line sets a name for the > host, then dhcp-name-match NEVER matches that name OR the one supplied > by the host. That's wrong. > > The question is, is the client-provided name and the dhcp-host name > differ, which one should be matched? Since this is broken, there's no > pre-existing behaviour to consider. Any configurations relying on one or > the other are currently broken be definition. > > I've decided that if both exist, then the name from dhcp-host should be > matched. It seems that if the config explicitly nails a MAC address or > client-id to a name, that's the one that should be used. > > > Patch in git now, fixing DHCPv4 and DHCPv6 > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=6ebdc95754cbae1cea376f4856634377566485c0 > Seeing "DHCPv6" did me wonder if http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q4/012707.html still would apply. It did. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
On 07/11/2019 03:52, James Feeney wrote: > Hey Simon > > On 10/30/19 3:32 PM, Simon Kelley wrote: >> The question is, [if] the client-provided name and the dhcp-host name >> differ, which one should be matched? Since this is broken, there's no >> pre-existing behaviour to consider. Any configurations relying on one or >> the other are currently broken [by] definition. >> >> I've decided that if both exist, then the name from dhcp-host should be >> matched. It seems that if the config explicitly nails a MAC address or >> client-id to a name, that's the one that should be used. > > Hmm - if you would, let me make sure I understand, then, how this will work. > > I would have thought to make "dhcp-name-match" match against the client > provided name, since there is nothing that will assure that the client > provided name is anything different from what the client wants to provide. > The client is not, necessarily, going to adopt the hostname provided by the > dhcp server. > > So then, does the "new" behavior mean that, effectively, "dhcp-name-match" is > really a kind of "MAC-address-match", or "DUID-match", by way of the > dhcp-host specified hostname? > > I should, then, simply write "dhcp-name-match=", where the > name is just the name associated with the dhcp-host MAC address, or with the > DUID? > > Also, then, if there is *no* dhcp-host hostname specified, will > "dhcp-name-match" still match the client provided name? Or, will that no > longer work, at all? > > A difficulty I see here, is that, if the client DUID or MAC address is *not* > known, and only the persistent client provided name is offered by the client, > then there will be no way to actually tag the client, unless every client > DUID or MAC address is first discovered and manually configured with a > hostname. > > And then, why not simply have a "dhcp-DUID-match" or a "dhcp-MAC-addr-match", > instead? > > James > If there's no name configured in the dnsmasq configuration, then the client-provided name will be matched. However if there is a name configured in the dnsmasq configuration, selected by MAC address or client-id, then that will be used in preference. To an extent, what the client chooses to use as its name is secondary: dnsmasq determines the client's name so that it can be inserted into the DNS. If the configuration specifies that name, then that's what dnsmasq puts in the DNS, and it's what dnsmasq uses with dhcp-name-match. Simon ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
Hey Simon On 10/30/19 3:32 PM, Simon Kelley wrote: > The question is, [if] the client-provided name and the dhcp-host name > differ, which one should be matched? Since this is broken, there's no > pre-existing behaviour to consider. Any configurations relying on one or > the other are currently broken [by] definition. > > I've decided that if both exist, then the name from dhcp-host should be > matched. It seems that if the config explicitly nails a MAC address or > client-id to a name, that's the one that should be used. Hmm - if you would, let me make sure I understand, then, how this will work. I would have thought to make "dhcp-name-match" match against the client provided name, since there is nothing that will assure that the client provided name is anything different from what the client wants to provide. The client is not, necessarily, going to adopt the hostname provided by the dhcp server. So then, does the "new" behavior mean that, effectively, "dhcp-name-match" is really a kind of "MAC-address-match", or "DUID-match", by way of the dhcp-host specified hostname? I should, then, simply write "dhcp-name-match=", where the name is just the name associated with the dhcp-host MAC address, or with the DUID? Also, then, if there is *no* dhcp-host hostname specified, will "dhcp-name-match" still match the client provided name? Or, will that no longer work, at all? A difficulty I see here, is that, if the client DUID or MAC address is *not* known, and only the persistent client provided name is offered by the client, then there will be no way to actually tag the client, unless every client DUID or MAC address is first discovered and manually configured with a hostname. And then, why not simply have a "dhcp-DUID-match" or a "dhcp-MAC-addr-match", instead? James ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-name-match ?
On 28/10/2019 02:45, James Feeney wrote: > Hey Simon > > Thanks for that. Yes, that's it. > > I tried simply removing the dhcp-host hostname, and then the tag is added, as > expected. > > Yes, that does not seem to be an "expected" behavior, dhcp-host interacting > with dhcp-name-match. > >>From reading the man page, at dhcp-host: > > > This allows a machine with a particular hardware address to be always > allocated the same hostname, IP address and lease time. A hostname specified > like this overrides any supplied by the DHCP client on the machine. > > > This would seem to imply that dnsmasq would just offer the dhcp-host > specified hostname in the options returned, and not otherwise discriminate > against the client. > > *Without* the dhcp-host hostname, dnsmasq simply "reflects" the hostname > provided by the client: > option: 12 hostname NPI8C840E > > And *with* the dhcp-host hostname specified, "NPI8C840E" in this case, > dnsmasq simply offers that dhcp-host hostname, but converted to lower-case - > where DNS is not case sensitive, of course: > option: 12 hostname npi8c840e > > It seems to make no difference whether the dhcp-host hostname is specified > with just the hostname part, or as a FQDN, with both the hostname part "dot" > the domain name part. > > So, all in all, I'd interpret that as a bug, that dhcp-name-match is failing > when a dhcp-host hostname is specified. > Even if the "client provides name:" value were something wild, and nothing to > do with the specified hostname, I don't know that there would be any reason > to ignore that wild client provided name. I could imagine that some > appliance might both provide a client name and, at the same time, always > ignore the offered dhcp hostname. We might still want to be able to "tag" > that appliance. > > What do you think? I think it's a definite bug. If the dhcp-host line sets a name for the host, then dhcp-name-match NEVER matches that name OR the one supplied by the host. That's wrong. The question is, is the client-provided name and the dhcp-host name differ, which one should be matched? Since this is broken, there's no pre-existing behaviour to consider. Any configurations relying on one or the other are currently broken be definition. I've decided that if both exist, then the name from dhcp-host should be matched. It seems that if the config explicitly nails a MAC address or client-id to a name, that's the one that should be used. Patch in git now, fixing DHCPv4 and DHCPv6 http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=6ebdc95754cbae1cea376f4856634377566485c0 Cheers, Simon. > > > James > > > > On 10/22/19 4:31 PM, Simon Kelley wrote: >> Looking at the code, the only obvious explanation is if you are >> over-riding the hostname in the dnsmasq configuration, ie with dhcp-host. >> >> In that case the client-provided name is ignored, including for the >> purposes of dhcp-name-match. (This may be a bug, but it is also an >> explanation.) >> >> >> Simon >> >> >> On 22/10/2019 15:43, James Feeney wrote: >>> dnsmasq 2.80-4 >>> Arch Linux >>> >>> /etc/dnsmasq.conf >>> dhcp-name-match=set:printer,NPI* >>> >>> $ journalctl -ab >>> ... >>> client provides name: NPI8C840E.prime >>> ... >>> tags: known, enp4s0 >>> >>> Uhm - so, did I miss something? Or, is "dhcp-name-match=" broken? >>> Why is the tag "printer" not been appended to the list of tags? >>> >>> The similar "dhcp-vendorclass=" seems to work as expected. >>> Is "dhcp-name-match=" different in some way? >>> >>> >>> Thanks >>> James >>> >>> ___ >>> 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
Re: [Dnsmasq-discuss] dhcp-name-match ?
Looking at the code, the only obvious explanation is if you are over-riding the hostname in the dnsmasq configuration, ie with dhcp-host. In that case the client-provided name is ignored, including for the purposes of dhcp-name-match. (This may be a bug, but it is also an explanation.) Simon On 22/10/2019 15:43, James Feeney wrote: > dnsmasq 2.80-4 > Arch Linux > > /etc/dnsmasq.conf > dhcp-name-match=set:printer,NPI* > > $ journalctl -ab > ... > client provides name: NPI8C840E.prime > ... > tags: known, enp4s0 > > Uhm - so, did I miss something? Or, is "dhcp-name-match=" broken? > Why is the tag "printer" not been appended to the list of tags? > > The similar "dhcp-vendorclass=" seems to work as expected. > Is "dhcp-name-match=" different in some way? > > > Thanks > James > > ___ > 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] dhcp-name-match ?
dnsmasq 2.80-4 Arch Linux /etc/dnsmasq.conf dhcp-name-match=set:printer,NPI* $ journalctl -ab ... client provides name: NPI8C840E.prime ... tags: known, enp4s0 Uhm - so, did I miss something? Or, is "dhcp-name-match=" broken? Why is the tag "printer" not been appended to the list of tags? The similar "dhcp-vendorclass=" seems to work as expected. Is "dhcp-name-match=" different in some way? Thanks James ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
