[Dnsmasq-discuss] Announce: dnsmasq-2.53 release candidate 1
simon at thekelleys.org.uk
Mon May 24 13:10:41 BST 2010
clemens fischer wrote:
> Simon Kelley wrote:
>> Now seems to be a good time to start the process of releasing
>> dnsmasq-2.53. There's no outstanding development work, and a fairly
>> fat list of changes since 2.52, back in January.
>> Therefore I've made a first release candidate, available at
>> As many people as can, please test this, The more people test, the
>> lower the chance I get to wear a brown-paper bag after it's released :-)
> As far as I came to know your work there might be no opportunity to see
> you with that brown paper bag, but if you feel compelled to wear one,
> please post a snapshot at the usual places 8-)
> The 53rc1 is currently running here without any problems! I'm most
> grateful to you for the "logging-to-stderr" option, the rebind-domain-ok
> and rebind-localhost-ok, all the other helpful hints and your
> The changelog:
>> version 2.53
>> Rationalised the DHCP tag system. Every configuration item
>> which can set a tag does so by adding "set:<tag>" and
>> every configuration item which is conditional on a tag is
>> made so by "tag:<tag>". The NOT operator changes to '!',
>> which is a bit more intuitive too. Dhcp-host directives
>> can set more than one tag now. The old '#' NOT,
>> "net:" prefix and no-prefixes are still honoured, so
>> no existing config file needs to be changed, but
>> the documentation and new-style config files should be
>> much less confusing.
> This is good stuff. One day the provided example configuration needs
> rearrangement in that dns-, dhcp- and tftp-options have no order there.
> I propose putting logging and dns options first, then dhcp ranges with
> citation of the "NOTES" section from the manual regarding the tag system
> first, then examples concerning window$ and mac boxes and thereafter
> tftp options, again with examples for the other two operating systems.
This is a good suggestion. It need combining with another suggestion:
make two example files, one with common stuff for use by newbies who
need to do simple things, and a second which exhaustively covers every
>> If we send vendor-class encapsulated options based on the
>> vendor-class supplied by the client, and no explicit
>> vendor-class option is given, echo back the vendor-class
>> from the client.
> How does this work? Does this info get echoed to the client or the log?
To the client (it's probably logged too, but the point is that the
client has to know the vendor class to know if the vendor-encapsulated
options are valid. In this case the client should know the vendor class
because it supplied it in the request, but some clients actually need
it in the reply too.
>> Added interface:<iface name> part to dhcp-range. The
>> semantics of this are very odd at first sight, but it
>> allows a single line of the form
>> to be added to dnsmasq configuration which then supplies
>> DHCP and DNS services to that interface, without affecting
>> what services are supplied to other interfaces and
>> irrespective of the existance or lack of
>> lines elsewhere in the dnsmasq configuration. The idea is
>> that such a line can be added automatically by libvirt
>> or equivalent systems, without disturbing any manual
> Very useful! I can use this immediately myself. How is this applied to
> DNS services? I want to run dnsmasq mainly for dhcp with dns served by
> bind-9, because I'm testing IPv6 with DNSSEC, but I can imagine
> production dhcp clients using some other forwarder.
Like it says, dhcp-range=interface:<interface> will supply DNS service
listening on the address of <interface>. You can disbale dnsmasq's DNS
service completely with port=0.
More information about the Dnsmasq-discuss