Make sure your router's DHCP server is disabled when using the Pi-hole DHCP server!
+
+
+
+
+
+
+
+
From
+
+
+
+
+
+
+
+
To
+
+
+
+
+
+
+
+
+
Router
+
+
+
+
+
+
+
Enable this option to enable IPv6 support for the Pi-hole DHCP server. This will allow the Pi-hole to hand out IPv6 addresses to clients and also provide IPv6 router advertisements (RA) to clients. This option is only useful if the Pi-hole is configured with an IPv6 address.
+
+
+
+
+
+
+
+
+
Advanced DHCP Settings
+
+
+
+
+
+
+
+
Domain
+
+
+
+
The DNS domains for the DHCP server. If no domain is specified, then any DHCP hostname with a domain part (i.e., with a period) will be disallowed. If a domain is specified, then hostnames with a domain parts matching the domain here are allowed. In addition, when a suffix is set then hostnames without a domain part have the suffix added as an optional domain part.
+
+
+
+
+
+
Lease time
+
+
+
+
The lease time can be in seconds, minutes (e.g., "45m"), hours (e.g., "1h"), days (like "2d"), or even weeks ("1w"). You may also use "infinite" as string but be aware of the drawbacks: assigned addresses are will only be made available again after the lease time has passed or when leases are manually deleted below.
+
+
+
+
The DHCPv4 rapid commit option allows the Pi-hole DHCP server to assign an IP address to a client right away. This can noteably speed up the address assignment process and you will notice, e.g., faster WiFi joins in your network. This option should only be enabled if the Pi-hole DHCP server is the only DHCP server in your network.
+
+
+
+
+
+
+
+
+
+
+
+
+
Currently active DHCP leases
+
+
+
+
+
+
+
+
+
IP address
+
Hostname
+
MAC address
+
Expiration
+
Client ID
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Static DHCP configuration
+
+
+
+
+
Specify per host parameters for the DHCP server. This allows a machine with a particular hardware address to be always allocated the same hostname, IP address and lease time. A hostname specified like this overrides any supplied by the DHCP client on the machine. 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.
+
+
Each entry should be on a separate line, and should be of the form:
tells Pi-hole to give the machine with hardware address 00:20:e0:3b:13:af the address 192.168.0.123
+
00:20:e0:3b:13:af,laptop
tells Pi-hole to give the machine with hardware address 00:20:e0:3b:13:af the name laptop
+
00:20:e0:3b:13:af,192.168.0.123,laptop,infinite
tells Pi-hole to give the machine with hardware address 00:20:e0:3b:13:af the address 192.168.0.123, the name laptop, and an infinite DHCP lease
+
+
+
+
+
+
+
Advanced description
+
+
+
+
+
+
+
Addresses allocated like this are not constrained to be in the DHCP range specified above but they must be in the same subnet. For subnets which don't need a pool of dynamically allocated addresses, you can set a one-address range above and specify only static leases here.
+
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 lines like id:01:02:03:04,..... refer to the host with client identifier 01:02:03:04. It is also allowed to specify the client ID as text, like this: id:clientidastext,.....
+
A single line may contain an IPv4 address or one or more IPv6 addresses, or both. IPv6 addresses must be bracketed by square brackets thus: laptop,[1234::56] IPv6 addresses may contain only the host-identifier part: laptop,[::56] in which case they act as wildcards in constructed DHCP ranges, with the appropriate network part inserted. For IPv6, an address may include a prefix length: 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 either 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.
+
+
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 separate line specifying the name also exists. Only one hostname can be given per line, but aliases are possible by using CNAMEs. Note that /etc/hosts is NOT used when the DNS server side of dnsmasq is disabled by setting the DNS server port to zero.
+
More than one line can be associated (by name, hardware address or UID) with a host. Which one is used (and therefore which address is allocated by DHCP and appears in the DNS) depends on the subnet on which the host last obtained a DHCP lease: the line with an address within the subnet is used. If more than one address is within the subnet, the result is undefined. A corollary to this is that the name associated with a host defined here does not appear in the DNS until the host obtains a DHCP lease.
+
The special keyword ignore tells Pi-hole to never offer a DHCP lease to a machine. The machine can be specified by hardware address, client ID or hostname, for instance 00:20:e0:3b:13:af,ignore. This is useful when there is another DHCP server on the network which should be used by some machines.
+
The set:<tag> construct sets the tag whenever this line is in use. This can be used to selectively send DHCP options just for this host. More than one tag can be set per line directive (but not in other places where "set:<tag>" is allowed). When a host matches any directive (or one implied by /etc/ethers) then the special tag "known"" is set. This allows Pi-hole to be configured to ignore requests from unknown machines using a custom config option dhcp-ignore=tag:!known in your own config file. If the host matches only a directive which cannot be used because it specifies an address on different subnet, the tag "known-othernet" is set.
+
The tag:<tag> construct filters which directives are used; more than one can be provided, in this case the request must match all of them. Tagged directives are used in preference to untagged ones. Note that one of <hwaddr>, <client_id> or <hostname> still needs to be specified (can be a wildcard).
+
Ethernet addresses (but not client-ids) may have wildcard bytes, so for example 00:20:e0:3b:13:*,ignore will cause Pi-hole to ignore a range of hardware addresses.
+
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 the line 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: 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 Pi-hole 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 instance, useful to allocate a stable IP address to a laptop which has both wired and wireless interfaces.
ECS (Extended Client Subnet) defines a mechanism for recursive resolvers to send partial client IP address information to authoritative DNS name servers. Content Delivery Networks (CDNs) and latency-sensitive services use this to give geo-located responses when responding to name lookups coming through public DNS resolvers. Note that ECS may result in reduced privacy.
+
+
+
+
+
Custom DNS servers
+
+
+
+
+
+
The following list contains all DNS servers selected above. Furthermore, you can add your own custom DNS servers here. The expected format is one server per line in form of IP#port, where the port is optional. If given, it has to be separated by a hash # from the address (e.g. 127.0.0.1#5335 for a local unbound istance running on port 5335). The port defaults to 53 if omitted.
+
+
+
+
+
+
+
+
+
+
+
+
+
Conditional forwarding
+
+
+
+
+
If not configured as your DHCP server, Pi-hole typically won't be able to
+ determine the names of devices on your local network. As a
+ result, tables such as Top Clients will only show IP addresses.
+
One solution for this is to configure Pi-hole to forward these
+ requests to your DHCP server (most likely your router), but only for devices on your
+ home network. To configure this we will need to know the IP
+ address of your DHCP server and which addresses belong to your local network.
+ Exemplary input is given below as placeholder in the text boxes (if empty).
+
If your local network spans 192.168.0.1 - 192.168.0.255, then you will have to input
+ 192.168.0.0/24. If your local network is 192.168.47.1 - 192.168.47.255, it will
+ be 192.168.47.0/24 and similar. If your network is larger, the CIDR has to be
+ different, for instance a range of 10.8.0.1 - 10.8.255.255 results in 10.8.0.0/16,
+ whereas an even wider network of 10.0.0.1 - 10.255.255.255 results in 10.0.0.0/8.
+ Setting up IPv6 ranges is exactly similar to setting up IPv4 here and fully supported.
+ Feel free to reach out to us on our
+ Discourse forum
+ in case you need any assistance setting up local host name resolution for your particular system.
+
You can also specify a local domain name (like fritz.box) to ensure queries to
+ devices ending in your local domain name will not leave your network, however, this is optional.
+ The local domain name must match the domain name specified
+ in your DHCP server for this to work. You can likely find it within the DHCP settings.
+
Enabling Conditional Forwarding will also forward all hostnames (i.e., non-FQDNs) to the router
+ when "Never forward non-FQDNs" is not enabled.
These options are dangerous on devices
+ directly connected to the Internet such as cloud instances and are only safe if your
+ Pi-hole is properly firewalled. In a typical at-home setup where your Pi-hole is
+ located within your local network (and you have not forwarded port 53
+ in your router!) they are safe to use.
Tells Pi-hole 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.
+ If Conditional Forwarding is enabled, unticking this box may cause a partial
+ DNS loop under certain circumstances (e.g. if a client would send TLD DNSSEC queries).
+
+
+
+
+
+
All reverse lookups for private IP ranges (i.e., 192.168.0.x/24, etc.)
+ which are not found in /etc/hosts or the DHCP leases are answered
+ with "no such domain" rather than being forwarded upstream. The set
+ of prefixes affected is the list given in RFC6303.
+
Important: Enabling these two options may increase your privacy,
+ but may also prevent you from being able to access
+ local hostnames if the Pi-hole is not used as DHCP server.
+
+
+
+
+
+
Validate DNS replies and cache DNSSEC data. When forwarding DNS
+ queries, Pi-hole requests the DNSSEC records needed to validate
+ the replies. If a domain fails validation or the upstream does not
+ support DNSSEC, this setting can cause issues resolving domains.
+ Use an upstream DNS server which supports DNSSEC when activating DNSSEC. Note that
+ the size of your log might increase significantly
+ when enabling DNSSEC. A DNSSEC resolver test can be found
+ here.
+
+
+
+
+
+
+
+
Rate-limiting
+
+
+
+
+
Block clients making more than queries within
+ seconds.
+
When a client makes too many queries in too short time, it
+ gets rate-limited. Rate-limited queries are answered with a
+ REFUSED reply and not further processed by FTL
+ and prevent Pi-holes getting overwhelmed by rogue clients.
+ It is important to note that rate-limiting is happening on a
+ per-client basis. Other clients can continue to use FTL while
+ rate-limited clients are short-circuited at the same time.
+
Rate-limiting may be disabled altogether by setting both
+ values to zero. See
+ our documentation
+ for further details.
ECS (Extended Client Subnet) defines a mechanism for recursive resolvers to send partial client IP address information to authoritative DNS name servers. Content Delivery Networks (CDNs) and latency-sensitive services use this to give geo-located responses when responding to name lookups coming through public DNS resolvers. Note that ECS may result in reduced privacy.
-
-
-
-
-
Custom DNS servers
-
-
-
-
-
-
The following list contains all DNS servers selected above. Furthermore, you can add your own custom DNS servers here. The expected format is one server per line in form of IP#port, where the port is optional. If given, it has to be separated by a hash # from the address (e.g. 127.0.0.1#5335 for a local unbound istance running on port 5335). The port defaults to 53 if omitted.
-
-
-
-
-
-
-
-
-
-
Conditional forwarding
-
-
-
-
-
If not configured as your DHCP server, Pi-hole typically won't be able to
- determine the names of devices on your local network. As a
- result, tables such as Top Clients will only show IP addresses.
-
One solution for this is to configure Pi-hole to forward these
- requests to your DHCP server (most likely your router), but only for devices on your
- home network. To configure this we will need to know the IP
- address of your DHCP server and which addresses belong to your local network.
- Exemplary input is given below as placeholder in the text boxes (if empty).
-
If your local network spans 192.168.0.1 - 192.168.0.255, then you will have to input
- 192.168.0.0/24. If your local network is 192.168.47.1 - 192.168.47.255, it will
- be 192.168.47.0/24 and similar. If your network is larger, the CIDR has to be
- different, for instance a range of 10.8.0.1 - 10.8.255.255 results in 10.8.0.0/16,
- whereas an even wider network of 10.0.0.1 - 10.255.255.255 results in 10.0.0.0/8.
- Setting up IPv6 ranges is exactly similar to setting up IPv4 here and fully supported.
- Feel free to reach out to us on our
- Discourse forum
- in case you need any assistance setting up local host name resolution for your particular system.
-
You can also specify a local domain name (like fritz.box) to ensure queries to
- devices ending in your local domain name will not leave your network, however, this is optional.
- The local domain name must match the domain name specified
- in your DHCP server for this to work. You can likely find it within the DHCP settings.
-
Enabling Conditional Forwarding will also forward all hostnames (i.e., non-FQDNs) to the router
- when "Never forward non-FQDNs" is not enabled.
These options are dangerous on devices
- directly connected to the Internet such as cloud instances and are only safe if your
- Pi-hole is properly firewalled. In a typical at-home setup where your Pi-hole is
- located within your local network (and you have not forwarded port 53
- in your router!) they are safe to use.
Tells Pi-hole 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.
- If Conditional Forwarding is enabled, unticking this box may cause a partial
- DNS loop under certain circumstances (e.g. if a client would send TLD DNSSEC queries).
-
-
-
-
-
-
All reverse lookups for private IP ranges (i.e., 192.168.0.x/24, etc.)
- which are not found in /etc/hosts or the DHCP leases are answered
- with "no such domain" rather than being forwarded upstream. The set
- of prefixes affected is the list given in RFC6303.
-
Important: Enabling these two options may increase your privacy,
- but may also prevent you from being able to access
- local hostnames if the Pi-hole is not used as DHCP server.
-
-
-
-
-
-
Validate DNS replies and cache DNSSEC data. When forwarding DNS
- queries, Pi-hole requests the DNSSEC records needed to validate
- the replies. If a domain fails validation or the upstream does not
- support DNSSEC, this setting can cause issues resolving domains.
- Use an upstream DNS server which supports DNSSEC when activating DNSSEC. Note that
- the size of your log might increase significantly
- when enabling DNSSEC. A DNSSEC resolver test can be found
- here.
-
-
-
-
-
-
-
-
Rate-limiting
-
-
-
-
-
Block clients making more than queries within
- seconds.
-
When a client makes too many queries in too short time, it
- gets rate-limited. Rate-limited queries are answered with a
- REFUSED reply and not further processed by FTL
- and prevent Pi-holes getting overwhelmed by rogue clients.
- It is important to note that rate-limiting is happening on a
- per-client basis. Other clients can continue to use FTL while
- rate-limited clients are short-circuited at the same time.
-
Rate-limiting may be disabled altogether by setting both
- values to zero. See
- our documentation
- for further details.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
DHCP Settings
-
-
-
-
-
-
Make sure your router's DHCP server is disabled when using the Pi-hole DHCP server!
-
-
-
-
-
-
-
-
From
-
-
-
-
-
-
-
-
To
-
-
-
-
-
-
-
-
-
Router
-
-
-
-
-
-
-
Enable this option to enable IPv6 support for the Pi-hole DHCP server. This will allow the Pi-hole to hand out IPv6 addresses to clients and also provide IPv6 router advertisements (RA) to clients. This option is only useful if the Pi-hole is configured with an IPv6 address.
-
-
-
-
-
-
-
-
-
Advanced DHCP Settings
-
-
-
-
-
-
-
-
Domain
-
-
-
-
The DNS domains for the DHCP server. If no domain is specified, then any DHCP hostname with a domain part (i.e., with a period) will be disallowed. If a domain is specified, then hostnames with a domain parts matching the domain here are allowed. In addition, when a suffix is set then hostnames without a domain part have the suffix added as an optional domain part.
-
-
-
-
-
-
Lease time
-
-
-
-
The lease time can be in seconds, minutes (e.g., "45m"), hours (e.g., "1h"), days (like "2d"), or even weeks ("1w"). You may also use "infinite" as string but be aware of the drawbacks: assigned addresses are will only be made available again after the lease time has passed or when leases are manually deleted below.
-
-
-
-
The DHCPv4 rapid commit option allows the Pi-hole DHCP server to assign an IP address to a client right away. This can noteably speed up the address assignment process and you will notice, e.g., faster WiFi joins in your network. This option should only be enabled if the Pi-hole DHCP server is the only DHCP server in your network.
-
-
-
-
-
-
-
-
-
-
-
-
-
Currently active DHCP leases
-
-
-
-
-
-
-
-
-
IP address
-
Hostname
-
MAC address
-
Expiration
-
Client ID
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Static DHCP configuration
-
-
-
-
-
Specify per host parameters for the DHCP server. This allows a machine with a particular hardware address to be always allocated the same hostname, IP address and lease time. A hostname specified like this overrides any supplied by the DHCP client on the machine. 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.
-
-
Each entry should be on a separate line, and should be of the form:
tells Pi-hole to give the machine with hardware address 00:20:e0:3b:13:af the address 192.168.0.123
-
00:20:e0:3b:13:af,laptop
tells Pi-hole to give the machine with hardware address 00:20:e0:3b:13:af the name laptop
-
00:20:e0:3b:13:af,192.168.0.123,laptop,infinite
tells Pi-hole to give the machine with hardware address 00:20:e0:3b:13:af the address 192.168.0.123, the name laptop, and an infinite DHCP lease
-
-
-
-
-
-
-
Advanced description
-
-
-
-
-
-
-
Addresses allocated like this are not constrained to be in the DHCP range specified above but they must be in the same subnet. For subnets which don't need a pool of dynamically allocated addresses, you can set a one-address range above and specify only static leases here.
-
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 lines like id:01:02:03:04,..... refer to the host with client identifier 01:02:03:04. It is also allowed to specify the client ID as text, like this: id:clientidastext,.....
-
A single line may contain an IPv4 address or one or more IPv6 addresses, or both. IPv6 addresses must be bracketed by square brackets thus: laptop,[1234::56] IPv6 addresses may contain only the host-identifier part: laptop,[::56] in which case they act as wildcards in constructed DHCP ranges, with the appropriate network part inserted. For IPv6, an address may include a prefix length: 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 either 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.
-
-
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 separate line specifying the name also exists. Only one hostname can be given per line, but aliases are possible by using CNAMEs. Note that /etc/hosts is NOT used when the DNS server side of dnsmasq is disabled by setting the DNS server port to zero.
-
More than one line can be associated (by name, hardware address or UID) with a host. Which one is used (and therefore which address is allocated by DHCP and appears in the DNS) depends on the subnet on which the host last obtained a DHCP lease: the line with an address within the subnet is used. If more than one address is within the subnet, the result is undefined. A corollary to this is that the name associated with a host defined here does not appear in the DNS until the host obtains a DHCP lease.
-
The special keyword ignore tells Pi-hole to never offer a DHCP lease to a machine. The machine can be specified by hardware address, client ID or hostname, for instance 00:20:e0:3b:13:af,ignore. This is useful when there is another DHCP server on the network which should be used by some machines.
-
The set:<tag> construct sets the tag whenever this line is in use. This can be used to selectively send DHCP options just for this host. More than one tag can be set per line directive (but not in other places where "set:<tag>" is allowed). When a host matches any directive (or one implied by /etc/ethers) then the special tag "known"" is set. This allows Pi-hole to be configured to ignore requests from unknown machines using a custom config option dhcp-ignore=tag:!known in your own config file. If the host matches only a directive which cannot be used because it specifies an address on different subnet, the tag "known-othernet" is set.
-
The tag:<tag> construct filters which directives are used; more than one can be provided, in this case the request must match all of them. Tagged directives are used in preference to untagged ones. Note that one of <hwaddr>, <client_id> or <hostname> still needs to be specified (can be a wildcard).
-
Ethernet addresses (but not client-ids) may have wildcard bytes, so for example 00:20:e0:3b:13:*,ignore will cause Pi-hole to ignore a range of hardware addresses.
-
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 the line 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: 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 Pi-hole 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 instance, useful to allocate a stable IP address to a laptop which has both wired and wireless interfaces.