[Dnsmasq-discuss] Do "proxy-DHCP" without PXE
Geert Stappers
stappers at stappers.nl
Tue Apr 29 04:39:51 UTC 2025
On Mon, Apr 28, 2025 at 07:52:00PM +0100, Simon Kelley wrote:
> On 28/04/2025 13:32, Steven Maddox wrote:
> > Hello,
> >
> > Sorry if what I'm about to ask is impossible, but I just really needed
> > to know one way or another.
> >
> > I find dnsmasq such a handy utility for all kinds of situations (so huge
> > thanks for creating it!)... one such situation was back when I was
> > working with ThinStation and I'd do something like this to quickly test
> > how a new build would boot on some PXE enabled machines...
> >
> > dnsmasq -d -i enp2s0 -F192.168.1.0,proxy --enable-tftp --tftp-
> > root="$(pwd)/build/boot-images/pxe" -p0 --log-dhcp --pxe-
> > service=x86PC,'Network Boot',boot/lpxelinux/lpxelinux
> >
> > Ultimately it's the "proxy-DHCP" that I'm focussing on here.
> >
> > Would it be possible to use this technique to add extra arbitrary DHCP
> > options to a reply instead? without touching the config of the
> > authoritative "other" DHCP server? e.g...
> >
> > dnsmasq -d -i enp2s0 -F192.168.1.0,proxy --enable-tftp --tftp-
> > root="$(pwd)" -p0 --log-dhcp -O 160,tftp://192.168.1.2
> >
> > This would be really handy in a scenario where you need to tell a bunch
> > of devices (e.g. Polycom phones) a new provisioning URL (in that example
> > option 160) on a temporary basis whilst you reboot/factory-reset them.
> > Especially when you're stuck using whatever existing DHCP server is on
> > the network with no ability (or great difficulty) to reconfigure it.
> >
> > But I have a feeling I'm going to be told that "proxy-DHCP" is, and can
> > only be, a PXE specific thing? if so, what is that?
> >
> The latest release, 2.91, includes a new option --dhcp-option-pxe,
> which may be of use here.
</screenshot>
DNSMASQ(8) System Manager's Manual DNSMASQ(8)
NAME
dnsmasq - A lightweight DHCP and caching DNS server.
SYNOPSIS
dnsmasq [OPTION]...
DESCRIPTION
dnsmasq is a lightweight DNS, TFTP, PXE, router advertisement and DHCP
server. It is intended to provide coupled DNS and DHCP service to a
LAN.
....
-O, --dhcp-option=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<en‐
terprise>,][vendor:[<vendor-class>],][<opt>|option:<opt-name>|op‐
tion6:<opt>|option6:<opt-name>],[<value>[,<value>]]
Send various extra options to DHCP clients. By default, dnsmasq
sends some standard options to DHCP clients, the netmask and
broadcast address are set to the same as the host running dns‐
masq, and the DNS server and default route are set to the ad‐
dress of the machine running dnsmasq. (Equivalent rules apply
for IPv6.) If the domain name option has been set, that is sent.
This configuration allows these defaults to be overridden, or
other options specified. The option to be sent may be given as a
decimal number or as option:<option-name>.
Option numbers are specified in RFC2132 and subsequent RFCs. The
set of option-names known by dnsmasq can be discovered by run‐
ning dnsmasq --help dhcp. For example, to set the default route
option to 192.168.4.4, use --dhcp-option=3,192.168.4.4 or
--dhcp-option=option:router,192.168.4.4 and to set the time-
server address to 192.168.0.4, use --dhcp-option=42,192.168.0.4
or --dhcp-option=option:ntp-server,192.168.0.4. The special ad‐
dress 0.0.0.0 means "the address of the system running dnsmasq".
An option without data is valid, and includes just the option
without data. (There is only one option with a zero length data
field currently defined for DHCPv4, 80:rapid commit, so this
feature is not very useful in practice). Options for which dns‐
masq normally provides default values can be ommitted by defin‐
ing the option with no data. These are netmask, broadcast,
router, DNS server, domainname and hostname. Thus, for DHCPv4
--dhcp-option = option:router will result in no router option
being sent, rather than the default of the host on which dnsmasq
is running. For DHCPv6, the same is true of the options DNS
server and refresh time.
Data types allowed are comma separated dotted-quad IPv4 ad‐
dresses, []-wrapped IPv6 addresses, a decimal number, colon-sep‐
arated hex digits and a text string. If the optional tags are
given then this option is only sent when all the tags are
matched.
Special processing is done on a text argument for option 119, to
conform with RFC 3397. Text or dotted-quad IP addresses as argu‐
ments to option 120 are handled as per RFC 3361. Dotted-quad IP
addresses which are followed by a slash and then a netmask size
are encoded as described in RFC 3442.
IPv6 options are specified using the option6: keyword, followed
by the option number or option name. The IPv6 option name space
is disjoint from the IPv4 option name space. IPv6 addresses in
options must be bracketed with square brackets, eg.
--dhcp-option=option6:ntp-server,[1234::56]. For IPv6, [::]
means "the global address of the machine running dnsmasq",
whilst [fd00::] is replaced with the ULA, if it exists, and
[fe80::] with the link-local address.
Be careful: data-type suitability for the option number sent is
not checked. It is quite possible to persuade dnsmasq to gener‐
ate illegal DHCP packets with injudicious use of this flag.
When the value is a decimal number, dnsmasq must determine how
large the data item is. It does this by examining the option
number and/or the value, but can be overridden by appending a
single letter flag as follows: b = one byte, s = two bytes, i =
four bytes. This is mainly useful with encapsulated vendor class
options (see below) where dnsmasq cannot determine data size
from the option number. Option data which consists solely of pe‐
riods and digits will be interpreted by dnsmasq as an IP ad‐
dress, and inserted into an option as such. To force a literal
string, use quotes. For instance when using option 66 to send a
literal IP address as TFTP server name, it is necessary to do
--dhcp-option=66,"1.2.3.4".
Encapsulated Vendor-class options may also be specified (IPv4
only) using --dhcp-option: for instance --dhcp-option=vendor:PX‐
EClient,1,0.0.0.0 sends the encapsulated vendor class-specific
option "mftp-address=0.0.0.0" to any client whose vendor-class
matches "PXEClient". The vendor-class matching is substring
based (see --dhcp-vendorclass for details). If a vendor-class
option (number 60) is sent by dnsmasq, then that is used for se‐
lecting encapsulated options in preference to any sent by the
client. It is possible to omit the vendorclass completely;
--dhcp-option=vendor:,1,0.0.0.0 in which case the encapsulated
option is always sent.
Options may be encapsulated (IPv4 only) within other options:
for instance --dhcp-option=encap:175, 190, iscsi-client0 will
send option 175, within which is the option 190. If multiple op‐
tions are given which are encapsulated with the same option num‐
ber then they will be correctly combined into one encapsulated
option. encap: and vendor: may not both be set in the same
--dhcp-option.
The final variant on encapsulated options is "Vendor-Identifying
Vendor Options" as specified by RFC3925. These are denoted like
this: --dhcp-option=vi-encap:2, 10, text The number in the vi-
encap: section is the IANA enterprise number used to identify
this option. This form of encapsulation is supported in IPv6.
The address 0.0.0.0 is not treated specially in encapsulated op‐
tions.
--dhcp-option-force=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-en‐
cap:<enterprise>,][vendor:[<vendor-class>],]<opt>,[<value>[,<value>]]
This works in exactly the same way as --dhcp-option except that
the option will always be sent, even if the client does not ask
for it in the parameter request list. This is sometimes needed,
for example when sending options to PXELinux.
--dhcp-option-pxe=[tag:<tag>,[tag:<tag>,]][encap:<opt>,][vi-encap:<en‐
terprise>,]<opt>,[<value>[,<value>]]
A variant of --dhcp-option which defines options only sent in
reply to PXE clients. In addition, such options are sent in re‐
ply to PXE clients when dnsmasq is acting as a PXE proxy, unlike
other options. A typical use-case is option 175, sent to iPXE.
</screenshot>
Now we wait on feedback from original poster.
More information about the Dnsmasq-discuss
mailing list