HowTo Configure DHCP and DNS Servers

本文介绍如何在Linux系统上为sipX主机配置DHCP和DNS服务器,确保网络设备能够自动获取IP地址并进行域名解析。文章详细说明了安装、配置DHCP服务器及DNS服务器bind的过程,并介绍了如何设置动态DNS更新等功能。
 

HowTo Configure DHCP and DNS Servers

From SIPfoundry sipx, The Open Source SIP PBX for Linux - Calivia



HowTo Configure Linux DHCP and DNS Servers on the sipX Host

The sipX system needs properly configured DHCP and DNS servers to operate. If such servers do not already exist in your network, you might want to run them on the same host as the sipx system. This page describes how to setup Linux DHCP and DNS servers on the sipX host that will provide the required services to your network. Note that only one DHCP server can be authoritative per LAN segment.

Adding a mail server required for voicemail notification by email is described on this page: Configure sendmail for Email Notification of Voicemail.

This page initially is intended for Red Hat / Fedora users. We might add info for other distros later.

Note: SELinux has to be turned off for sipX, which means that the Fedora security policy for the named DNS server is turned off as well. You therefore should run named in a chroot jail, which we will do in a second step. Refer to man named.

You should not use the domain name "example.com" - you should register a real domain name; there are many ISPs and DNS providers that can help you with setting this up.

[ edit]

DHCP Server Configuration

Make sure the host on which you plan to install DHCP and DNS servers has a fixed IP address as well as a properly assigned host and domain name. In this example we use domain.com for the domain name and sipx for the hostname.


File: /etc/hosts
A host that was assigned a fixed IP address:
127.0.0.1 localhost.localdomain localhost
192.168.5.145 sipx.example.com sipx

