DNSMASQ(8)



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.

       Dnsmasq  accepts  DNS queries and either answers them from a small, lo-
       cal, cache or forwards them to a real, recursive, DNS server. It  loads
       the  contents of /etc/hosts so that local hostnames which do not appear
       in the global DNS can be resolved and also answers DNS queries for DHCP
       configured  hosts.  It can also act as the authoritative DNS server for
       one or more domains, allowing local names to appear in the global  DNS.
       It can be configured to do DNSSEC validation.

       The  dnsmasq DHCP server supports static address assignments and multi-
       ple networks. It automatically sends a sensible default set of DHCP op-
       tions,  and  can be configured to send any desired set of DHCP options,
       including vendor-encapsulated options. It includes a secure, read-only,
       TFTP  server  to  allow  net/PXE  boot  of DHCP hosts and also supports
       BOOTP. The PXE support is full featured,  and  includes  a  proxy  mode
       which  supplies  PXE information to clients whilst DHCP address alloca-
       tion is done by another server.

       The dnsmasq DHCPv6 server provides the same  set  of  features  as  the
       DHCPv4 server, and in addition, it includes router advertisements and a
       neat feature which allows naming  for  clients  which  use  DHCPv4  and
       stateless  autoconfiguration only for IPv6 configuration. There is sup-
       port for doing address allocation (both DHCPv6  and  RA)  from  subnets
       which are dynamically delegated via DHCPv6 prefix delegation.

       Dnsmasq  is  coded with small embedded systems in mind. It aims for the
       smallest possible memory footprint compatible with the supported  func-
       tions,   and  allows unneeded functions to be omitted from the compiled
       binary.

