[Dnsmasq-discuss] dhcp-name-match ?
Geert Stappers
stappers at stappers.nl
Sun Nov 10 09:40:42 GMT 2019
On Wed, Oct 30, 2019 at 09:32:14PM +0000, 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.
More information about the Dnsmasq-discuss
mailing list