Pick a suitable private address range for your internal LAN (If you don't know what they are use 192.168.1.x and a netmask of 255.255.255.0).

[ edit]

Installing the DHCP Server

We need the ISC DHCP server version 3, which is the default on FC4:

yum install dhcp
[ edit]

Configuring the DHCP Server

We configure the DHCP server for dynamic updating with the DNS server. The DHCP server has the ability to dynamically update the Domain Name System. Within the configuration files, you can define how you want the Domain Name System to be updated. These updates are RFC 2136 compliant so any DNS server supporting RFC 2136 should be able to accept updates from the DHCP server. The advantage of this scheme is that if a new host is connected and obtains its IP address, its name is automatically inserted into the DNS system, For security reasons a key is required to communicate between the DHCP and DNS servers. Refer to "man dhcpd.conf" for more information.


File: /etc/dhcpd.conf
 authoritative;              # No other DHCP servers on this subnet
ddns-update-style interim; # Supported update method - see man dhcpd.conf
ignore client-updates; # Overwrite client configured FQHNs

key rndckey { # Key for DNS updates
algorithm hmac-md5;
secret "JIjUPfT2GZZ172o5IdcK1Q=="; # Same as used for bind - see /etc/rndc.key
};

zone domain.com. { # Forward zone to be updated
primary 127.0.0.1;
key rndckey;
}

zone 5.168.192.in-addr.arpa. { # Backward zone to be updated
primary 127.0.0.1;
key rndckey;
}

subnet 192.168.5.0 netmask 255.255.255.0 {

range 192.168.5.200 192.168.5.250;
default-lease-time 21600;
max-lease-time 43200;

option routers 192.168.5.1; # Default gateway
option subnet-mask 255.255.255.0;
option domain-name "example.com";
option domain-name-servers 192.168.5.145; # loopback address does not work here

# option nis-domain "example.com";

option time-offset -18000; # Eastern Standard Time
option tftp-server-name "sipx.example.com"; # required for phones to pickup profiles

option ntp-servers 192.168.5.145;
# option netbios-name-servers 192.168.5.145;
# option netbios-node-type 8; # try WINS servers first, broadcast if necessary

# Example for resource reservations:
# host xyz {
# ddns-hostname "host.example.com"; # use for hosts that do not send a hostname
# hardware ethernet 12:34:56:78:AB:CD;
# fixed-address 192.168.5.x;
# }
}

Note: The key and the keyfile /etc/rndc.key is first generated with the rndc-confgen -a command (see DNS server configuration below). It needs to be manually copied into the /etc/dhcpd.conf file.

Note: For further information refer to man dhcpd.conf.

[ edit]

Starting the DHCP Server

/sbin/service dhcpd start

Add to runlevels: chkconfig --levels 235 dhcpd on. The leases database is in the file /var/lib/dhcp/dhcpd.leases.

[ edit]

DNS Server Configuration

The Linux DNS Server is called bind or named; we need version 9. It should already be installed on your system, which can be verified using rpm -q bind.

The following files need to be configured:

  • /etc/named.conf
  • /var/named/example.com.zone
  • /var/named/192.168.5.zone
  • /etc/resolv.conf
  • /etc/sysconfig/named
[ edit]

Generate Key required to exchange updates between DHCP and DNS

The tool rndc-confgen, using the -a option, can auto-generate the necessary keys as well as the configuration required by bind. It generates /etc/rndc.conf and /etc/rndc.key files. The key still needs to be manually inserted in the the DHCP configuration file /etc/dhcpd.conf.

rndc-confgen -a


File: Generated /etc/rndc.key file
 key "rndckey" {
algorithm hmac-md5;
secret "JIjUPfT2GZZ172o5IdcK1Q==";
};
[ edit]

The /etc/named.conf File

The following two sections were added automatically when running the rndc-confgen -a command:

controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
include "/etc/rndc.key";

The following two zone definitions were added manually:

zone "example.com" IN {
type master;
file "example.com.zone";
allow-update { key "rndckey"; };
notify yes;
};
zone "5.168.192.in-addr.arpa" {
type master;
file "192.168.5.zone";
allow-update { key "rndckey"; };
notify yes;
};

Optional: DNS Security

There are lots of options to secure access to the DNS resources on your LAN. The following provides some simple mechanisms.


File: Additions to /etc/named.conf
 // prevent zone transfers:
options {
allow-transfer {none;};
};

// restrict access:
acl "trusted-subnet" {192.168.5.0/24; };
[ edit]

The /var/named/example.com.zone File

;
; Zone file for domain.com
;

$TTL 3D
@ IN SOA ns1.example.com. root.example.com. (
200602132  ; serial#
3600  ; refresh, seconds
3600  ; retry, seconds
3600  ; expire, seconds
3600 )  ; minimum TTL, seconds

NS ns1.example.com.  ; Inet Address of nameserver
example.com. MX 10 mail  ; Primary Mail Exchanger
;
localhost A 127.0.0.1
sipx A 192.168.5.145  ; Record of class IN by default

_sip._udp SRV 100 1 5060 sipx
_sip._tcp SRV 200 1 5060 sipx
_sips._tcp SRV 300 1 5060 sipx

ns1 CNAME sipx
mail CNAME sipx

Note: If a name (hostname or domainname) is followed by a period "." nothing is appended. If there is no period, the domain name of the current context is automatically appended.

[ edit]

The /var/named/192.168.5.zone File

;
; Reverse zone file for domain.com
;

$TTL 3D
@ IN SOA ns1.example.com. root.example.com. (
200602132  ; serial#
3600  ; refresh, seconds
3600  ; retry, seconds
3600  ; expire, seconds
3600 )  ; minimum TTL, seconds

NS ns1.example.com.  ; Inet Address of nameserver
;
1 PTR localhost.
145 PTR sipx.example.com.

; Don't specify any reverse pointer records for addresses in the
; DHCP range. Dynamic updates will define those as necessary.
[ edit]

Change Zone File Ownership

In order for the named server to be able to update the zone files as it receives dynamic update requests from the DHCP server, it has to have write permission for all the zone files. If you created your zone files as root, you have to change permissions as follows:

cd /var/named
chown named:named *
[ edit]

Enable named to write Zone Files

If SELinux is disabled (required for sipX), then allow named to write its zone files and create files in its $ROOTDIR/var/named directory; this is necessary for dynamic updates (DDNS) and slave zone transfers.


File: /etc/sysconfig/named
# This line needs to be added 
ENABLE_ZONE_WRITE=yes
# This line enables the chroot and was configured automatically
ROOTDIR=/var/named/chroot
[ edit]

The /etc/resolv.conf File

search example.com
nameserver 127.0.0.1
[ edit]

Starting the DNS Server

/sbin/service named start

Add to runlevels: chkconfig --levels 235 named on.


Important note: Editing the Zone files while dynamic updates are active

When dynamic update is enabled for a zone, the zone can no longer be manually edited as normal. Attempting to do so may work in some cases, but will usually result in a name server error.

The DNS server keeps a journal (.jnl) file of incoming updates. The file is not automatically syncronized with the zone file, but can be forced with the "rndc stop" command. Extreme care has to be exercised when manually updating a zone subject to dynamic updates.

When using BIND 9.3 the following can be used, which does not require that named be stopped:

  1. rndc freeze example.com
2. edit the zone
3. rndc unfreeze example.com

Remember to increment the serial number in the zone file as you make changes.

[ edit]

Install the chroot Jail to run named in a Secure Environment

yum install bind-chroot

The bind-chroot RPM installs the necessary directory tree in /var/named/chroot and copies all the necessary configuration files from your existing non-chroot installation. The old files in /etc and /var/named are automatically replaced with symbolic links to the new locations.

Make sure that going forward you edit the configuration files in the chroot jail:

  • /etc/named.conf -> /var/named/chroot/etc/named.conf
  • /etc/rndc.conf -> /var/named/chroot/etc/rndc.conf
  • /etc/rndc.key -> /var/named/chroot/etc/rndc.key
  • /var/named/* -> /var/named/chroot/var/named/*

Starting named now should start it in the chroot environment. This can be verified by issuing ps aux | grep named. The named daemon should have been started with the -u and -t command line options (refer to man named).

The root directory (default: /var/named/chroot) got configured in the file /etc/sysconfig/named also during the installation process of the named-chroot RPM.

[ edit]

Configuring DHCP Clients

For dynamic DNS updates to work, the DHCP client has to send its hostname to the DHCP server. Windows typically does this, but lots of linux clients need to be told. If you use dhclient, make sure you have the following line in your /etc/dhclient-eth0.conf file (Ubuntu: This file is in /etc/dhcp3/dhclient.conf. Debian Sarge: Look in /etc/dhclient.conf). If the file does not exist, create it (i.e FC4). Only enter the hostname and not the FQHN and don't forget the ";".


File: /etc/dhclient-eth0.conf
send host-name "hostname";
[ edit]

Diagnostics

There are various ways how you can troubleshoot DHCP and DNS servers. All of the tools below have good man pages.

[ edit]

Check Configuration

named-checkconf
named-checkzone
[ edit]

Logs

Syslog:

tail -f /var/log/messages

Turn on logging for the named daemon:


File: /etc/named.conf or /var/named/chroot/etc/named.conf
 // add the following section. A log file "dns-security.log" will be created
// in the named directory
logging {
category dnssec { security_log; };
category update { security_log; };
category security { security_log; };

channel security_log {
file "dns-security.log" versions 5 size 20m;
// every time the log grows over 20 Mbyte, it will
// backup and rollover. Maximum 5 backups will be kept.
print-time yes;
print-category yes;
print-severity yes;
severity info;
};
};

Note: If logging is turned on as shown above all log messages will be in /var/named/chroot/var/named/dns-security.log and no longer in the syslog file.

[ edit]

Controlling named

The name server control utility rndc is used to control named while it is running. Please refer to man rndc for further details.

rndc
rndc reload
[ edit]

DNS Lookups

dig is a powerful utility to verify DNS settings. The option "AXFR" initiates a zone transfer that if allowed displays the currently active zone information for easy verification.

dig -x 127.0.0.1
dig yahoo.com
dig example.com AXFR

Other utilities include nslookup and host. Please refer to the respective man pages.

nslookup
host
{ // DHCPv4 configuration starts here. This section will be read by DHCPv4 server // and will be ignored by other components. "Control-agent": { "http-host": "localhost", "http-port": 8000 }, "Dhcp4": { "interfaces-config": { "interfaces": [ "enp3s0f0" ] }, "control-socket": { "socket-type": "unix", "socket-name": "/path/to/kea4-ctrl-socket" }, } "Dhcp4": { // Add names of your network interfaces to listen on. "interfaces-config": { // See section 8.2.4 for more details. You probably want to add just // interface name (e.g. "eth0" or specific IPv4 address on that // interface name (e.g. "eth0/192.0.2.1"). "interfaces": ["enp3s0f1/192.168.100.1"] // Kea DHCPv4 server by default listens using raw sockets. This ensures // all packets, including those sent by directly connected clients // that don't have IPv4 address yet, are received. However, if your // traffic is always relayed, it is often better to use regular // UDP sockets. If you want to do that, uncomment this line: // "dhcp-socket-type": "udp" }, // Kea supports control channel, which is a way to receive management // commands while the server is running. This is a Unix domain socket that // receives commands formatted in JSON, e.g. config-set (which sets new // configuration), config-reload (which tells Kea to reload its // configuration from file), statistic-get (to retrieve statistics) and many // more. For detailed description, see Sections 8.8, 16 and 15. "control-socket": { "socket-type": "unix", "socket-name": "kea4-ctrl-socket" }, // Use Memfile lease database backend to store leases in a CSV file. // Depending on how Kea was compiled, it may also support SQL databases // (MySQL and/or PostgreSQL). Those database backends require more // parameters, like name, host and possibly user and password. // There are dedicated examples for each backend. See Section 7.2.2 "Lease // Storage" for details. "lease-database": { // Memfile is the simplest and easiest backend to use. It's an in-memory // C++ database that stores its state in CSV file. "type": "memfile", "lfc-interval": 3600 }, // Kea allows storing host reservations in a database. If your network is // small or you have few reservations, it's probably easier to keep them // in the configuration file. If your network is large, it's usually better // to use database for it. To enable it, uncomment the following: // "hosts-database": { // "type": "mysql", // "name": "kea", // "user": "kea", // "password": "1234", // "host": "localhost", // "port": 3306 // }, // See Section 7.2.3 "Hosts storage" for details. // Setup reclamation of the expired leases and leases affinity. // Expired leases will be reclaimed every 10 seconds. Every 25 // seconds reclaimed leases, which have expired more than 3600 // seconds ago, will be removed. The limits for leases reclamation // are 100 leases or 250 ms for a single cycle. A warning message // will be logged if there are still expired leases in the // database after 5 consecutive reclamation cycles. // If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are // not 0, when the client sends a release message the lease is expired // instead of being deleted from the lease storage. "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 }, // Global timers specified here apply to all subnets, unless there are // subnet specific values defined in particular subnets. "renew-timer": 900, "rebind-timer": 60, "valid-lifetime": 3600, // Many additional parameters can be specified here: // - option definitions (if you want to define vendor options, your own // custom options or perhaps handle standard options // that Kea does not support out of the box yet) // - client classes // - hooks // - ddns information (how the DHCPv4 component can reach a DDNS daemon) // // Some of them have examples below, but there are other parameters. // Consult Kea User's Guide to find out about them. // These are global options. They are going to be sent when a client // requests them, unless overwritten with values in more specific scopes. // The scope hierarchy is: // - global (most generic, can be overwritten by class, subnet or host) // - class (can be overwritten by subnet or host) // - subnet (can be overwritten by host) // - host (most specific, overwrites any other scopes) // // Not all of those options make sense. Please configure only those that // are actually useful in your network. // // For a complete list of options currently supported by Kea, see // Section 7.2.8 "Standard DHCPv4 Options". Kea also supports // vendor options (see Section 7.2.10) and allows users to define their // own custom options (see Section 7.2.9). "option-data": [ // When specifying options, you typically need to specify // one of (name or code) and data. The full option specification // covers name, code, space, csv-format and data. // space defaults to "dhcp4" which is usually correct, unless you // use encapsulate options. csv-format defaults to "true", so // this is also correct, unless you want to specify the whole // option value as long hex string. For example, to specify // domain-name-servers you could do this: // { // "name": "domain-name-servers", // "code": 6, // "csv-format": "true", // "space": "dhcp4", // "data": "192.0.2.1, 192.0.2.2" // } // but it's a lot of writing, so it's easier to do this instead: { "name": "domain-name-servers", "data": "192.0.2.1, 192.0.2.2" }, // Typically people prefer to refer to options by their names, so they // don't need to remember the code names. However, some people like // to use numerical values. For example, option "domain-name" uses // option code 15, so you can reference to it either by // "name": "domain-name" or "code": 15. { "code": 15, "data": "example.org" }, // Domain search is also a popular option. It tells the client to // attempt to resolve names within those specified domains. For // example, name "foo" would be attempted to be resolved as // foo.mydomain.example.com and if it fails, then as foo.example.com { "name": "domain-search", "data": "mydomain.example.com, example.com" }, // String options that have a comma in their values need to have // it escaped (i.e. each comma is preceded by two backslashes). // That's because commas are reserved for separating fields in // compound options. At the same time, we need to be conformant // with JSON spec, that does not allow "\,". Therefore the // slightly uncommon double backslashes notation is needed. // Legal JSON escapes are \ followed by "\/bfnrt character // or \u followed by 4 hexadecimal numbers (currently Kea // supports only \u0000 to \u00ff code points). // CSV processing translates '\\' into '\' and '\,' into ',' // only so for instance '\x' is translated into '\x'. But // as it works on a JSON string value each of these '\' // characters must be doubled on JSON input. { "name": "boot-file-name", "data": "EST5EDT4\\,M3.2.0/02:00\\,M11.1.0/02:00" }, // Options that take integer values can either be specified in // dec or hex format. Hex format could be either plain (e.g. abcd) // or prefixed with 0x (e.g. 0xabcd). { "name": "default-ip-ttl", "data": "0xf0" } // Note that Kea provides some of the options on its own. In particular, // it sends IP Address lease type (code 51, based on valid-lifetime // parameter, Subnet mask (code 1, based on subnet definition), Renewal // time (code 58, based on renew-timer parameter), Rebind time (code 59, // based on rebind-timer parameter). ], // Other global parameters that can be defined here are option definitions // (this is useful if you want to use vendor options, your own custom // options or perhaps handle options that Kea does not handle out of the box // yet). // You can also define classes. If classes are defined, incoming packets // may be assigned to specific classes. A client class can represent any // group of devices that share some common characteristic, e.g. Windows // devices, iphones, broken printers that require special options, etc. // Based on the class information, you can then allow or reject clients // to use certain subnets, add special options for them or change values // of some fixed fields. "client-classes": [ { // This specifies a name of this class. It's useful if you need to // reference this class. "name": "voip", // This is a test. It is an expression that is being evaluated on // each incoming packet. It is supposed to evaluate to either // true or false. If it's true, the packet is added to specified // class. See Section 12 for a list of available expressions. There // are several dozens. Section 8.2.14 for more details for DHCPv4 // classification and Section 9.2.19 for DHCPv6. "test": "substring(option[60].hex,0,6) == 'Aastra'", // If a client belongs to this class, you can define extra behavior. // For example, certain fields in DHCPv4 packet will be set to // certain values. "next-server": "192.0.2.254", "server-hostname": "hal9000", "boot-file-name": "/dev/null" // You can also define option values here if you want devices from // this class to receive special options. } ], // Another thing possible here are hooks. Kea supports a powerful mechanism // that allows loading external libraries that can extract information and // even influence how the server processes packets. Those libraries include // additional forensic logging capabilities, ability to reserve hosts in // more flexible ways, and even add extra commands. For a list of available // hook libraries, see https://gitlab.isc.org/isc-projects/kea/wikis/Hooks-available. "hooks-libraries":[ { "library": "/usr/local/lib64/kea/hooks/libdhcp_macauth.so", "parameters": { "server_ip": "10.10.10.1", "ac_ip": "10.10.10.102", "port": 5001, "shared_secret": "7a5b8c3e9f" } }, { "library": "/usr/local/lib64/kea/hooks/libdhcp_lease_cmds.so" } //{ // "library": "/usr/local/lib64/kea/hooks/libdhcp_lease_query.so" // } ], // "hooks-libraries": [ // { // // Forensic Logging library generates forensic type of audit trail // // of all devices serviced by Kea, including their identifiers // // (like MAC address), their location in the network, times // // when they were active etc. // "library": "/usr/local/lib64/kea/hooks/libdhcp_legal_log.so", // "parameters": { // "base-name": "kea-forensic4" // } // }, // { // // Flexible identifier (flex-id). Kea software provides a way to // // handle host reservations that include addresses, prefixes, // // options, client classes and other features. The reservation can // // be based on hardware address, DUID, circuit-id or client-id in // // DHCPv4 and using hardware address or DUID in DHCPv6. However, // // there are sometimes scenario where the reservation is more // // complex, e.g. uses other options that mentioned above, uses part // // of specific options or perhaps even a combination of several // // options and fields to uniquely identify a client. Those scenarios // // are addressed by the Flexible Identifiers hook application. // "library": "/usr/local/lib64/kea/hooks/libdhcp_flex_id.so", // "parameters": { // "identifier-expression": "relay4[2].hex" // } // }, // { // // the MySQL host backend hook library required for host storage. // "library": "/usr/local/lib64/kea/hooks/libdhcp_mysql.so" // } // ], // Below an example of a simple IPv4 subnet declaration. Uncomment to enable // it. This is a list, denoted with [ ], of structures, each denoted with // { }. Each structure describes a single subnet and may have several // parameters. One of those parameters is "pools" that is also a list of // structures. "subnet4": [ { // This defines the whole subnet. Kea will use this information to // determine where the clients are connected. This is the whole // subnet in your network. // Subnet identifier should be unique for each subnet. "id": 1, // This is mandatory parameter for each subnet. "subnet": "192.168.30.0/24", // Pools define the actual part of your subnet that is governed // by Kea. Technically this is optional parameter, but it's // almost always needed for DHCP to do its job. If you omit it, // clients won't be able to get addresses, unless there are // host reservations defined for them. "pools": [ { "pool": "192.168.30.10 - 192.168.30.200" } ], // This is one of the subnet selectors. Uncomment the "interface" // parameter and specify the appropriate interface name if the DHCPv4 // server will receive requests from local clients (connected to the // same subnet as the server). This subnet will be selected for the // requests received by the server over the specified interface. // This rule applies to the DORA exchanges and rebinding clients. // Renewing clients unicast their messages, and the renewed addresses // are used by the server to determine the subnet they belong to. // When this parameter is used, the "relay" parameter is typically // unused. // "interface": "eth0", // This is another subnet selector. Uncomment the "relay" parameter // and specify a list of the relay addresses. The server will select // this subnet for lease assignments when it receives queries over one // of these relays. When this parameter is used, the "interface" parameter // is typically unused. // "relay": { // "ip-addresses": [ "10.0.0.1" ] // }, // These are options that are subnet specific. In most cases, // you need to define at least routers option, as without this // option your clients will not be able to reach their default // gateway and will not have Internet connectivity. "option-data": [ { // For each IPv4 subnet you most likely need to specify at // least one router. "name": "routers", "data": "192.0.2.1" } ], // Kea offers host reservations mechanism. Kea supports reservations // by several different types of identifiers: hw-address // (hardware/MAC address of the client), duid (DUID inserted by the // client), client-id (client identifier inserted by the client) and // circuit-id (circuit identifier inserted by the relay agent). // // Kea also support flexible identifier (flex-id), which lets you // specify an expression that is evaluated for each incoming packet. // Resulting value is then used for as an identifier. // // Note that reservations are subnet-specific in Kea. This is // different than ISC DHCP. Keep that in mind when migrating // your configurations. "reservations": [ // This is a reservation for a specific hardware/MAC address. // It's a rather simple reservation: just an address and nothing // else. // { // "hw-address": "1a:1b:1c:1d:1e:1f", // "ip-address": "192.0.2.201" // }, // This is a reservation for a specific client-id. It also shows // the this client will get a reserved hostname. A hostname can // be defined for any identifier type, not just client-id. { "client-id": "01:11:22:33:44:55:66", "ip-address": "192.168.30.202", "hostname": "special-snowflake" }, // The third reservation is based on DUID. This reservation defines // a special option values for this particular client. If the // domain-name-servers option would have been defined on a global, // subnet or class level, the host specific values take preference. { "duid": "01:02:03:04:05", "ip-address": "192.168.30.203", "option-data": [ { "name": "domain-name-servers", "data": "10.1.1.202, 10.1.1.203" } ] }, // The fourth reservation is based on circuit-id. This is an option // inserted by the relay agent that forwards the packet from client // to the server. In this example the host is also assigned vendor // specific options. // // When using reservations, it is useful to configure // reservations-global, reservations-in-subnet, // reservations-out-of-pool (subnet specific parameters) // and host-reservation-identifiers (global parameter). { "client-id": "01:12:23:34:45:56:67", "ip-address": "192.168.30.204", "option-data": [ { "name": "vivso-suboptions", "data": "4491" }, { "name": "tftp-servers", "space": "vendor-4491", "data": "10.1.1.202, 10.1.1.203" } ] }, // This reservation is for a client that needs specific DHCPv4 // fields to be set. Three supported fields are next-server, // server-hostname and boot-file-name { "client-id": "01:0a:0b:0c:0d:0e:0f", "ip-address": "192.168.30.205", "next-server": "192.168.30.1", "server-hostname": "hal9000", "boot-file-name": "/dev/null" }, // This reservation is using flexible identifier. Instead of // relying on specific field, sysadmin can define an expression // similar to what is used for client classification, // e.g. substring(relay[0].option[17],0,6). Then, based on the // value of that expression for incoming packet, the reservation // is matched. Expression can be specified either as hex or // plain text using single quotes. // // Note: flexible identifier requires flex_id hook library to be // loaded to work. { "flex-id": "'s0mEVaLue'", "ip-address": "192.168.30.206" } // You can add more reservations here. ] // You can add more subnets there. }, { "subnet": "192.168.100.0/24", "id":100, "pools": [ { "pool": "192.168.100.100 - 192.168.100.200" } ], "option-data": [ { "name": "routers", "data": "192.168.100.2" }, { "name": "domain-name-servers", "data": "8.8.8.8, 8.8.4.4" } ] }, { "subnet": "192.168.10.0/24", "id":10, "pools": [ { "pool": "192.168.10.100 - 192.168.10.200" } ], "relay": { "ip-addresses": ["192.168.10.1"] }, "option-data": [ { "name": "routers", "data": "192.168.10.1" }, { "name": "domain-name-servers", "data": "114.114.114.114,8.8.8.8" } ] }, { "id":20, "subnet": "192.168.20.0/24", "pools": [ { "pool": "192.168.20.100 - 192.168.20.200" } ], "relay": { "ip-addresses": ["192.168.20.1"] }, "option-data": [ { "name": "routers", "data": "192.168.20.1" }, { "name": "domain-name-servers", "data": "114.114.114.114, 8.8.4.4" } ] } ], // There are many, many more parameters that DHCPv4 server is able to use. // They were not added here to not overwhelm people with too much // information at once. // Logging configuration starts here. Kea uses different loggers to log various // activities. For details (e.g. names of loggers), see Chapter 18. "loggers": [ { // This section affects kea-dhcp4, which is the base logger for DHCPv4 // component. It tells DHCPv4 server to write all log messages (on // severity INFO or more) to a file. "name": "kea-dhcp4", "output-options": [ { // Specifies the output file. There are several special values // supported: // - stdout (prints on standard output) // - stderr (prints on standard error) // - syslog (logs to syslog) // - syslog:name (logs to syslog using specified name) // Any other value is considered a name of the file "output": "kea-dhcp4.log" // Shorter log pattern suitable for use with systemd, // avoids redundant information // "pattern": "%-5p %m\n", // This governs whether the log output is flushed to disk after // every write. // "flush": false, // This specifies the maximum size of the file before it is // rotated. // "maxsize": 1048576, // This specifies the maximum number of rotated files to keep. // "maxver": 8 } ], // This specifies the severity of log messages to keep. Supported values // are: FATAL, ERROR, WARN, INFO, DEBUG "severity": "INFO", // If DEBUG level is specified, this value is used. 0 is least verbose, // 99 is most verbose. Be cautious, Kea can generate lots and lots // of logs if told to do so. "debuglevel": 0 } ] } } 查看以上配置文件查看看dhcp配置接口开放配置有什么问题及语法错误并修复
最新发布
08-15
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值