OPTIONS
       Note that in general missing parameters  are  allowed  and  switch  off
       functions,  for  instance  "--pid-file" disables writing a PID file. On
       BSD, unless the GNU getopt library is linked, the long form of the  op-
       tions  does not work on the command line; it is still recognised in the
       configuration file.

       --test Read and syntax check configuration file(s). Exit with code 0 if
              all  is  OK,  or a non-zero code otherwise. Do not start up dns-
              masq.

       -w, --help
              Display all command-line  options.   --help  dhcp  will  display
              known  DHCPv4  configuration options, and --help dhcp6 will dis-
              play DHCPv6 options.

       -h, --no-hosts
              Don't read the hostnames in /etc/hosts.

       -H, --addn-hosts=<file>
              Additional hosts file.  Read  the  specified  file  as  well  as
              /etc/hosts.  If  --no-hosts  is  given,  read only the specified
              file. This option may be repeated for more than  one  additional
              hosts  file.  If  a  directory is given, then read all the files
              contained in that directory.

       --hostsdir=<path>
              Read all the hosts files contained  in  the  directory.  New  or
              changed  files  are  read automatically. See --dhcp-hostsdir for
              details.

       -E, --expand-hosts
              Add the domain to simple names (without a period) in  /etc/hosts
              in  the  same way as for DHCP-derived names. Note that this does
              not apply to domain names in cnames, PTR  records,  TXT  records
              etc.

       -T, --local-ttl=<time>
              When  replying with information from /etc/hosts or configuration
              or the DHCP leases file dnsmasq by default sets the time-to-live
              field  to  zero,  meaning  that  the requester should not itself
              cache the information. This is the correct thing to do in almost
              all  situations.  This option allows a time-to-live (in seconds)
              to be given for these replies. This will reduce the load on  the
              server  at  the  expense  of clients using stale data under some
              circumstances.

       --dhcp-ttl=<time>
              As for --local-ttl, but affects only  replies  with  information
              from DHCP leases. If both are given, --dhcp-ttl applies for DHCP
              information, and --local-ttl for others. Setting  this  to  zero
              eliminates the effect of --local-ttl for DHCP.

       --neg-ttl=<time>
              Negative replies from upstream servers normally contain time-to-
              live information in SOA records which dnsmasq uses for  caching.
              If the replies from upstream servers omit this information, dns-
              masq does not cache the reply. This option gives a default value
              for  time-to-live (in seconds) which dnsmasq uses to cache nega-
              tive replies even in the absence of an SOA record.

       --max-ttl=<time>
              Set a maximum TTL value that will be handed out to clients.  The
              specified  maximum  TTL  will be given to clients instead of the
              true TTL value if it is lower. The true  TTL  value  is  however
              kept in the cache to avoid flooding the upstream DNS servers.

       --max-cache-ttl=<time>
              Set a maximum TTL value for entries in the cache.

       --min-cache-ttl=<time>
              Extend  short  TTL  values  to the time given when caching them.
              Note that artificially extending TTL values is in general a  bad
              idea, do not do it unless you have a good reason, and understand
              what you are doing.  Dnsmasq limits the value of this option  to
              one hour, unless recompiled.

       --auth-ttl=<time>
              Set  the  TTL  value  returned in answers from the authoritative
              server.

       -k, --keep-in-foreground
              Do not go into the background at startup but  otherwise  run  as
              normal.  This is intended for use when dnsmasq is run under dae-
              montools or launchd.

       -d, --no-daemon
              Debug mode: don't fork to the  background,  don't  write  a  pid
              file,  don't  change  user id, generate a complete cache dump on
              receipt on SIGUSR1, log to stderr as well as syslog, don't  fork
              new  processes  to  handle TCP queries. Note that this option is
              for use in debugging only, to stop dnsmasq daemonising  in  pro-
              duction, use --keep-in-foreground.

       -q, --log-queries
              Log the results of DNS queries handled by dnsmasq. Enable a full
              cache dump on receipt of SIGUSR1. If  the  argument  "extra"  is
              supplied, ie --log-queries=extra then the log has extra informa-
              tion at the start of each line.  This consists of a serial  num-
              ber  which  ties together the log lines associated with an indi-
              vidual query, and the IP address of the requestor.

       -8, --log-facility=<facility>
              Set the facility to which dnsmasq will send syslog entries, this
              defaults  to  DAEMON, and to LOCAL0 when debug mode is in opera-
              tion. If the facility given contains at least one '/' character,
              it  is  taken  to  be  a filename, and dnsmasq logs to the given
              file, instead of syslog. If the facility  is  '-'  then  dnsmasq
              logs to stderr.  (Errors whilst reading configuration will still
              go to syslog, but all output from a successful startup, and  all
              output  whilst  running,  will go exclusively to the file.) When
              logging to a file, dnsmasq will close and reopen the  file  when
              it  receives  SIGUSR2.  This  allows  the log file to be rotated
              without stopping dnsmasq.

       --log-async[=<lines>]
              Enable asynchronous logging and optionally set the limit on  the
              number  of lines which will be queued by dnsmasq when writing to
              the syslog is slow.  Dnsmasq can log asynchronously: this allows
              it  to continue functioning without being blocked by syslog, and
              allows syslog to use dnsmasq for  DNS  queries  without  risking
              deadlock.   If the queue of log-lines becomes full, dnsmasq will
              log the overflow, and the number of messages  lost. The  default
              queue  length  is  5,  a sane value would be 5-25, and a maximum
              limit of 100 is imposed.

       -x, --pid-file=<path>
              Specify an alternate path for dnsmasq to record  its  process-id
              in. Normally /var/run/dnsmasq.pid.

       -u, --user=<username>
              Specify  the  userid to which dnsmasq will change after startup.
              Dnsmasq must normally be started as root, but it will drop  root
              privileges  after  startup  by changing id to another user. Nor-
              mally this user is "nobody" but that  can  be  over-ridden  with
              this switch.

       -g, --group=<groupname>
              Specify  the  group  which  dnsmasq  will run as. The default is
              "dip",  if  available,  to  facilitate  access  to  /etc/ppp/re-
              solv.conf which is not normally world readable.

       -v, --version
              Print the version number.

       -p, --port=<port>
              Listen  on <port> instead of the standard DNS port (53). Setting
              this to zero completely disables DNS function, leaving only DHCP
              and/or TFTP.

       -P, --edns-packet-max=<size>
              Specify  the largest EDNS.0 UDP packet which is supported by the
              DNS forwarder. Defaults to 4096,  which  is  the  RFC5625-recom-
              mended size.

       -Q, --query-port=<query_port>
              Send outbound DNS queries from, and listen for their replies on,
              the specific UDP  port  <query_port>  instead  of  using  random
              ports. NOTE that using this option will make dnsmasq less secure
              against DNS spoofing attacks but it may be faster and  use  less
              resources.  Setting this option to zero makes dnsmasq use a sin-
              gle port allocated to it by the OS: this was the default  behav-
              iour in versions prior to 2.43.

       --min-port=<port>
              Do not use ports less than that given as source for outbound DNS
              queries. Dnsmasq picks  random  ports  as  source  for  outbound
              queries:  when  this option is given, the ports used will always
              to larger than that specified. Useful for systems  behind  fire-
              walls. If not specified, defaults to 1024.

       --max-port=<port>
              Use  ports  lower  than  that  given  as source for outbound DNS
              queries.  Dnsmasq picks random  ports  as  source  for  outbound
              queries:  when  this option is given, the ports used will always
              be lower than that specified. Useful for  systems  behind  fire-
              walls.

       -i, --interface=<interface name>
              Listen only on the specified interface(s). Dnsmasq automatically
              adds the loopback (local) interface to the list of interfaces to
              use  when  the --interface option  is used. If no --interface or
              --listen-address options are given dnsmasq listens on all avail-
              able  interfaces except any given in --except-interface options.
              On Linux, when --bind-interfaces or --bind-dynamic  are  in  ef-
              fect,  IP  alias  interface  labels  (eg  "eth1:0") are checked,
              rather than interface names. In the degenerate case when an  in-
              terface has one address, this amounts to the same thing but when
              an interface has multiple addresses it allows control over which
              of  those addresses are accepted.  The same effect is achievable
              in default mode by using --listen-address.  A  simple  wildcard,
              consisting  of  a  trailing  '*', can be used in --interface and
              --except-interface options.

       -I, --except-interface=<interface name>
              Do not listen on the specified interface. Note that the order of
              --listen-address --interface and --except-interface options does
              not matter and that --except-interface options  always  override
              the others. The comments about interface labels for --listen-ad-
              dress apply here.

       --auth-server=<domain>,[<interface>|<ip-address>...]
              Enable DNS authoritative mode for queries arriving at an  inter-
              face  or address. Note that the interface or address need not be
              mentioned in --interface or --listen-address configuration,  in-
              deed  --auth-server  will override these and provide a different
              DNS service on the specified  interface.  The  <domain>  is  the
              "glue  record".  It  should  resolve  in  the global DNS to an A
              and/or AAAA record which points to the address dnsmasq  is  lis-
              tening  on.  When an interface is specified, it may be qualified
              with "/4" or "/6" to specify only the IPv4 or IPv6 addresses as-
              sociated  with  the  interface.  Since any defined authoritative
              zones are also available as part of the normal recusive DNS ser-
              vice  supplied  by dnsmasq, it can make sense to have an --auth-
              server declaration with no interfaces  or  address,  but  simply
              specifying the primary external nameserver.

       --local-service
              Accept  DNS  queries only from hosts whose address is on a local
              subnet, ie a subnet for which an interface exists on the server.
              This  option  only has effect if there are no --interface, --ex-
              cept-interface, --listen-address or --auth-server options. It is
              intended to be set as a default on installation, to allow uncon-
              figured installations to be useful but also safe from being used
              for DNS amplification attacks.

       -2, --no-dhcp-interface=<interface name>
              Do  not  provide DHCP or TFTP on the specified interface, but do
              provide DNS service.

       -a, --listen-address=<ipaddr>
              Listen on the given IP address(es). Both --interface and  --lis-
              ten-address  options may be given, in which case the set of both
              interfaces and addresses is used. Note that  if  no  --interface
              option is given, but --listen-address is, dnsmasq will not auto-
              matically listen on the loopback interface. To achieve this, its
              IP  address,  127.0.0.1, must be explicitly given as a --listen-
              address option.

       -z, --bind-interfaces
              On systems which support it, dnsmasq binds the wildcard address,
              even  when it is listening on only some interfaces. It then dis-
              cards requests that it shouldn't reply to. This has  the  advan-
              tage  of working even when interfaces come and go and change ad-
              dress. This option forces dnsmasq to really bind only the inter-
              faces  it is listening on. About the only time when this is use-
              ful is when running another nameserver (or another  instance  of
              dnsmasq)  on  the same machine. Setting this option also enables
              multiple instances of dnsmasq which provide DHCP service to  run
              in the same machine.

       --bind-dynamic
              Enable  a  network  mode which is a hybrid between --bind-inter-
              faces and the default. Dnsmasq binds the address  of  individual
              interfaces,  allowing multiple dnsmasq instances, but if new in-
              terfaces or addresses appear, it automatically listens on  those
              (subject to any access-control configuration). This makes dynam-
              ically created interfaces work in the same way as  the  default.
              Implementing  this  option requires non-standard networking APIs
              and it is only available under  Linux.  On  other  platforms  it
              falls-back to --bind-interfaces mode.

       -y, --localise-queries
              Return  answers  to DNS queries from /etc/hosts and --interface-
              name which depend on the interface over which the query was  re-
              ceived.  If a name has more than one address associated with it,
              and at least one of those addresses is on the same subnet as the
              interface  to which the query was sent, then return only the ad-
              dress(es) on that subnet. This allows for a server  to have mul-
              tiple  addresses  in /etc/hosts corresponding to each of its in-
              terfaces, and hosts will get the correct address based on  which
              network they are attached to. Currently this facility is limited
              to IPv4.

       -b, --bogus-priv
              Bogus private reverse lookups. All reverse lookups  for  private
              IP   ranges  (ie  192.168.x.x,  etc)  which  are  not  found  in
              /etc/hosts or the DHCP leases file are answered  with  "no  such
              domain"  rather  than  being forwarded upstream. The set of pre-
              fixes affected is the list given in RFC6303, for IPv4 and IPv6.

       -V, --alias=[<old-ip>]|[<start-ip>-<end-ip>],<new-ip>[,<mask>]
              Modify IPv4 addresses returned from upstream nameservers; old-ip
              is  replaced  by  new-ip. If the optional mask is given then any
              address which matches the masked old-ip will be re-written.  So,
              for   instance  --alias=1.2.3.0,6.7.8.0,255.255.255.0  will  map
              1.2.3.56 to 6.7.8.56 and 1.2.3.67  to  6.7.8.67.  This  is  what
              Cisco  PIX  routers call "DNS doctoring". If the old IP is given
              as range, then only addresses in the range, rather than a  whole
              subnet,              are              re-written.             So
              --alias=192.168.0.10-192.168.0.40,10.0.0.0,255.255.255.0    maps
              192.168.0.10->192.168.0.40 to 10.0.0.10->10.0.0.40

       -B, --bogus-nxdomain=<ipaddr>
              Transform  replies  which  contain the IP address given into "No
              such domain" replies. This is intended to counteract  a  devious
              move  made  by  Verisign in September 2003 when they started re-
              turning the address of an advertising web page  in  response  to
              queries  for unregistered names, instead of the correct NXDOMAIN
              response. This option tells dnsmasq to fake the correct response
              when  it sees this behaviour. As at Sept 2003 the IP address be-
              ing returned by Verisign is 64.94.110.11

       --ignore-address=<ipaddr>
              Ignore replies to A-record queries which include  the  specified
              address.   No  error  is  generated, dnsmasq simply continues to
              listen for another reply.  This is  useful  to  defeat  blocking
              strategies  which rely on quickly supplying a forged answer to a
              DNS request for certain domain, before the  correct  answer  can
              arrive.

       -f, --filterwin2k
              Later versions of windows make periodic DNS requests which don't
              get sensible answers from the public DNS and can cause  problems
              by triggering dial-on-demand links. This flag turns on an option
              to filter such requests. The requests blocked are for records of
              types SOA and SRV, and type ANY where the requested name has un-
              derscores, to catch LDAP requests.

       -r, --resolv-file=<file>
              Read the IP addresses of the upstream nameservers  from  <file>,
              instead of /etc/resolv.conf. For the format of this file see re-
              solv.conf(5).  The only lines relevant to dnsmasq are nameserver
              ones.  Dnsmasq  can  be  told  to poll more than one resolv.conf
              file, the first file name  specified overrides the default, sub-
              sequent ones add to the list. This is only allowed when polling;
              the file with the currently latest modification time is the  one
              used.

       -R, --no-resolv
              Don't  read /etc/resolv.conf. Get upstream servers only from the
              command line or the dnsmasq configuration file.

       -1, --enable-dbus[=<service-name>]
              Allow dnsmasq configuration to be updated via DBus method calls.
              The  configuration  which can be changed is upstream DNS servers
              (and corresponding domains) and cache clear. Requires that  dns-
              masq  has  been  built with DBus support. If the service name is
              given, dnsmasq provides service at that name,  rather  than  the
              default which is uk.org.thekelleys.dnsmasq

       --enable-ubus[=<service-name>]
              Enable  dnsmasq  UBus interface. It sends notifications via UBus
              on DHCPACK and DHCPRELEASE events. Furthermore  it  offers  met-
              rics.   Requires  that dnsmasq has been built with UBus support.
              If the service name is given, dnsmasq provides service  at  that
              namespace, rather than the default which is dnsmasq

       -o, --strict-order
              By  default,  dnsmasq  will  send queries to any of the upstream
              servers it knows about and tries  to  favour  servers  that  are
              known  to  be  up.  Setting this flag forces dnsmasq to try each
              query with each server strictly in  the  order  they  appear  in
              /etc/resolv.conf

       --all-servers
              By  default,  when  dnsmasq  has  more  than one upstream server
              available, it will send queries to just one server. Setting this
              flag  forces  dnsmasq  to  send  all  queries  to  all available
              servers. The reply from the server which answers first  will  be
              returned to the original requester.

       --dns-loop-detect
              Enable  code  to  detect  DNS forwarding loops; ie the situation
              where a query sent to one of the upstream server eventually  re-
              turns  as a new query to the dnsmasq instance. The process works
              by generating TXT queries of the  form  <hex>.test  and  sending
              them to each upstream server. The hex is a UID which encodes the
              instance of dnsmasq sending the query and the upstream server to
              which it was sent. If the query returns to the server which sent
              it, then the upstream server through which it was sent  is  dis-
              abled  and  this  event is logged. Each time the set of upstream
              servers changes, the test is re-run on all  of  them,  including
              ones which were previously disabled.

       --stop-dns-rebind
              Reject  (and  log) addresses from upstream nameservers which are
              in the private ranges. This blocks an attack where a browser be-
              hind  a firewall is used to probe machines on the local network.
              For IPv6, the private range covers the IPv4-mapped addresses  in
              private  space plus all link-local (LL) and site-local (ULA) ad-
              dresses.

       --rebind-localhost-ok
              Exempt 127.0.0.0/8 and ::1 from rebinding checks.  This  address
              range is returned by realtime black hole servers, so blocking it
              may disable these services.

       --rebind-domain-ok=[<domain>]|[[/<domain>/[<domain>/]
              Do not detect and block dns-rebind on queries to these  domains.
              The  argument may be either a single domain, or multiple domains
              surrounded by '/', like the --server syntax,  eg.   --rebind-do-
              main-ok=/domain1/domain2/domain3/

       -n, --no-poll
              Don't poll /etc/resolv.conf for changes.

       --clear-on-reload
              Whenever /etc/resolv.conf is re-read or the upstream servers are
              set via DBus, clear the DNS cache.   This  is  useful  when  new
              nameservers may have different data than that held in cache.

       -D, --domain-needed
              Tells  dnsmasq  to  never  forward  A  or AAAA queries for plain
              names, without dots or domain parts, to upstream nameservers. If
              the name is not known from /etc/hosts or DHCP then a "not found"
              answer is returned.

       -S,                 --local,                 --server=[/[<domain>]/[do-
       main/]][<ipaddr>[#<port>][@<source-ip>|<interface>[#<port>]]
              Specify  IP  address  of upstream servers directly. Setting this
              flag does not suppress reading of /etc/resolv.conf, use --no-re-
              solv to do that. If one or more optional domains are given, that
              server is used only for those domains and they are queried  only
              using  the  specified server. This is intended for private name-
              servers: if you have a nameserver on your  network  which  deals
              with   names   of  the  form  xxx.internal.thekelleys.org.uk  at
              192.168.1.1 then  giving   the  flag  --server=/internal.thekel-
              leys.org.uk/192.168.1.1  will  send all queries for internal ma-
              chines to that  nameserver,  everything  else  will  go  to  the
              servers in /etc/resolv.conf. DNSSEC validation is turned off for
              such private nameservers, UNLESS a --trust-anchor  is  specified
              for  the  domain  in question. An empty domain specification, //
              has the special meaning of "unqualified  names  only"  ie  names
              without  any  dots in them. A non-standard port may be specified
              as part of the IP address using a # character.   More  than  one
              --server  flag  is allowed, with repeated domain or ipaddr parts
              as required.

              More specific domains take precedence  over  less  specific  do-
              mains,              so:             --server=/google.com/1.2.3.4
              --server=/www.google.com/2.3.4.5   will   send    queries    for
              *.google.com  to  1.2.3.4, except *www.google.com, which will go
              to 2.3.4.5

              The  special  server  address  '#'  means,  "use  the   standard
              servers",             so            --server=/google.com/1.2.3.4
              --server=/www.google.com/# will send queries for *.google.com to
              1.2.3.4,  except  *www.google.com  which  will  be  forwarded as
              usual.

              Also permitted is a -S flag which gives a domain but no  IP  ad-
              dress;  this tells dnsmasq that a domain is local and it may an-
              swer queries from /etc/hosts or DHCP but  should  never  forward
              queries  on  that  domain to any upstream servers.  --local is a
              synonym for --server to make configuration files clearer in this
              case.

              IPv6   addresses   may   include   an  %interface  scope-id,  eg
              fe80::202:a412:4512:7bbf%eth0.

              The optional string after the @ character tells dnsmasq  how  to
              set  the source of the queries to this nameserver. It can either
              be an ip-address, an interface  name  or  both.  The  ip-address
              should belong to the machine on which dnsmasq is running, other-
              wise this server line will be logged and then ignored. If an in-
              terface name is given, then queries to the server will be forced
              via that interface; if an ip-address is given  then  the  source
              address  of the queries will be set to that address; and if both
              are given then a combination of ip-address  and  interface  name
              will  be  used  to steer requests to the server.  The query-port
              flag is ignored for any servers  which  have  a  source  address
              specified  but the port may be specified directly as part of the
              source address. Forcing queries to an interface  is  not  imple-
              mented on all platforms supported by dnsmasq.

       --rev-server=<ip-address>/<prefix-len>[,<ipaddr>][#<port>][@<source-
       ip>|<interface>[#<port>]]
              This is functionally the same as  --server,  but  provides  some
              syntactic  sugar to make specifying address-to-name queries eas-
              ier. For example --rev-server=1.2.3.0/24,192.168.0.1 is  exactly
              equivalent to --server=/3.2.1.in-addr.arpa/192.168.0.1

       -A, --address=/<domain>[/<domain>...]/[<ipaddr>]
              Specify  an  IP  address to return for any host in the given do-
              mains.  Queries in the domains are never  forwarded  and  always
              replied  to  with  the specified IP address which may be IPv4 or
              IPv6. To give both IPv4 and IPv6 addresses for a domain, use re-
              peated  --address flags.  To include multiple IP addresses for a
              single  query,  use  --addn-hosts=<path>  instead.   Note   that
              /etc/hosts and DHCP leases override this for individual names. A
              common use of this is to redirect the entire doubleclick.net do-
              main  to some friendly local web server to avoid banner ads. The
              domain specification works in the same was as for --server, with
              the  additional facility that /#/ matches any domain. Thus --ad-
              dress=/#/1.2.3.4 will always return 1.2.3.4 for  any  query  not
              answered  from  /etc/hosts  or  DHCP and not sent to an upstream
              nameserver  by  a  more  specific  --server  directive.  As  for
              --server, one or more domains with no address returns a no-such-
              domain  answer,  so  --address=/example.com/  is  equivalent  to
              --server=/example.com/  and returns NXDOMAIN for example.com and
              all its subdomains. An address specified as  '#'  translates  to
              the  NULL  address  of  0.0.0.0 and its IPv6 equivalent of :: so
              --address=/example.com/# will return NULL  addresses  for  exam-
              ple.com  and  its subdomains. This is partly syntactic sugar for
              --address=/example.com/0.0.0.0 and --address=/example.com/:: but
              is  also more efficient than including both as separate configu-
              ration lines. Note that NULL addresses normally work in the same
              way  as localhost, so beware that clients looking up these names
              are likely to end up talking to themselves.

       --ipset=/<domain>[/<domain>...]/<ipset>[,<ipset>...]
              Places the resolved IP addresses of queries for one or more  do-
              mains  in  the  specified Netfilter IP set. If multiple setnames
              are given, then the addresses are placed in each of  them,  sub-
              ject  to  the limitations of an IP set (IPv4 addresses cannot be
              stored in an IPv6 IP set and vice versa).   Domains  and  subdo-
              mains  are  matched in the same way as --address.  These IP sets
              must already exist. See ipset(8) for more details.

       -m, --mx-host=<mx name>[[,<hostname>],<preference>]
              Return an MX record named <mx name> pointing to the given  host-
              name (if given), or the host specified in the --mx-target switch
              or, if that switch is not given, the host on  which  dnsmasq  is
              running.  The  default is useful for directing mail from systems
              on a LAN to a central server. The preference value is  optional,
              and  defaults  to 1 if not given. More than one MX record may be
              given for a host.

       -t, --mx-target=<hostname>
              Specify the default target for the MX record  returned  by  dns-
              masq.  See  --mx-host.   If  --mx-target is given, but not --mx-
              host, then dnsmasq returns a MX record containing the MX  target
              for  MX  queries on the hostname of the machine on which dnsmasq
              is running.

       -e, --selfmx
              Return an MX record pointing to itself for each  local  machine.
              Local machines are those in /etc/hosts or with DHCP leases.

       -L, --localmx
              Return  an  MX  record pointing to the host given by --mx-target
              (or the machine on which dnsmasq is running) for each local  ma-
              chine.  Local  machines  are  those  in  /etc/hosts or with DHCP
              leases.

       -W, --srv-host=<_service>.<_prot>.[<domain>],[<target>[,<port>[,<prior-
       ity>[,<weight>]]]]
              Return  a  SRV  DNS record. See RFC2782 for details. If not sup-
              plied, the domain defaults to that given by --domain.   The  de-
              fault  for  the target domain is empty, and the default for port
              is one and the defaults for weight and  priority  are  zero.  Be
              careful  if  transposing  data  from  BIND zone files: the port,
              weight and priority numbers are in a different order. More  than
              one  SRV  record for a given service/domain is allowed, all that
              match are returned.

       --host-record=<name>[,<name>....],[<IPv4-address>],[<IPv6-ad-
       dress>][,<TTL>]
              Add  A,  AAAA  and PTR records to the DNS. This adds one or more
              names to the DNS  with  associated  IPv4  (A)  and  IPv6  (AAAA)
              records.  A  name  may appear in more than one --host-record and
              therefore be assigned more than one address. Only the first  ad-
              dress creates a PTR record linking the address to the name. This
              is the same rule as is used reading hosts-files.   --host-record
              options  are  considered to be read before host-files, so a name
              appearing there inhibits PTR-record creation if  it  appears  in
              hosts-file  also.  Unlike  hosts-files,  names are not expanded,
              even when --expand-hosts is in effect. Short and long names  may
              appear in the same --host-record, eg.  --host-record=laptop,lap-
              top.thekelleys.org,192.168.0.1,1234::100

              If the time-to-live is given, it overrides the default, which is
              zero  or the value of --local-ttl. The value is a positive inte-
              ger and gives the time-to-live in seconds.

       -Y, --txt-record=<name>[[,<text>],<text>]
              Return a TXT DNS record. The value of TXT record  is  a  set  of
              strings,  so   any  number may be included, delimited by commas;
              use quotes to put commas into a string. Note  that  the  maximum
              length  of a single string is 255 characters, longer strings are
              split into 255 character chunks.

       --ptr-record=<name>[,<target>]
              Return a PTR DNS record.

       --naptr-record=<name>,<order>,<preference>,<flags>,<service>,<reg-
       exp>[,<replacement>]
              Return an NAPTR DNS record, as specified in RFC3403.

       --caa-record=<name>,<flags>,<tag>,<value>
              Return a CAA DNS record, as specified in RFC6844.

       --cname=<cname>,[<cname>,]<target>[,<TTL>]
              Return  a  CNAME  record  which indicates that <cname> is really
              <target>. There is a significant limitation on  the  target;  it
              must  be  a  DNS  record which is known to dnsmasq and NOT a DNS
              record which comes from an upstream server. The  cname  must  be
              unique, but it is permissible to have more than one cname point-
              ing to the same target. Indeed it's possible to declare multiple
              cnames    to   a   target   in   a   single   line,   like   so:
              --cname=cname1,cname2,target

              If the time-to-live is given, it overrides the default, which is
              zero  or the value of --local-ttl. The value is a positive inte-
              ger and gives the time-to-live in seconds.

       --dns-rr=<name>,<RR-number>,[<hex data>]
              Return an arbitrary DNS Resource Record. The number is the  type
              of  the record (which is always in the C_IN class). The value of
              the record is given by the hex data, which may be  of  the  form
              01:23:45 or 01 23 45 or 012345 or any mixture of these.

       --interface-name=<name>,<interface>[/4|/6]
              Return  DNS records associating the name with the address(es) of
              the given interface. This flag specifies an A or AAAA record for
              the  given  name  in  the same way as an /etc/hosts line, except
              that the address is not constant, but taken from the  given  in-
              terface.  The interface may be followed by "/4" or "/6" to spec-
              ify that only IPv4 or IPv6 addresses of the interface should  be
              used.  If the interface is down, not configured or non-existent,
              an empty record is returned. The matching  PTR  record  is  also
              created,  mapping  the  interface address to the name. More than
              one name may be associated with an interface address by  repeat-
              ing  the  flag;  in that case the first instance is used for the
              reverse address-to-name mapping. Note that a name used in  --in-
              terface-name may not appear in /etc/hosts.

       --synth-domain=<domain>,<address range>[,<prefix>[*]]
              Create  artificial  A/AAAA and PTR records for an address range.
              The records either seqential numbers or the address, with  peri-
              ods (or colons for IPv6) replaced with dashes.

              An  examples should make this clearer. First sequential numbers.
              --synth-domain=thekelleys.org.uk,192.168.0.50,192.168.0.70,in-
              ternal-*  results  in the name internal-0.thekelleys.org.uk. re-
              turning  192.168.0.50,  internal-1.thekelleys.org.uk   returning
              192.168.0.51  and so on. (note the *) The same principle applies
              to IPv6 addresses (where the numbers may be very large). Reverse
              lookups from address to name behave as expected.

              Second,   --synth-domain=thekelleys.org.uk,192.168.0.0/24,inter-
              nal-   (no   *)   will   result   in   a   query   for    inter-
              nal-192-168-0-56.thekelleys.org.uk  returning 192.168.0.56 and a
              reverse query vice versa. The same applies to IPv6, but IPv6 ad-
              dresses  may  start  with '::' but DNS labels may not start with
              '-' so in this case if no prefix is configured a zero  is  added
              in front of the label. ::1 becomes 0--1.

              V4  mapped  IPv6  addresses,  which  have  a representation like
              ::ffff:1.2.3.4  are   handled   specially,   and   become   like
              0--ffff-1-2-3-4

              The  address  range can be of the form <ip address>,<ip address>
              or <ip address>/<netmask> in both forms of the option.

       --dumpfile=<path/to/file>
              Specify the location of a pcap-format file which dnsmasq uses to
              dump  copies  of  network packets for debugging purposes. If the
              file exists when dnsmasq starts, it is not deleted; new  packets
              are added to the end.

       --dumpmask=<mask>
              Specify  which types of packets should be added to the dumpfile.
              The argument should be the OR of the bitmasks for each  type  of
              packet to be dumped: it can be specified in hex by preceding the
              number with 0x in  the normal way. Each time a packet is written
              to  the  dumpfile, dnsmasq logs the packet sequence and the mask
              representing its type. The  current  types  are:  0x0001  -  DNS
              queries  from clients 0x0002 DNS replies to clients 0x0004 - DNS
              queries to upstream 0x0008 - DNS replies from upstream 0x0010  -
              queries  send upstream for DNSSEC validation 0x0020 - replies to
              queries for DNSSEC validation 0x0040 - replies to client queries
              which  fail  DNSSEC  validation  0x0080  replies  to queries for
              DNSSEC validation which fail validation.

       --add-mac[=base64|text]
              Add the MAC address of the requestor to DNS  queries  which  are
              forwarded upstream. This may be used to DNS filtering by the up-
              stream server. The MAC address can only  be  added  if  the  re-
              questor  is  on the same subnet as the dnsmasq server. Note that
              the mechanism used to achieve this (an EDNS0 option) is not  yet
              standardised,  so  this  should be considered experimental. Also
              note that exposing MAC addresses in this way may  have  security
              and  privacy  implications.  The warning about caching given for
              --add-subnet applies to --add-mac too. An  alternative  encoding
              of the MAC, as base64, is enabled by adding the "base64" parame-
              ter and a human-readable encoding of hex-and-colons  is  enabled
              by added the "text" parameter.

       --add-cpe-id=<string>
              Add  an  arbitrary  identifying  string to DNS queries which are
              forwarded upstream.

       --add-subnet[[=[<IPv4  address>/]<IPv4  prefix   length>][,[<IPv6   ad-
       dress>/]<IPv6 prefix length>]]
              Add  a subnet address to the DNS queries which are forwarded up-
              stream. If an address is specified in the flag, it will be used,
              otherwise, the address of the requestor will be used. The amount
              of the address forwarded depends on the prefix length parameter:
              32 (128 for IPv6) forwards the whole address, zero forwards none
              of it but still marks the request so that no upstream nameserver
              will  add client address information either. The default is zero
              for both IPv4 and IPv6. Note that upstream  nameservers  may  be
              configured  to  return  different results based on this informa-
              tion, but the dnsmasq cache does not take account. If a  dnsmasq
              instance  is  configured  such that different results may be en-
              countered, caching should be disabled.

              For example, --add-subnet=24,96 will add the /24 and /96 subnets
              of  the  requestor  for  IPv4 and IPv6 requestors, respectively.
              --add-subnet=1.2.3.4/24 will add 1.2.3.0/24 for IPv4  requestors
              and      ::/0      for      IPv6     requestors.      --add-sub-
              net=1.2.3.4/24,1.2.3.4/24 will add 1.2.3.0/24 for both IPv4  and
              IPv6 requestors.

       -c, --cache-size=<cachesize>
              Set  the size of dnsmasq's cache. The default is 150 names. Set-
              ting the cache size to zero disables caching. Note:  huge  cache
              size impacts performance.

       -N, --no-negcache
              Disable negative caching. Negative caching allows dnsmasq to re-
              member "no such domain" answers from  upstream  nameservers  and
              answer identical queries without forwarding them again.

       -0, --dns-forward-max=<queries>
              Set  the  maximum  number of concurrent DNS queries. The default
              value is 150, which should be fine for  most  setups.  The  only
              known  situation  where this needs to be increased is when using
              web-server log file resolvers, which can generate large  numbers
              of concurrent queries.

       --dnssec
              Validate  DNS replies and cache DNSSEC data. When forwarding DNS
              queries, dnsmasq requests the DNSSEC records needed to  validate
              the  replies.  The replies are validated and the result returned
              as the Authenticated Data bit in the DNS packet. In addition the
              DNSSEC  records  are  stored  in the cache, making validation by
              clients more efficient. Note that validation by clients  is  the
              most  secure  DNSSEC  mode, but for clients unable to do valida-
              tion, use of the AD bit set by dnsmasq is useful, provided  that
              the  network  between  the  dnsmasq  server  and  the  client is
              trusted. Dnsmasq must be compiled with HAVE_DNSSEC enabled,  and
              DNSSEC  trust anchors provided, see --trust-anchor.  Because the
              DNSSEC validation process uses the cache, it is not permitted to
              reduce  the cache size below the default when DNSSEC is enabled.
              The nameservers upstream of dnsmasq must be  DNSSEC-capable,  ie
              capable  of returning DNSSEC records with data. If they are not,
              then dnsmasq will not be able to determine the trusted status of
              answers and this means that DNS service will be entirely broken.

       --trust-anchor=[<class>],<domain>,<key-tag>,<algorithm>,<digest-
       type>,<digest>
              Provide DS records to act a trust anchors for DNSSEC validation.
              Typically  these will be the DS record(s) for Key Signing key(s)
              (KSK) of the root zone, but trust anchors  for  limited  domains
              are  also  possible.  The current root-zone trust anchors may be
              downloaded   from    https://data.iana.org/root-anchors/root-an-
              chors.xml

       --dnssec-check-unsigned[=no]
              As  a  default, dnsmasq checks that unsigned DNS replies are le-
              gitimate: this entails possible extra queries even for  the  ma-
              jority  of  DNS  zones  which are not, at the moment, signed. If
              --dnssec-check-unsigned=no appears in  the  configuration,  then
              such replies they are assumed to be valid and passed on (without
              the "authentic data" bit set, of course). This does not  protect
              against  an  attacker  forging  unsigned  replies for signed DNS
              zones, but it is fast.

              Versions of dnsmasq prior to 2.80 defaulted to not checking  un-
              signed  replies, and used --dnssec-check-unsigned to switch this
              on. Such configurations will continue to  work  as  before,  but
              those  which used the default of no checking will need to be al-
              tered to explicitly select no checking. The new default  is  be-
              cause  switching off checking for unsigned replies is inherently
              dangerous. Not only  does  it  open  the  possiblity  of  forged
              replies,  but  it allows everything to appear to be working even
              when the upstream namesevers do not support DNSSEC, and in  this
              case no DNSSEC validation at all is occurring.

       --dnssec-no-timecheck
              DNSSEC signatures are only valid for specified time windows, and
              should be rejected outside those windows. This generates an  in-
              teresting  chicken-and-egg problem for machines which don't have
              a hardware real time clock. For these machines to determine  the
              correct  time  typically  requires use of NTP and therefore DNS,
              but validating DNS requires that the  correct  time  is  already
              known. Setting this flag removes the time-window checks (but not
              other DNSSEC validation.) only until  the  dnsmasq  process  re-
              ceives  SIGINT.  The intention is that dnsmasq should be started
              with this flag when the platform determines that  reliable  time
              is  not  currently available. As soon as reliable time is estab-
              lished, a SIGINT should be sent to dnsmasq, which  enables  time
              checking,  and  purges  the  cache of DNS records which have not
              been thoroughly checked.

              Earlier versions of dnsmasq overloaded  SIGHUP  (which  re-reads
              much configuration) to also enable time validation.

              If  dnsmasq  is run in debug mode (--no-daemon flag) then SIGINT
              retains its usual meaning of terminating the dnsmasq process.

       --dnssec-timestamp=<path>
              Enables an alternative way of checking the validity of the  sys-
              tem  time  for DNSSEC (see --dnssec-no-timecheck). In this case,
              the system time is considered to be valid once it becomes  later
              than  the  timestamp  on the specified file. The file is created
              and its timestamp set automatically by dnsmasq. The file must be
              stored  on a persistent filesystem, so that it and its mtime are
              carried over system restarts. The timestamp file is created  af-
              ter  dnsmasq  has  dropped  root,  so  it  must be in a location
              writable by the unprivileged user that dnsmasq runs as.

       --proxy-dnssec
              Copy the DNSSEC Authenticated Data bit from upstream servers  to
              downstream  clients.   This  is an alternative to having dnsmasq
              validate DNSSEC, but it depends on the security of  the  network
              between  dnsmasq  and the upstream servers, and the trustworthi-
              ness of the upstream servers. Note that  caching  the  Authenti-
              cated  Data bit correctly in all cases is not technically possi-
              ble. If the AD bit is to be relied upon when using this  option,
              then  the cache should be disabled using --cache-size=0. In most
              cases, enabling DNSSEC validation within dnsmasq is a better op-
              tion. See --dnssec for details.

       --dnssec-debug
              Set  debugging  mode for the DNSSEC validation, set the Checking
              Disabled bit on upstream  queries,  and  don't  convert  replies
              which  do  not validate to responses with a return code of SERV-
              FAIL. Note that setting this may affect  DNS  behaviour  in  bad
              ways,  it  is not an extra-logging flag and should not be set in
              production.

       --auth-zone=<domain>[,<subnet>[/<prefix     length>][,<subnet>[/<prefix
       length>].....][,exclude:<subnet>[/<prefix length>]].....]
              Define  a  DNS  zone  for  which  dnsmasq  acts as authoritative
              server. Locally defined DNS records which are in the domain will
              be served. If subnet(s) are given, A and AAAA records must be in
              one of the specified subnets.

              As alternative to directly specifying the subnets, it's possible
              to  give the name of an interface, in which case the subnets im-
              plied by that interface's configured addresses and  netmask/pre-
              fix-length  are used; this is useful when using constructed DHCP
              ranges as the actual address is dynamic and not known when  con-
              figuring  dnsmasq.  The  interface  addresses may be confined to
              only IPv6 addresses using <interface>/6 or to  only  IPv4  using
              <interface>/4.  This is useful when an interface has dynamically
              determined global IPv6 addresses  which  should  appear  in  the
              zone,  but  RFC1918 IPv4 addresses which should not.  Interface-
              name and  address-literal  subnet  specifications  may  be  used
              freely in the same --auth-zone declaration.

              It's possible to exclude certain IP addresses from responses. It
              can be used, to make  sure  that  answers  contain  only  global
              routeable  IP  addresses (by excluding loopback, RFC1918 and ULA
              addresses).

              The subnet(s) are also used to define in-addr.arpa and  ip6.arpa
              domains  which are served for reverse-DNS queries. If not speci-
              fied, the prefix length defaults to 24 for IPv4 and 64 for IPv6.
              For  IPv4 subnets, the prefix length should be have the value 8,
              16 or 24 unless you are familiar with RFC 2317 and have arranged
              the in-addr.arpa delegation accordingly. Note that if no subnets
              are specified, then no reverse queries are answered.

       --auth-soa=<serial>[,<hostmaster>[,<refresh>[,<retry>[,<expiry>]]]]
              Specify fields in the SOA record associated  with  authoritative
              zones.  Note  that  this  is optional, all the values are set to
              sane defaults.

       --auth-sec-servers=<domain>[,<domain>[,<domain>...]]
              Specify any secondary servers for a zone for  which  dnsmasq  is
              authoritative. These servers must be configured to get zone data
              from dnsmasq by zone transfer, and answer queries for  the  same
              authoritative zones as dnsmasq.

       --auth-peer=<ip-address>[,<ip-address>[,<ip-address>...]]
              Specify  the addresses of secondary servers which are allowed to
              initiate zone transfer (AXFR) requests for zones for which  dns-
              masq  is  authoritative. If this option is not given but --auth-
              sec-servers is, then AXFR requests will  be  accepted  from  any
              secondary. Specifying --auth-peer without --auth-sec-servers en-
              ables zone transfer but does not advertise the secondary  in  NS
              records returned by dnsmasq.

       --conntrack
              Read  the  Linux  connection track mark associated with incoming
              DNS queries and set the same mark value on upstream traffic used
              to  answer  those queries. This allows traffic generated by dns-
              masq to be associated with the queries which  cause  it,  useful
              for bandwidth accounting and firewalling. Dnsmasq must have con-
              ntrack support compiled in and the kernel  must  have  conntrack
              support  included and configured. This option cannot be combined
              with --query-port.

       -F,            --dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-
       addr>[,<end-addr>|<mode>][,<netmask>[,<broadcast>]][,<lease time>]

       -F,            --dhcp-range=[tag:<tag>[,tag:<tag>],][set:<tag>,]<start-
       IPv6addr>[,<end-IPv6addr>|constructor:<interface>][,<mode>][,<prefix-
       len>][,<lease time>]

              Enable  the  DHCP  server.  Addresses will be given out from the
              range <start-addr> to <end-addr> and from statically defined ad-
              dresses  given  in  --dhcp-host  options.  If  the lease time is
              given, then leases will be given for that length  of  time.  The
              lease  time  is in seconds, or minutes (eg 45m) or hours (eg 1h)
              or "infinite". If not given, the default lease time is one hour.
              The  minimum  lease  time  is  two minutes. For IPv6 ranges, the
              lease time maybe "deprecated"; this sets the preferred  lifetime
              sent  in  a  DHCP  lease  or router advertisement to zero, which
              causes clients to use other addresses,  if  available,  for  new
              connections as a prelude to renumbering.

              This option may be repeated, with different addresses, to enable
              DHCP service to more than one network.  For  directly  connected
              networks  (ie, networks on which the machine running dnsmasq has
              an interface) the netmask is optional: dnsmasq will determine it
              from  the  interface  configuration.  For networks which receive
              DHCP service via a relay agent,  dnsmasq  cannot  determine  the
              netmask  itself,  so  it  should be specified, otherwise dnsmasq
              will have to guess, based on the class (A, B or C) of  the  net-
              work  address.  The  broadcast address is always optional. It is
              always allowed to have more than one --dhcp-range  in  a  single
              subnet.

              For IPv6, the parameters are slightly different: instead of net-
              mask and broadcast address, there is an optional  prefix  length
              which  must  be equal to or larger then the prefix length on the
              local interface. If not given, this defaults to 64.  Unlike  the
              IPv4  case,  the prefix length is not automatically derived from
              the interface configuration. The  minimum  size  of  the  prefix
              length is 64.

              IPv6  (only)  supports another type of range. In this, the start
              address and optional end address contain only the  network  part
              (ie ::1) and they are followed by constructor:<interface>.  This
              forms a template which describes how to create ranges, based  on
              the addresses assigned to the interface. For instance

              --dhcp-range=::1,::400,constructor:eth0

              will  look  for  addresses  on eth0 and then create a range from
              <network>::1 to <network>::400. If  the  interface  is  assigned
              more than one network, then the corresponding ranges will be au-
              tomatically created, and then  deprecated  and  finally  removed
              again  as the address is deprecated and then deleted. The inter-
              face name may have a final "*" wildcard. Note that just any  ad-
              dress  on  eth0 will not do: it must not be an autoconfigured or
              privacy address, or be deprecated.

              If a --dhcp-range is only being used for stateless  DHCP  and/or
              SLAAC, then the address can be simply ::

              --dhcp-range=::,constructor:eth0

              The  optional  set:<tag>  sets an alphanumeric label which marks
              this network so that DHCP options may be specified on a per-net-
              work  basis.   When it is prefixed with 'tag:' instead, then its
              meaning changes from setting a tag to matching it. Only one  tag
              may be set, but more than one tag may be matched.

              The optional <mode> keyword may be static which tells dnsmasq to
              enable DHCP for the network specified, but  not  to  dynamically
              allocate  IP  addresses:  only hosts which have static addresses
              given via --dhcp-host or from  /etc/ethers  will  be  served.  A
              static-only  subnet  with  address  all  zeros  may be used as a
              "catch-all" address to enable replies to all Information-request
              packets  on a subnet which is provided with stateless DHCPv6, ie
              --dhcp-range=::,static

              For IPv4, the <mode> may be proxy in  which  case  dnsmasq  will
              provide  proxy-DHCP  on  the specified subnet. (See --pxe-prompt
              and --pxe-service for details.)

              For IPv6, the mode may be some combination  of  ra-only,  slaac,
              ra-names, ra-stateless, ra-advrouter, off-link.

              ra-only tells dnsmasq to offer Router Advertisement only on this
              subnet, and not DHCP.

              slaac tells dnsmasq to offer Router Advertisement on this subnet
              and  to  set  the A bit in the router advertisement, so that the
              client will use SLAAC addresses. When used with a DHCP range  or
              static  DHCP  address  this  results in the client having both a
              DHCP-assigned and a SLAAC address.

              ra-stateless sends router advertisements with the O and  A  bits
              set,  and provides a stateless DHCP service. The client will use
              a SLAAC address, and use DHCP for other  configuration  informa-
              tion.

              ra-names  enables  a  mode  which  gives DNS names to dual-stack
              hosts which do SLAAC for IPv6.  Dnsmasq  uses  the  host's  IPv4
              lease  to  derive  the name, network segment and MAC address and
              assumes that the host will also have an IPv6 address  calculated
              using  the SLAAC algorithm, on the same network segment. The ad-
              dress is pinged, and if a reply is received, an AAAA  record  is
              added  to  the DNS for this IPv6 address. Note that this is only
              happens for directly-connected networks, (not one doing DHCP via
              a  relay) and it will not work if a host is using privacy exten-
              sions.  ra-names can be combined  with ra-stateless and slaac.

              ra-advrouter enables a mode where router address(es) rather than
              prefix(es)  are  included  in  the  advertisements.  This is de-
              scribed in RFC-3775 section 7.2 and is used in mobile  IPv6.  In
              this  mode the interval option is also included, as described in
              RFC-3775 section 7.3.

              off-link tells dnsmasq to advertise the prefix without  the  on-
              link (aka L) bit set.

       -G,                                                             --dhcp-
       host=[<hwaddr>][,id:<client_id>|*][,set:<tag>][tag:<tag>][,<ipaddr>][,<host-
       name>][,<lease_time>][,ignore]
              Specify  per  host parameters for the DHCP server. This allows a
              machine with a particular hardware address to  be  always  allo-
              cated  the  same hostname, IP address and lease time. A hostname
              specified like this overrides any supplied by the DHCP client on
              the  machine.  It is also allowable to omit the hardware address
              and include the hostname, in which case the IP address and lease
              times  will apply to any machine claiming that name. For example
              --dhcp-host=00:20:e0:3b:13:af,wap,infinite tells dnsmasq to give
              the  machine  with  hardware  address 00:20:e0:3b:13:af the name
              wap, and an infinite DHCP lease.   --dhcp-host=lap,192.168.0.199
              tells  dnsmasq to always allocate the machine lap the IP address
              192.168.0.199.

              Addresses allocated like this are not constrained to be  in  the
              range  given by the --dhcp-range option, but they must be in the
              same subnet as some valid dhcp-range.  For subnets  which  don't
              need a pool of dynamically allocated addresses, use the "static"
              keyword in the --dhcp-range declaration.

              It is allowed to use client identifiers (called client  DUID  in
              IPv6-land)  rather  than hardware addresses to identify hosts by
              prefixing  with  'id:'.  Thus:  --dhcp-host=id:01:02:03:04,.....
              refers  to  the  host  with client identifier 01:02:03:04. It is
              also allowed to specify  the  client  ID  as  text,  like  this:
              --dhcp-host=id:clientidastext,.....

              A  single --dhcp-host may contain an IPv4 address or one or more
              IPv6 addresses, or both. IPv6 addresses  must  be  bracketed  by
              square  brackets  thus:  --dhcp-host=laptop,[1234::56]  IPv6 ad-
              dresses may  contain  only  the  host-identifier  part:  --dhcp-
              host=laptop,[::56]  in  which case they act as wildcards in con-
              structed DHCP ranges, with  the  appropriate  network  part  in-
              serted.  For  IPv6,  an  address  may  include  a prefix length:
              --dhcp-host=laptop,[1234:50/126] which (in this case)  specifies
              four  addresses,  1234::50  to 1234::53. This (an the ability to
              specify multiple addresses) is useful when a host  presents  ei-
              ther  a consistent name or hardware-ID, but varying DUIDs, since
              it allows dnsmasq to honour the static  address  allocation  but
              assign a different adddress for each DUID. This typically occurs
              when chain netbooting, as each stage of the chain gets  in  turn
              allocates an address.

              Note  that  in IPv6 DHCP, the hardware address may not be avail-
              able, though it normally is  for  direct-connected  clients,  or
              clients using DHCP relays which support RFC 6939.

              For DHCPv4, the  special option id:* means "ignore any client-id
              and use MAC addresses  only."  This  is  useful  when  a  client
              presents a client-id sometimes but not others.

              If  a  name appears in /etc/hosts, the associated address can be
              allocated to a DHCP lease, but  only  if  a  --dhcp-host  option
              specifying  the name also exists. Only one hostname can be given
              in a --dhcp-host option,  but  aliases  are  possible  by  using
              CNAMEs. (See --cname ).

              The special keyword "ignore" tells dnsmasq to never offer a DHCP
              lease to a machine. The machine can be specified by hardware ad-
              dress,   client   ID   or   hostname,   for   instance   --dhcp-
              host=00:20:e0:3b:13:af,ignore This is useful when there  is  an-
              other  DHCP  server  on the network which should be used by some
              machines.

              The set:<tag> construct sets the tag whenever  this  --dhcp-host
              directive  is  in use. This can be used to selectively send DHCP
              options just for this host. More than one tag can be  set  in  a
              --dhcp-host directive (but not in other places where "set:<tag>"
              is allowed). When a host matches any --dhcp-host  directive  (or
              one implied by /etc/ethers) then the special tag "known" is set.
              This allows dnsmasq to be configured to ignore requests from un-
              known   machines  using  --dhcp-ignore=tag:!known  If  the  host
              matches only a --dhcp-host directive which cannot  be  used  be-
              cause  it  specifies  an  address  on  different subnet, the tag
              "known-othernet" is set.

              The tag:<tag> construct filters which dhcp-host  directives  are
              used. Tagged directives are used in preference to untagged ones.

              Ethernet addresses (but not client-ids) may have wildcard bytes,
              so for example  --dhcp-host=00:20:e0:3b:13:*,ignore  will  cause
              dnsmasq  to  ignore a range of hardware addresses. Note that the
              "*" will need to be escaped or quoted on a command line, but not
              in the configuration file.

              Hardware addresses normally match any network (ARP) type, but it
              is possible to restrict them to a single ARP type  by  preceding
              them   with   the   ARP-type   (in  HEX)  and  "-".  so  --dhcp-
              host=06-00:20:e0:3b:13:af,1.2.3.4 will only match  a  Token-Ring
              hardware  address,  since the ARP-address type for token ring is
              6.

              As a special case, in DHCPv4, it is  possible  to  include  more
              than       one      hardware      address.      eg:      --dhcp-
              host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2 This allows
              an IP address to be associated with multiple hardware addresses,
              and gives dnsmasq permission to abandon a DHCP lease to  one  of
              the hardware addresses when another one asks for a lease. Beware
              that this is a dangerous thing to do, it will only work reliably
              if  only one of the hardware addresses is active at any time and
              there is no way for dnsmasq to enforce  this.  It  is,  for  in-
              stance, useful to allocate a stable IP address to a laptop which
              has both wired and wireless interfaces.

       --dhcp-hostsfile=<path>
              Read DHCP host information from the specified file. If a  direc-
              tory  is given, then read all the files contained in that direc-
              tory. The file contains information about one host per line. The
              format  of  a  line  is  the same as text to the right of '=' in
              --dhcp-host. The advantage of storing DHCP host  information  in
              this file is that it can be changed without re-starting dnsmasq:
              the file will be re-read when dnsmasq receives SIGHUP.

       --dhcp-optsfile=<path>
              Read DHCP option information from the specified file.  If a  di-
              rectory  is given, then read all the files contained in that di-
              rectory. The advantage of using this option is the same  as  for
              --dhcp-hostsfile:  the --dhcp-optsfile will be re-read when dns-
              masq receives SIGHUP. Note that it is possible to encode the in-
              formation  in  a --dhcp-boot flag as DHCP options, using the op-
              tions names bootfile-name,  server-ip-address  and  tftp-server.
              This allows these to be included in a --dhcp-optsfile.

       --dhcp-hostsdir=<path>
              This  is  equivalent to --dhcp-hostsfile, except for the follow-
              ing. The path MUST be a directory, and not an  individual  file.
              Changed  or  new  files  within the directory are read automati-
              cally, without the need to send SIGHUP.  If a file is deleted or
              changed  after it has been read by dnsmasq, then the host record
              it contained will remain until dnsmasq receives a SIGHUP, or  is
              restarted; ie host records are only added dynamically.

       --dhcp-optsdir=<path>
              This  is  equivalent  to  --dhcp-optsfile,  with the differences
              noted for --dhcp-hostsdir.

       -Z, --read-ethers
              Read /etc/ethers  for  information  about  hosts  for  the  DHCP
              server.  The  format  of /etc/ethers is a hardware address, fol-
              lowed by either a hostname or dotted-quad IP address. When  read
              by  dnsmasq  these lines have exactly the same effect as --dhcp-
              host options containing the same information. /etc/ethers is re-
              read  when  dnsmasq receives SIGHUP. IPv6 addresses are NOT read
              from /etc/ethers.

       -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>]]
              Specify different or 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
              dnsmasq, 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>" The option numbers
              are specified in RFC2132 and subsequent RFCs. The set of option-
              names known by dnsmasq can be  discovered  by  running  "dnsmasq
              --help  dhcp".   For example, to set the default route option to
              192.168.4.4, do --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, do --dhcp-option = 42,192.168.0.4 or  --dhcp-option
              =  option:ntp-server, 192.168.0.4 The special address 0.0.0.0 is
              taken to mean "the address of the machine running dnsmasq".

              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-op-
              tion=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:  no  checking is done that the correct type of data
              for the option number is sent, it is quite possible to  persuade
              dnsmasq to generate illegal DHCP packets with injudicious use of
              this flag. When the value is a decimal number, dnsmasq must  de-
              termine  how  large  the data item is. It does this by examining
              the option number and/or the value, but can be overridden by ap-
              pending  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  periods and digits will be interpreted by dnsmasq as
              an IP address, 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: are 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-no-override
              (IPv4 only) Disable re-use of the DHCP servername  and  filename
              fields  as extra option space. If it can, dnsmasq moves the boot
              server and filename information (from --dhcp-boot) out of  their
              dedicated fields into DHCP options. This make extra space avail-
              able in the DHCP packet for options but can, rarely, confuse old
              or  broken clients. This flag forces "simple and safe" behaviour
              to avoid problems in such a case.

       --dhcp-relay=<local address>,<server address>[,<interface]
              Configure dnsmasq to do DHCP relay. The local address is an  ad-
              dress allocated to an interface on the host running dnsmasq. All
              DHCP requests arriving on that interface will we  relayed  to  a
              remote  DHCP server at the server address. It is possible to re-
              lay from a single local address to multiple  remote  servers  by
              using  multiple --dhcp-relay configs with the same local address
              and different server addresses. A server address must be  an  IP
              literal  address,  not a domain name. In the case of DHCPv6, the
              server  address  may  be  the  ALL_SERVERS  multicast   address,
              ff05::1:3.  In  this  case  the  interface must be given, not be
              wildcard, and is used to direct the multicast to the correct in-
              terface to reach the DHCP server.

              Access  control  for  DHCP clients has the same rules as for the
              DHCP server, see --interface, --except-interface, etc.  The  op-
              tional interface name in the --dhcp-relay config has a different
              function: it controls on which interface DHCP replies  from  the
              server  will  be  accepted.  This is intended for configurations
              which have three interfaces: one being relayed  from,  a  second
              connecting the DHCP server, and a third untrusted network, typi-
              cally the wider internet. It avoids  the  possibility  of  spoof
              replies arriving via this third interface.

              It is allowed to have dnsmasq act as a DHCP server on one set of
              interfaces and relay from a disjoint  set  of  interfaces.  Note
              that  whilst  it is quite possible to write configurations which
              appear to act as a server and a relay  on  the  same  interface,
              this is not supported: the relay function will take precedence.

              Both  DHCPv4 and DHCPv6 relay is supported. It's not possible to
              relay DHCPv4 to a DHCPv6 server or vice-versa.

       -U,   --dhcp-vendorclass=set:<tag>,[enterprise:<IANA-enterprise    num-
       ber>,]<vendor-class>
              Map  from a vendor-class string to a tag. Most DHCP clients pro-
              vide a "vendor class" which represents, in some sense, the  type
              of  host.  This option maps vendor classes to tags, so that DHCP
              options may be selectively delivered  to  different  classes  of
              hosts.   For   example  --dhcp-vendorclass=set:printers,Hewlett-
              Packard JetDirect will allow options  to  be  set  only  for  HP
              printers  like  so: --dhcp-option=tag:printers,3,192.168.4.4 The
              vendor-class string is substring  matched  against  the  vendor-
              class  supplied by the client, to allow fuzzy matching. The set:
              prefix is optional but allowed for consistency.

              Note that in IPv6 only, vendorclasses  are  namespaced  with  an
              IANA-allocated enterprise number. This is given with enterprise:
              keyword and specifies that only vendorclasses matching the spec-
              ified number should be searched.

       -j, --dhcp-userclass=set:<tag>,<user-class>
              Map  from a user-class string to a tag (with substring matching,
              like vendor classes). Most DHCP clients provide a  "user  class"
              which is configurable. This option maps user classes to tags, so
              that DHCP options may  be  selectively  delivered  to  different
              classes  of  hosts.  It is possible, for instance to use this to
              set a different printer server for hosts in the class "accounts"
              than for hosts in the class "engineering".

       -4, --dhcp-mac=set:<tag>,<MAC address>
              Map  from  a  MAC  address to a tag. The MAC address may include
              wildcards. For example  --dhcp-mac=set:3com,01:34:23:*:*:*  will
              set  the  tag  "3com" for any host whose MAC address matches the
              pattern.

       --dhcp-circuitid=set:<tag>,<circuit-id>, --dhcp-remoteid=set:<tag>,<re-
       mote-id>
              Map  from  RFC3046 relay agent options to tags. This data may be
              provided by DHCP relay agents. The circuit-id  or  remote-id  is
              normally given as colon-separated hex, but is also allowed to be
              a simple string. If an exact match is achieved between the  cir-
              cuit  or  agent ID and one provided by a relay agent, the tag is
              set.

              --dhcp-remoteid (but not --dhcp-circuitid) is supported in IPv6.

       --dhcp-subscrid=set:<tag>,<subscriber-id>
              (IPv4 and IPv6) Map from RFC3993 subscriber-id relay  agent  op-
              tions to tags.

       --dhcp-proxy[=<ip addr>]......
              (IPv4  only)  A  normal DHCP relay agent is only used to forward
              the initial parts of a DHCP interaction to the DHCP server. Once
              a  client  is  configured,  it  communicates  directly  with the
              server. This is undesirable if the relay agent is  adding  extra
              information  to  the  DHCP packets, such as that used by --dhcp-
              circuitid and --dhcp-remoteid.  A full relay implementation  can
              use  the  RFC  5107  serverid-override  option to force the DHCP
              server to use the relay as a full proxy, with all packets  pass-
              ing  through it. This flag provides an alternative method of do-
              ing the same thing, for relays which  don't  support  RFC  5107.
              Given  alone,  it manipulates the server-id for all interactions
              via relays. If a list of IP addresses is  given,  only  interac-
              tions via relays at those addresses are affected.

       --dhcp-match=set:<tag>,<option    number>|option:<option   name>|vi-en-
       cap:<enterprise>[,<value>]
              Without a value, set the tag if the client sends a  DHCP  option
              of  the given number or name. When a value is given, set the tag
              only if the option is sent and matches the value. The value  may
              be  of  the form "01:ff:*:02" in which case the value must match
              (apart from wildcards) but the option sent  may  have  unmatched
              data  past  the  end  of the value. The value may also be of the
              same form as in --dhcp-option in which case the option  sent  is
              treated  as  an  array,  and  one element must match, so --dhcp-
              match=set:efi-ia32,option:client-arch,6 will set the  tag  "efi-
              ia32"  if  the the number 6 appears in the list of architectures
              sent by the client in option 93. (See RFC 4578 for details.)  If
              the value is a string, substring matching is used.

              The  special  form  with  vi-encap:<enterprise  number>  matches
              against vendor-identifying vendor classes for the specified  en-
              terprise. Please see RFC 3925 for more details of these rare and
              interesting beasts.

       --dhcp-name-match=set:<tag>,<name>[*]
              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.

       --tag-if=set:<tag>[,set:<tag>[,tag:<tag>[,tag:<tag>]]]
              Perform  boolean  operations  on  tags.  Any  tag  appearing  as
              set:<tag>  is  set if all the tags which appear as tag:<tag> are
              set, (or unset when tag:!<tag> is used) If no tag:<tag>  appears
              set:<tag>  tags are set unconditionally.  Any number of set: and
              tag: forms may appear, in any order.  --tag-if  lines  are  exe-
              cuted  in  order, so if the tag in tag:<tag> is a tag set by an-
              other --tag-if, the line which sets the tag must precede the one
              which tests it.

       -J, --dhcp-ignore=tag:<tag>[,tag:<tag>]
              When  all  the  given tags appear in the tag set ignore the host
              and do not allocate it a DHCP lease.

       --dhcp-ignore-names[=tag:<tag>[,tag:<tag>]]
              When all the given tags appear in the tag set, ignore any  host-
              name  provided  by the host. Note that, unlike --dhcp-ignore, it
              is permissible to supply no tags, in which case DHCP-client sup-
              plied  hostnames are always ignored, and DHCP hosts are added to
              the DNS using only --dhcp-host configuration in dnsmasq and  the
              contents of /etc/hosts and /etc/ethers.

       --dhcp-generate-names=tag:<tag>[,tag:<tag>]
              (IPv4 only) Generate a name for DHCP clients which do not other-
              wise have one, using the MAC address expressed in hex, separated
              by  dashes. Note that if a host provides a name, it will be used
              by preference to this, unless --dhcp-ignore-names is set.

       --dhcp-broadcast[=tag:<tag>[,tag:<tag>]]
              (IPv4 only) When all the given tags appear in the tag  set,  al-
              ways  use  broadcast to communicate with the host when it is un-
              configured. It is permissible to supply no tags, in  which  case
              this  is  unconditional.  Most DHCP clients which need broadcast
              replies set a flag in their requests so that this happens  auto-
              matically, some old BOOTP clients do not.

       -M,    --dhcp-boot=[tag:<tag>,]<filename>,[<servername>[,<server    ad-
       dress>|<tftp_servername>]]
              (IPv4 only) Set BOOTP options to be returned by the DHCP server.
              Server  name and address are optional: if not provided, the name
              is left empty, and the address set to the address of the machine
              running  dnsmasq.  If  dnsmasq  is providing a TFTP service (see
              --enable-tftp ) then only the filename is required here  to  en-
              able  network  booting.   If the optional tag(s) are given, they
              must match for this configuration to be sent.  Instead of an  IP
              address,  the  TFTP server address can be given as a domain name
              which is looked up in /etc/hosts. This name can be associated in
              /etc/hosts  with  multiple  IP  addresses, which are used round-
              robin.  This facility can be used to load balance the tftp  load
              among a set of servers.

       --dhcp-sequential-ip
              Dnsmasq  is designed to choose IP addresses for DHCP clients us-
              ing a hash of the client's MAC address. This normally  allows  a
              client's  address to remain stable long-term, even if the client
              sometimes allows its DHCP lease to expire. In this default  mode
              IP  addresses  are  distributed  pseudo-randomly over the entire
              available address range. There are sometimes circumstances (typ-
              ically server deployment) where it is more convenient to have IP
              addresses  allocated  sequentially,  starting  from  the  lowest
              available address, and setting this flag enables this mode. Note
              that in the sequential mode, clients which allow a lease to  ex-
              pire are much more likely to move IP address; for this reason it
              should not be generally used.

       --dhcp-ignore-clid
              Dnsmasq is reading 'client identifier' (RFC 2131) option sent by
              clients  (if available) to identify clients. This allow to serve
              same IP address for a host using several  interfaces.  Use  this
              option  to  disable  'client identifier' reading, i.e. to always
              identify a host using the MAC address.

       --pxe-service=[tag:<tag>,]<CSA>,<menu   text>[,<basename>|<bootservice-
       type>][,<server address>|<server_name>]
              Most uses of PXE boot-ROMS simply allow the PXE system to obtain
              an IP address and then download the file  specified  by  --dhcp-
              boot  and  execute it. However the PXE system is capable of more
              complex functions when supported by a suitable DHCP server.

              This specifies a boot option which may  appear  in  a  PXE  boot
              menu.  <CSA> is client system type, only services of the correct
              type will appear in a menu. The known  types  are  x86PC,  PC98,
              IA64_EFI,    Alpha,    Arc_x86,   Intel_Lean_Client,   IA32_EFI,
              X86-64_EFI, Xscale_EFI, BC_EFI, ARM32_EFI and ARM64_EFI; an  in-
              teger  may be used for other types. The parameter after the menu
              text may be a file name, in which case dnsmasq acts  as  a  boot
              server  and directs the PXE client to download the file by TFTP,
              either from itself ( --enable-tftp must be set for this to work)
              or  another  TFTP  server  if  the  final server address/name is
              given.  Note that the "layer" suffix (normally ".0") is supplied
              by  PXE,  and  need not be added to the basename. Alternatively,
              the basename may be a filename, complete with suffix,  in  which
              case  no layer suffix is added. If an integer boot service type,
              rather than a basename is given, then the PXE client will search
              for  a  suitable boot service for that type on the network. This
              search may be done by broadcast, or direct to a server if its IP
              address/name  is  provided.  If no boot service type or filename
              is provided (or a boot service type of 0 is specified) then  the
              menu  entry will abort the net boot procedure and continue boot-
              ing from local media. The server address can be given as  a  do-
              main name which is looked up in /etc/hosts. This name can be as-
              sociated in /etc/hosts with multiple  IP  addresses,  which  are
              used round-robin.

       --pxe-prompt=[tag:<tag>,]<prompt>[,<timeout>]
              Setting  this  provides a prompt to be displayed after PXE boot.
              If the timeout is given then after the timeout has elapsed  with
              no keyboard input, the first available menu option will be auto-
              matically executed. If the timeout is zero then the first avail-
              able  menu item will be executed immediately. If --pxe-prompt is
              omitted the system will wait for user input if there are  multi-
              ple  items  in  the  menu, but boot immediately if there is only
              one. See --pxe-service for details of menu items.

              Dnsmasq supports PXE "proxy-DHCP", in  this  case  another  DHCP
              server  on  the  network  is  responsible  for allocating IP ad-
              dresses, and dnsmasq simply provides the  information  given  in
              --pxe-prompt and --pxe-service to allow netbooting. This mode is
              enabled using the proxy keyword in --dhcp-range.

       -X, --dhcp-lease-max=<number>
              Limits dnsmasq to the specified maximum number of  DHCP  leases.
              The  default  is 1000. This limit is to prevent DoS attacks from
              hosts which create thousands of leases and use lots of memory in
              the dnsmasq process.

       -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 al-
              lows 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)  in-
              stead of 0 (the minimum).

       --dhcp-rapid-commit
              Enable  DHCPv4  Rapid  Commit Option specified in RFC 4039. When
              enabled, dnsmasq will respond to a DHCPDISCOVER message  includ-
              ing  a Rapid Commit option with a DHCPACK including a Rapid Com-
              mit option and fully committed address and configuration  infor-
              mation. Should only be enabled if either the server is  the only
              server for the subnet, or multiple servers are present and  they
              each commit a binding for all clients.

       --dhcp-alternate-port[=<server port>[,<client port>]]
              (IPv4  only) Change the ports used for DHCP from the default. If
              this option is given alone, without arguments,  it  changes  the
              ports used for DHCP from 67 and 68 to 1067 and 1068. If a single
              argument is given, that port number is used for the  server  and
              the  port number plus one used for the client. Finally, two port
              numbers allows arbitrary specification of both server and client
              ports for DHCP.

       -3, --bootp-dynamic[=<network-id>[,<network-id>]]
              (IPv4  only)  Enable dynamic allocation of IP addresses to BOOTP
              clients. Use this with care, since each address allocated  to  a
              BOOTP  client  is  leased  forever, and therefore becomes perma-
              nently unavailable for re-use by other hosts. if this  is  given
              without  tags,  then  it unconditionally enables dynamic alloca-
              tion. With tags, only when the tags are all set. It may  be  re-
              peated with different tag sets.

       -5, --no-ping
              (IPv4  only)  By default, the DHCP server will attempt to ensure
              that an address is not in use before allocating it to a host. It
              does  this  by  sending an ICMP echo request (aka "ping") to the
              address in question. If it gets a reply, then the  address  must
              already be in use, and another is tried. This flag disables this
              check. Use with caution.

       --log-dhcp
              Extra logging for DHCP: log all the options sent to DHCP clients
              and the tags used to determine them.

       --quiet-dhcp, --quiet-dhcp6, --quiet-ra
              Suppress  logging  of  the routine operation of these protocols.
              Errors and problems  will  still  be  logged.  --quiet-dhcp  and
              quiet-dhcp6 are over-ridden by --log-dhcp.

       -l, --dhcp-leasefile=<path>
              Use the specified file to store DHCP lease information.

       --dhcp-duid=<enterprise-id>,<uid>
              (IPv6  only)  Specify the server persistent UID which the DHCPv6
              server will use. This option is not normally required as dnsmasq
              creates  a  DUID  automatically  when  it  is first needed. When
              given, this option provides dnsmasq the data required to  create
              a  DUID-EN  type DUID. Note that once set, the DUID is stored in
              the lease database, so to change between DUID-EN  and  automati-
              cally  created  DUIDs  or vice-versa, the lease database must be
              re-initialised. The enterprise-id is assigned by IANA,  and  the
              uid is a string of hex octets unique to a particular device.

       -6 --dhcp-script=<path>
              Whenever  a  new DHCP lease is created, or an old one destroyed,
              or a TFTP file transfer completes, the executable  specified  by
              this  option  is  run.   <path> must be an absolute pathname, no
              PATH search occurs.  The arguments to  the  process  are  "add",
              "old" or "del", the MAC address of the host (or DUID for IPv6) ,
              the IP address, and the hostname, if known. "add" means a  lease
              has  been created, "del" means it has been destroyed, "old" is a
              notification of an existing  lease  when  dnsmasq  starts  or  a
              change  to  MAC  address or hostname of an existing lease (also,
              lease length or expiry and client-id, if --leasefile-ro  is  set
              and lease expiry if --script-on-renewal is set).  If the MAC ad-
              dress is from a network type other than ethernet, it  will  have
              the  network type prepended, eg "06-01:23:45:67:89:ab" for token
              ring. The process is run as  root  (assuming  that  dnsmasq  was
              originally  run as root) even if dnsmasq is configured to change
              UID to an unprivileged user.

              The environment is inherited from the invoker of  dnsmasq,  with
              some or all of the following variables added

              For both IPv4 and IPv6:

              DNSMASQ_DOMAIN if the fully-qualified domain name of the host is
              known, this is set to the  domain part. (Note that the  hostname
              passed to the script as an argument is never fully-qualified.)

              If the client provides a hostname, DNSMASQ_SUPPLIED_HOSTNAME

              If  the  client provides user-classes, DNSMASQ_USER_CLASS0..DNS-
              MASQ_USER_CLASSn

              If dnsmasq was compiled with HAVE_BROKEN_RTC, then the length of
              the lease (in seconds) is stored in DNSMASQ_LEASE_LENGTH, other-
              wise the time of lease expiry  is  stored  in  DNSMASQ_LEASE_EX-
              PIRES. The number of seconds until lease expiry is always stored
              in DNSMASQ_TIME_REMAINING.

              If a lease used to have a hostname, which is removed,  an  "old"
              event  is generated with the new state of the lease, ie no name,
              and the former name is provided in the environment variable DNS-
              MASQ_OLD_HOSTNAME.

              DNSMASQ_INTERFACE  stores the name of the interface on which the
              request arrived; this is not set for "old" actions when  dnsmasq
              restarts.

              DNSMASQ_RELAY_ADDRESS  is set if the client used a DHCP relay to
              contact dnsmasq and the IP address of the relay is known.

              DNSMASQ_TAGS contains all the tags set during the DHCP  transac-
              tion, separated by spaces.

              DNSMASQ_LOG_DHCP is set if --log-dhcp is in effect.

              For IPv4 only:

              DNSMASQ_CLIENT_ID if the host provided a client-id.

              DNSMASQ_CIRCUIT_ID,  DNSMASQ_SUBSCRIBER_ID, DNSMASQ_REMOTE_ID if
              a DHCP relay-agent added any of these options.

              If the client provides vendor-class, DNSMASQ_VENDOR_CLASS.

              DNSMASQ_REQUESTED_OPTIONS a string containing the decimal values
              in  the  Parameter  Request List option, comma separated, if the
              parameter request list option is provided by the client.

              For IPv6 only:

              If the client  provides  vendor-class,  DNSMASQ_VENDOR_CLASS_ID,
              containing  the  IANA  enterprise  id  for  the  class, and DNS-
              MASQ_VENDOR_CLASS0..DNSMASQ_VENDOR_CLASSn for the data.

              DNSMASQ_SERVER_DUID containing the DUID of the server:  this  is
              the same for every call to the script.

              DNSMASQ_IAID  containing the IAID for the lease. If the lease is
              a temporary allocation, this is prefixed to 'T'.

              DNSMASQ_MAC containing the MAC address of the client, if known.

              Note that the supplied hostname, vendorclass and userclass  data
              is only  supplied for "add" actions or "old" actions when a host
              resumes an existing lease, since these data are not held in dns-
              masq's lease database.

              All  file  descriptors are closed except stdin, which is open to
              /dev/null, and stdout and stderr which capture output  for  log-
              ging  by dnsmasq.  (In debug mode, stdio, stdout and stderr file
              are left as those inherited from the invoker of dnsmasq).

              The script is not invoked concurrently: at most one instance  of
              the  script  is  ever  running (dnsmasq waits for an instance of
              script to exit before running the next). Changes  to  the  lease
              database  are  which require the script to be invoked are queued
              awaiting exit of a running instance.  If  this  queueing  allows
              multiple state changes occur to a single lease before the script
              can be run then earlier states are  discarded  and  the  current
              state of that lease is reflected when the script finally runs.

              At  dnsmasq startup, the script will be invoked for all existing
              leases as they are read from the lease file. Expired leases will
              be  called  with  "del"  and others with "old". When dnsmasq re-
              ceives a HUP signal, the script will  be  invoked  for  existing
              leases with an "old" event.

              There are four further actions which may appear as the first ar-
              gument to the script, "init", "arp-add", "arp-del"  and  "tftp".
              More may be added in the future, so scripts should be written to
              ignore unknown actions. "init" is described  below  in  --lease-
              file-ro  The  "tftp" action is invoked when a TFTP file transfer
              completes: the arguments are the file size in bytes, the address
              to  which  the  file  was sent, and the complete pathname of the
              file.

              The "arp-add" and "arp-del" actions are only called  if  enabled
              with  --script-arp  They are are supplied with a MAC address and
              IP address as arguments. "arp-add" indicates the  arrival  of  a
              new entry in the ARP or neighbour table, and "arp-del" indicates
              the deletion of same.

       --dhcp-luascript=<path>
              Specify a script written in Lua, to be run when leases are  cre-
              ated,  destroyed or changed. To use this option, dnsmasq must be
              compiled with the correct support. The Lua interpreter  is  ini-
              tialised  once,  when  dnsmasq  starts, so that global variables
              persist between lease events. The Lua code must define  a  lease
              function, and may provide init and shutdown functions, which are
              called, without arguments when dnsmasq starts up and terminates.
              It may also provide a tftp function.

              The  lease function receives the information detailed in --dhcp-
              script.  It gets two arguments, firstly the action, which  is  a
              string  containing,  "add", "old" or "del", and secondly a table
              of tag value pairs. The tags mostly correspond to  the  environ-
              ment  variables  detailed  above,  for instance the tag "domain"
              holds the same data as the environment variable  DNSMASQ_DOMAIN.
              There are a few extra tags which hold the data supplied as argu-
              ments to --dhcp-script.  These are mac_address,  ip_address  and
              hostname  for IPv4, and client_duid, ip_address and hostname for
              IPv6.

              The tftp function is called in the same way as the  lease  func-
              tion,   and   the  table  holds  the  tags  destination_address,
              file_name and file_size.

              The arp and arp-old functions are called only when enabled  with
              --script-arp  and  have a table which holds the tags mac_address
              and client_address.

       --dhcp-scriptuser
              Specify the user as which to run the lease-change script or  Lua
              script.  This  defaults  to  root, but can be changed to another
              user using this flag.

       --script-arp
              Enable the "arp" and "arp-old" functions  in  the  --dhcp-script
              and --dhcp-luascript.

       -9, --leasefile-ro
              Completely  suppress  use  of  the lease database file. The file
              will not be created, read, or written. Change the way the lease-
              change  script (if one is provided) is called, so that the lease
              database may be maintained in external storage by the script. In
              addition  to  the invocations  given in --dhcp-script the lease-
              change script is called once, at dnsmasq startup, with the  sin-
              gle  argument  "init".  When  called like this the script should
              write the saved state of the lease database, in  dnsmasq  lease-
              file  format,  to  stdout  and exit with zero exit code. Setting
              this option also forces the leasechange script to be  called  on
              changes to the client-id and lease length and expiry time.

       --script-on-renewal
              Call the DHCP script when the lease expiry time changes, for in-
              stance when the lease is renewed.

       --bridge-interface=<interface>,<alias>[,<alias>]
              Treat DHCP (v4 and v6) requests and IPv6 Router Solicit  packets
              arriving at any of the <alias> interfaces as if they had arrived
              at <interface>.  This option allows dnsmasq to provide DHCP  and
              RA  service  over unaddressed and unbridged Ethernet interfaces,
              e.g. on an OpenStack compute host where each such interface is a
              TAP  interface  to  a  VM,  or as in "old style bridging" on BSD
              platforms.  A trailing '*' wildcard can be used in each <alias>.

              It is permissible to add more than one alias using more than one
              --bridge-interface       option       since      --bridge-inter-
              face=int1,alias1,alias2 is exactly equivalent to --bridge-inter-
              face=int1,alias1 --bridge-interface=int1,alias2

       --shared-network=<interface>,<addr>
       --shared-network=<addr>,<addr>
              The DHCP server determines which DHCP ranges are useable for al-
              locating an address to a DHCP client based on the  network  from
              which  the DHCP request arrives, and the IP configuration of the
              server's interface on that network.  The  shared-network  option
              extends the available subnets (and therefore DHCP ranges) beyond
              the subnets configured on the arrival interface.

              The first argument is either the name of an interface, or an ad-
              dress  that  is  configured on a local interface, and the second
              argument is an address which defines another subnet on which ad-
              dresses can be allocated.

              To  be  useful, there must be a suitable dhcp-range which allows
              address allocation on this subnet and this dhcp-range  MUST  in-
              clude the netmask.

              Using  shared-network also needs extra consideration of routing.
              Dnsmasq does not have the usual information that it uses to  de-
              termine the default route, so the default route option (or other
              routing) MUST be configured manually. The  client  must  have  a
              route  to  the server: if the two-address form of shared-network
              is used, this needs to be to the first specified address. If the
              interface,address  form is used, there must be a route to all of
              the addresses configured on the interface.

              The two-address form of shared-network is  also  usable  with  a
              DHCP  relay:  the  first address is the address of the relay and
              the second, as before, specifies an extra subnet which addresses
              may be allocated from.

       -s, --domain=<domain>[,<address range>[,local]]
              Specifies  DNS  domains  for  the DHCP server. Domains may be be
              given unconditionally (without the IP range) or for  limited  IP
              ranges.  This has two effects; firstly it causes the DHCP server
              to return the domain to any hosts which request it, and secondly
              it  sets  the domain which it is legal for DHCP-configured hosts
              to claim. The intention is to constrain hostnames so that an un-
              trusted  host  on  the LAN cannot advertise its name via DHCP as
              e.g. "microsoft.com" and capture traffic not meant for it. If no
              domain suffix is specified, then any DHCP hostname with a domain
              part (ie with a period) will be disallowed and logged. If suffix
              is  specified,  then  hostnames  with a domain part are allowed,
              provided the domain part matches the suffix. In addition, when a
              suffix is set then hostnames without a domain part have the suf-
              fix added as an optional domain part. Eg on my network I can set
              --domain=thekelleys.org.uk  and  have a machine whose DHCP host-
              name is "laptop". The IP address for that machine  is  available
              from dnsmasq both as "laptop" and "laptop.thekelleys.org.uk". If
              the domain is given as "#" then the  domain  is  read  from  the
              first "search" directive in /etc/resolv.conf (or equivalent).

              The  address  range can be of the form <ip address>,<ip address>
              or <ip address>/<netmask> or just a  single  <ip  address>.  See
              --dhcp-fqdn  which  can change the behaviour of dnsmasq with do-
              mains.

              If the address range is given as ip-address/network-size, then a
              additional  flag "local" may be supplied which has the effect of
              adding --local declarations for forward and reverse DNS queries.
              Eg.   --domain=thekelleys.org.uk,192.168.0.0/24,local is identi-
              cal    to    --domain=thekelleys.org.uk,192.168.0.0/24     --lo-
              cal=/thekelleys.org.uk/   --local=/0.168.192.in-addr.arpa/   The
              network size must be 8, 16 or 24 for this to be legal.

       --dhcp-fqdn
              In the default mode, dnsmasq inserts the  unqualified  names  of
              DHCP  clients  into  the DNS. For this reason, the names must be
              unique, even if two clients which have the same name are in dif-
              ferent  domains.  If  a second DHCP client appears which has the
              same name as an existing client, the name is transferred to  the
              new  client.  If --dhcp-fqdn is set, this behaviour changes: the
              unqualified name is no longer put in the DNS, only the qualified
              name.  Two  DHCP  clients  with  the same name may both keep the
              name, provided that the domain part is different (ie  the  fully
              qualified  names differ.) To ensure that all names have a domain
              part, there must be at least --domain without an address  speci-
              fied when --dhcp-fqdn is set.

       --dhcp-client-update
              Normally,  when  giving  a DHCP lease, dnsmasq sets flags in the
              FQDN option to tell the client not to attempt a DDNS update with
              its name and IP address. This is because the name-IP pair is au-
              tomatically added into dnsmasq's DNS view. This flag  suppresses
              that  behaviour,  this is useful, for instance, to allow Windows
              clients to update Active Directory servers. See RFC 4702 for de-
              tails.

       --enable-ra
              Enable  dnsmasq's  IPv6  Router  Advertisement  feature.  DHCPv6
              doesn't handle complete network configuration in the same way as
              DHCPv4. Router discovery and (possibly) prefix discovery for au-
              tonomous address creation are handled by a  different  protocol.
              When  DHCP  is in use, only a subset of this is needed, and dns-
              masq can handle it, using existing DHCP configuration to provide
              most  data.  When RA is enabled, dnsmasq will advertise a prefix
              for each --dhcp-range, with  default  router   as  the  relevant
              link-local  address  on the machine running dnsmasq. By default,
              the "managed address" bits are set, and the "use SLAAC"  bit  is
              reset.  This can be changed for individual subnets with the mode
              keywords described in --dhcp-range.  RFC6106 DNS parameters  are
              included  in  the advertisements. By default, the relevant link-
              local address of the machine running dnsmasq is sent  as  recur-
              sive  DNS server. If provided, the DHCPv6 options dns-server and
              domain-search are used for the DNS server (RDNSS) and the domain
              search list (DNSSL).

       --ra-param=<interface>,[mtu:<integer>|<interface>|off,][high,|low,]<ra-
       interval>[,<router lifetime>]
              Set non-default values for router advertisements sent via an in-
              terface.  The  priority field for the router may be altered from
              the default of medium with eg --ra-param=eth0,high.  The  inter-
              val  between  router advertisements may be set (in seconds) with
              --ra-param=eth0,60.  The lifetime of the route may be changed or
              set to zero, which allows a router to advertise prefixes but not
              a route via itself.  --ra-param=eth0,0,0 (A value  of  zero  for
              the  interval  means the default value.) All four parameters may
              be set at once.  --ra-param=eth0,mtu:1280,low,60,1200

              The interface field may include a wildcard.

              The mtu: parameter may be an arbitrary interface name, in  which
              case  the  MTU  value for that interface is used. This is useful
              for (eg) advertising the MTU of a WAN interface on the other in-
              terfaces of a router.

       --dhcp-reply-delay=[tag:<tag>,]<integer>
              Delays  sending DHCPOFFER and PROXYDHCP replies for at least the
              specified number of seconds.  This can be used as workaround for
              bugs  in  PXE boot firmware that does not function properly when
              receiving an instant reply.  This option takes into account  the
              time already spent waiting (e.g. performing ping check) if any.

       --enable-tftp[=<interface>[,<interface>]]
              Enable the TFTP server function. This is deliberately limited to
              that needed to net-boot a client. Only reading is  allowed;  the
              tsize  and  blksize extensions are supported (tsize is only sup-
              ported in octet mode). Without an argument, the TFTP service  is
              provided  to the same set of interfaces as DHCP service.  If the
              list of interfaces is provided, that  defines  which  interfaces
              receive TFTP service.

       --tftp-root=<directory>[,<interface>]
              Look  for files to transfer using TFTP relative to the given di-
              rectory. When this is set, TFTP paths which include ".." are re-
              jected, to stop clients getting outside the specified root.  Ab-
              solute paths (starting with /) are allowed,  but  they  must  be
              within  the  tftp-root.  If  the  optional interface argument is
              given, the directory is only used for TFTP requests via that in-
              terface.

       --tftp-no-fail
              Do  not abort startup if specified tftp root directories are in-
              accessible.

       --tftp-unique-root[=ip|mac]
              Add the IP or hardware address of the TFTP client as a path com-
              ponent  on the end of the TFTP-root. Only valid if a --tftp-root
              is set and the directory exists.  Defaults to adding IP  address
              (in  standard dotted-quad format).  For instance, if --tftp-root
              is "/tftp" and client 1.2.3.4 requests file  "myfile"  then  the
              effective  path  will be "/tftp/1.2.3.4/myfile" if /tftp/1.2.3.4
              exists or /tftp/myfile otherwise.  When "=mac" is  specified  it
              will append the MAC address instead, using lowercase zero padded
              digits separated by dashes, e.g.:  01-02-03-04-aa-bb  Note  that
              resolving MAC addresses is only possible if the client is in the
              local network or obtained a DHCP lease from us.

       --tftp-secure
              Enable TFTP secure mode: without this, any file which  is  read-
              able  by  the  dnsmasq  process under normal unix access-control
              rules is available via TFTP.  When  the  --tftp-secure  flag  is
              given,  only files owned by the user running the dnsmasq process
              are accessible. If dnsmasq is being run as root, different rules
              apply:  --tftp-secure  has  no effect, but only files which have
              the world-readable bit set are accessible. It is not recommended
              to  run  dnsmasq  as  root  with TFTP enabled, and certainly not
              without specifying --tftp-root. Doing so can expose  any  world-
              readable file on the server to any host on the net.

       --tftp-lowercase
              Convert  filenames  in  TFTP  requests to all lowercase. This is
              useful for requests from Windows machines, which  have  case-in-
              sensitive  filesystems and tend to play fast-and-loose with case
              in filenames.  Note that dnsmasq's tftp server  always  converts
              "\" to "/" in filenames.

       --tftp-max=<connections>
              Set  the  maximum number of concurrent TFTP connections allowed.
              This defaults to 50. When serving a large number of TFTP connec-
              tions,  per-process  file  descriptor limits may be encountered.
              Dnsmasq needs one file descriptor for each concurrent TFTP  con-
              nection and one file descriptor per unique file (plus a few oth-
              ers). So serving the same file simultaneously to n clients  will
              use  require  about  n  + 10 file descriptors, serving different
              files simultaneously to n clients will require about (2*n) +  10
              descriptors.  If --tftp-port-range is given, that can affect the
              number of concurrent connections.

       --tftp-mtu=<mtu size>
              Use size as the ceiling of the MTU supported by the  intervening
              network when negotiating TFTP blocksize, overriding the MTU set-
              ting of the local interface  if it is larger.

       --tftp-no-blocksize
              Stop the TFTP server from  negotiating  the  "blocksize"  option
              with  a  client. Some buggy clients request this option but then
              behave badly when it is granted.

       --tftp-port-range=<start>,<end>
              A TFTP server listens on a well-known port (69)  for  connection
              initiation,  but  it  also uses a dynamically-allocated port for
              each connection. Normally these are allocated  by  the  OS,  but
              this  option  specifies  a range of ports for use by TFTP trans-
              fers. This can be useful when TFTP has to traverse  a  firewall.
              The  start of the range cannot be lower than 1025 unless dnsmasq
              is running as root. The number of concurrent TFTP connections is
              limited by the size of the port range.

       --tftp-single-port
              Run  in  a  mode  where the TFTP server uses ONLY the well-known
              port (69) for its end of the TFTP transfer. This allows TFTP  to
              work  when  there  in NAT is the path between client and server.
              Note that this is not strictly compliant with the RFCs  specify-
              ing the TFTP protocol: use at your own risk.

       -C, --conf-file=<file>
              Specify  a configuration file. The presence of this option stops
              dnsmasq from reading the default  configuration  file  (normally
              /etc/dnsmasq.conf). Multiple files may be specified by repeating
              the option either on the command line or in configuration files.
              A  filename  of  "-"  causes  dnsmasq to read configuration from
              stdin.

       -7, --conf-dir=<directory>[,<file-extension>......],
              Read all the files  in  the  given  directory  as  configuration
              files.  If  extension(s) are given, any files which end in those
              extensions are skipped. Any files whose names end in ~ or  start
              with . or start and end with # are always skipped. If the exten-
              sion starts with * then only files which have that extension are
              loaded.  So  --conf-dir=/path/to/dir,*.conf loads all files with
              the suffix .conf in /path/to/dir. This flag may be given on  the
              command  line  or  in  a configuration file. If giving it on the
              command line, be sure to escape * characters. Files  are  loaded
              in alphabetical order of filename.

       --servers-file=<file>
              A  special  case  of  --conf-file which differs in two respects.
              Firstly, only --server and --rev-server are allowed in the  con-
              figuration  file included. Secondly, the file is re-read and the
              configuration therein is updated when dnsmasq receives SIGHUP.

CONFIG FILE
       At startup, dnsmasq reads /etc/dnsmasq.conf, if it exists. (On FreeBSD,
       the  file is /usr/local/etc/dnsmasq.conf ) (but see the --conf-file and
       --conf-dir options.) The format of this file consists of one option per
       line,  exactly  as the long options detailed in the OPTIONS section but
       without the leading "--". Lines starting with # are  comments  and  ig-
       nored.  For options which may only be specified once, the configuration
       file overrides the command line.  Quoting is allowed in a config  file:
       between  " quotes the special meanings of ,:. and # are removed and the
       following escapes are allowed: \\ \" \t \e \b \r and \n. The later cor-
       responding to tab, escape, backspace, return and newline.

NOTES
       When  it  receives a SIGHUP, dnsmasq clears its cache and then re-loads
       /etc/hosts and /etc/ethers and  any  file  given  by  --dhcp-hostsfile,
       --dhcp-hostsdir,   --dhcp-optsfile,   --dhcp-optsdir,  --addn-hosts  or
       --hostsdir.  The DHCP lease change script is called  for  all  existing
       DHCP leases. If --no-poll is set SIGHUP also re-reads /etc/resolv.conf.
       SIGHUP does NOT re-read the configuration file.

       When it receives a SIGUSR1, dnsmasq writes  statistics  to  the  system
       log.  It  writes  the cache size, the number of names which have had to
       removed from the cache before they expired in order to  make  room  for
       new  names  and  the total number of names that have been inserted into
       the cache. The number of cache hits and misses and the  number  of  au-
       thoritative  queries  answered are also given. For each upstream server
       it gives the number of queries sent, and the number which  resulted  in
       an  error.  In --no-daemon mode or when full logging is enabled (--log-
       queries), a complete dump of the contents of the cache is made.

       The cache statistics are also  available  in  the  DNS  as  answers  to
       queries  of  class  CHAOS and type TXT in domain bind. The domain names
       are  cachesize.bind,  insertions.bind,   evictions.bind,   misses.bind,
       hits.bind,  auth.bind  and  servers.bind.  An  example command to query
       this, using the dig utility would be

       dig +short chaos txt cachesize.bind

       When it receives SIGUSR2 and it is logging direct to a file (see --log-
       facility ) dnsmasq will close and reopen the log file. Note that during
       this operation, dnsmasq will not be running as root. When it first cre-
       ates  the logfile dnsmasq changes the ownership of the file to the non-
       root user it will run as. Logrotate should be configured  to  create  a
       new  log  file with the ownership which matches the existing one before
       sending SIGUSR2.  If TCP DNS queries are in progress, the  old  logfile
       will  remain open in child processes which are handling TCP queries and
       may continue to be written. There is a  limit  of  150  seconds,  after
       which all existing TCP processes will have expired: for this reason, it
       is not wise to configure logfile compression for  logfiles  which  have
       just been rotated. Using logrotate, the required options are create and
       delaycompress.

       Dnsmasq is a DNS query forwarder: it is not capable of recursively  an-
       swering  arbitrary  queries starting from the root servers but forwards
       such queries to a fully recursive upstream DNS server  which  is  typi-
       cally provided by an ISP. By default, dnsmasq reads /etc/resolv.conf to
       discover the IP addresses of the upstream nameservers  it  should  use,
       since  the  information  is typically stored there. Unless --no-poll is
       used, dnsmasq checks the  modification  time  of  /etc/resolv.conf  (or
       equivalent  if  --resolv-file  is  used) and re-reads it if it changes.
       This allows the DNS servers to be set dynamically by PPP or DHCP  since
       both protocols provide the information.  Absence of /etc/resolv.conf is
       not an error since it may not have been created before a PPP connection
       exists.  Dnsmasq simply keeps checking in case /etc/resolv.conf is cre-
       ated at any time. Dnsmasq can be  told  to  parse  more  than  one  re-
       solv.conf file. This is useful on a laptop, where both PPP and DHCP may
       be used: dnsmasq can be  set  to  poll  both  /etc/ppp/resolv.conf  and
       /etc/dhcpc/resolv.conf  and  will use the contents of whichever changed
       last, giving automatic switching between DNS servers.

       Upstream servers may also be specified on the command line  or  in  the
       configuration  file.  These server specifications optionally take a do-
       main name which tells dnsmasq to use that server only to find names  in
       that particular domain.

       In  order to configure dnsmasq to act as cache for the host on which it
       is running, put "nameserver 127.0.0.1" in /etc/resolv.conf to force lo-
       cal  processes  to send queries to dnsmasq. Then either specify the up-
       stream servers directly to dnsmasq using --server options or put  their
       addresses real in another file, say /etc/resolv.dnsmasq and run dnsmasq
       with the --resolv-file /etc/resolv.dnsmasq option.  This  second  tech-
       nique allows for dynamic update of the server addresses by PPP or DHCP.

       Addresses  in /etc/hosts will "shadow" different addresses for the same
       names in the upstream DNS, so  "mycompany.com  1.2.3.4"  in  /etc/hosts
       will ensure that queries for "mycompany.com" always return 1.2.3.4 even
       if queries in the upstream DNS would otherwise return a  different  ad-
       dress.  There  is one exception to this: if the upstream DNS contains a
       CNAME which points to a  shadowed  name,  then  looking  up  the  CNAME
       through  dnsmasq  will result in the unshadowed address associated with
       the target of the  CNAME.  To  work  around  this,  add  the  CNAME  to
       /etc/hosts so that the CNAME is shadowed too.

       The  tag  system  works as follows: For each DHCP request, dnsmasq col-
       lects a set of valid tags from active configuration lines which include
       set:<tag>, including one from the --dhcp-range used to allocate the ad-
       dress, one from any matching --dhcp-host (and "known" or  "known-other-
       net"  if  a  --dhcp-host  matches) The tag "bootp" is set for BOOTP re-
       quests, and a tag whose name is the name of the interface on which  the
       request arrived is also set.

       Any  configuration lines which include one or more tag:<tag> constructs
       will only be valid if all that tags are  matched  in  the  set  derived
       above.  Typically  this is --dhcp-option.  --dhcp-option which has tags
       will be used in preference  to an untagged --dhcp-option, provided that
       _all_ the tags match somewhere in the set collected as described above.
       The  prefix  '!'  on  a  tag  means  'not'  so  --dhcp-option=tag:!pur-
       ple,3,1.2.3.4 sends the option when the tag purple is not in the set of
       valid tags. (If using this in a command line rather than  a  configura-
       tion file, be sure to escape !, which is a shell metacharacter)

       When  selecting --dhcp-options, a tag from --dhcp-range is second class
       relative to other tags, to make it easy to override options  for  indi-
       vidual    hosts,    so    --dhcp-range=set:interface1,......    --dhcp-
       host=set:myhost,.....       --dhcp-option=tag:interface1,option:nis-do-
       main,"domain1"     --dhcp-option=tag:myhost,option:nis-domain,"domain2"
       will set the NIS-domain to domain1 for hosts in the range, but override
       that to domain2 for a particular host.

       Note that for --dhcp-range both tag:<tag> and set:<tag> are allowed, to
       both select the range in use based on (eg) --dhcp-host, and  to  affect
       the options sent, based on the range selected.

       This  system evolved from an earlier, more limited one and for backward
       compatibility "net:" may be used instead of "tag:" and  "set:"  may  be
       omitted.  (Except  in  --dhcp-host, where "net:" may be used instead of
       "set:".) For the same reason, '#' may be used instead of '!'  to  indi-
       cate NOT.

       The  DHCP  server in dnsmasq will function as a BOOTP server also, pro-
       vided that the MAC address and IP address for clients are given, either
       using --dhcp-host configurations or in /etc/ethers , and a --dhcp-range
       configuration option is present to activate the DHCP server on  a  par-
       ticular  network.  (Setting --bootp-dynamic removes the need for static
       address mappings.) The filename parameter in a BOOTP request is used as
       a  tag,  as  is the tag "bootp", allowing some control over the options
       returned to different classes of hosts.

AUTHORITATIVE CONFIGURATION
       Configuring dnsmasq to act as an authoritative DNS  server  is  compli-
       cated  by  the  fact  that  it  involves  configuration of external DNS
       servers to provide delegation. We will walk through three scenarios  of
       increasing  complexity.  Prerequisites for all of these scenarios are a
       globally accessible IP address, an A or AAAA record  pointing  to  that
       address,  and an external DNS server capable of doing delegation of the
       zone in question. For the first part of this explanation, we will  call
       the A (or AAAA) record for the globally accessible address server.exam-
       ple.com, and the zone for which dnsmasq is authoritative our.zone.com.

       The simplest configuration consists of two lines of dnsmasq  configura-
       tion; something like

       --auth-server=server.example.com,eth0
       --auth-zone=our.zone.com,1.2.3.0/24

       and two records in the external DNS

       server.example.com       A    192.0.43.10
       our.zone.com            NS    server.example.com

       eth0  is  the external network interface on which dnsmasq is listening,
       and has (globally accessible) address 192.0.43.10.

       Note that the external IP address may well be dynamic (ie assigned from
       an  ISP  by DHCP or PPP) If so, the A record must be linked to this dy-
       namic assignment by one of the usual dynamic-DNS systems.

       A more complex, but practically useful configuration  has  the  address
       record  for the globally accessible IP address residing in the authori-
       tative zone which dnsmasq is serving, typically at  the  root.  Now  we
       have

       --auth-server=our.zone.com,eth0
       --auth-zone=our.zone.com,1.2.3.0/24

       our.zone.com             A    1.2.3.4
       our.zone.com            NS    our.zone.com

       The  A  record for our.zone.com has now become a glue record, it solves
       the chicken-and-egg problem of finding the IP address of the nameserver
       for  our.zone.com when the A record is within that zone. Note that this
       is the only role of this record: as dnsmasq is now  authoritative  from
       our.zone.com  it  too must provide this record. If the external address
       is static, this can be done with an /etc/hosts entry or --host-record.

       --auth-server=our.zone.com,eth0
       --host-record=our.zone.com,1.2.3.4
       --auth-zone=our.zone.com,1.2.3.0/24

       If the  external  address  is  dynamic,  the  address  associated  with
       our.zone.com  must  be  derived from the address of the relevant inter-
       face. This is done using --interface-name Something like:

       --auth-server=our.zone.com,eth0
       --interface-name=our.zone.com,eth0
       --auth-zone=our.zone.com,1.2.3.0/24,eth0

       (The "eth0" argument in --auth-zone adds the subnet  containing  eth0's
       dynamic  address  to the zone, so that the --interface-name returns the
       address in outside queries.)

       Our final configuration builds on that above, but also adds a secondary
       DNS  server.  This  is another DNS server which learns the DNS data for
       the zone by doing zones transfer, and acts as a backup should the  pri-
       mary  server become inaccessible. The configuration of the secondary is
       beyond the scope of this man-page, but the extra configuration of  dns-
       masq is simple:

       --auth-sec-servers=secondary.myisp.com

       and

       our.zone.com           NS    secondary.myisp.com

       Adding  auth-sec-servers enables zone transfer in dnsmasq, to allow the
       secondary to collect the DNS data. If you wish to restrict this data to
       particular hosts then

       --auth-peer=<IP address of secondary>

       will do so.

       Dnsmasq  acts as an authoritative server for  in-addr.arpa and ip6.arpa
       domains associated with the subnets given in --auth-zone  declarations,
       so  reverse  (address  to name) lookups can be simply configured with a
       suitable NS record, for  instance  in  this  example,  where  we  allow
       1.2.3.0/24 addresses.

        3.2.1.in-addr.arpa  NS    our.zone.com

       Note that at present, reverse (in-addr.arpa and ip6.arpa) zones are not
       available in zone transfers, so there is no point  arranging  secondary
       servers for reverse lookups.

       When  dnsmasq is configured to act as an authoritative server, the fol-
       lowing data is used to populate the authoritative zone.

       --mx-host, --srv-host, --dns-rr, --txt-record,  --naptr-record,  --caa-
       record, as long as the record names are in the authoritative domain.

       --cname  as long as the record name is in  the authoritative domain. If
       the target of the CNAME is unqualified, then it  is qualified with  the
       authoritative  zone  name.  CNAME  used in this way (only) may be wild-
       cards, as in

       --cname=*.example.com,default.example.com

       IPv4 and IPv6 addresses from /etc/hosts (and --addn-hosts ) and --host-
       record  and --interface-name provided the address falls into one of the
       subnets specified in the --auth-zone.

       Addresses of DHCP leases, provided the address falls into  one  of  the
       subnets  specified in the --auth-zone.  (If constructed DHCP ranges are
       is use, which depend on the address dynamically assigned to  an  inter-
       face, then the form of --auth-zone which defines subnets by the dynamic
       address of an interface should be used  to  ensure  this  condition  is
       met.)

       In  the  default  mode, where a DHCP lease has an unqualified name, and
       possibly a qualified name constructed using --domain then the  name  in
       the authoritative zone is constructed from the unqualified name and the
       zone's domain. This may or may not equal that  specified  by  --domain.
       If  --dhcp-fqdn  is set, then the fully qualified names associated with
       DHCP leases are used, and must match the zone's domain.

EXIT CODES
       0 - Dnsmasq successfully forked into the background, or terminated nor-
       mally if backgrounding is not enabled.

       1 - A problem with configuration was detected.

       2  - A problem with network access occurred (address in use, attempt to
       use privileged ports without permission).

       3 - A problem occurred with a filesystem operation (missing file/direc-
       tory, permissions).

       4 - Memory allocation failure.

       5 - Other miscellaneous problem.

       11  or  greater  -  a non zero return code was received from the lease-
       script process "init" call. The exit code from dnsmasq is the  script's
       exit code with 10 added.

LIMITS
       The default values for resource limits in dnsmasq are generally conser-
       vative, and appropriate for embedded router type devices with slow pro-
       cessors and limited memory. On more capable hardware, it is possible to
       increase the limits, and handle many more clients.  The  following  ap-
       plies to dnsmasq-2.37: earlier versions did not scale as well.

       Dnsmasq  is  capable  of  handling DNS and DHCP for at least a thousand
       clients. The DHCP lease times should not be very short (less  than  one
       hour).  The  value of --dns-forward-max can be increased: start with it
       equal to the number of clients and increase if  DNS  seems  slow.  Note
       that  DNS  performance  depends  too on the performance of the upstream
       nameservers. The size of the DNS cache may be increased: the hard limit
       is  10000  names  and the default (150) is very low. Sending SIGUSR1 to
       dnsmasq makes it log information which is useful for tuning  the  cache
       size. See the NOTES section for details.

       The  built-in  TFTP  server is capable of many simultaneous file trans-
       fers: the absolute limit is related to the number of  file-handles  al-
       lowed  to a process and the ability of the select() system call to cope
       with large numbers of file handles. If the limit is set too high  using
       --tftp-max it will be scaled down and the actual limit logged at start-
       up. Note that more transfers are possible when the same file  is  being
       sent than when each transfer sends a different file.

       It  is possible to use dnsmasq to block Web advertising by using a list
       of known banner-ad servers, all resolving to 127.0.0.1 or  0.0.0.0,  in
       /etc/hosts or an additional hosts file. The list can be very long, dns-
       masq has been tested successfully with one  million  names.  That  size
       file needs a 1GHz processor and about 60Mb of RAM.

INTERNATIONALISATION
       Dnsmasq  can  be  compiled to support internationalisation. To do this,
       the make targets "all-i18n" and "install-i18n" should be  used  instead
       of  the standard targets "all" and "install". When internationalisation
       is compiled in, dnsmasq will produce log messages in the local language
       and  support  internationalised  domain  names  (IDN).  Domain names in
       /etc/hosts, /etc/ethers and /etc/dnsmasq.conf which  contain  non-ASCII
       characters  will be translated to the DNS-internal punycode representa-
       tion. Note that dnsmasq determines both the language for  messages  and
       the  assumed  charset for configuration files from the LANG environment
       variable. This should be set to the system default value by the  script
       which  is responsible for starting dnsmasq. When editing the configura-
       tion files, be careful to do so using only  the  system-default  locale
       and not user-specific one, since dnsmasq has no direct way of determin-
       ing the charset in use, and must assume that it is the system default.

FILES
       /etc/dnsmasq.conf

       /usr/local/etc/dnsmasq.conf

       /etc/resolv.conf   /var/run/dnsmasq/resolv.conf    /etc/ppp/resolv.conf
       /etc/dhcpc/resolv.conf

       /etc/hosts

       /etc/ethers

       /var/lib/misc/dnsmasq.leases

       /var/db/dnsmasq.leases

       /var/run/dnsmasq.pid

SEE ALSO
       hosts(5), resolver(5)

AUTHOR
       This manual page was written by Simon Kelley <simon@thekelleys.org.uk>.

                                  2020-04-05                        DNSMASQ(8)

Man(1) output converted with man2html
list of all man pages