​1

DDI Central User Guide

 ​2

Table of Contents
About ManageEngine DDI Central ​5

DDI Central Application Architecture ​6

System requirements ​7

Quick Installation Guide ​15

Installing DDI Central using custom ISO image ​28

Getting Started ​58

Adding Clusters ​58

Modes For Deploying Servers ​61

Adding Servers ​62

Configuring The SMTP Host ​69

Adding Users ​72

Creating Contact Groups ​80

Monitoring servers ​82

About DNS Management ​87

DNS Domain Migrations ​88

Creating Authoritative Zones ​89

 ​3

Creating Reverse Authoritative Zones ​95

Creating Forward Zones ​99

DNS Firewall(FRW) Response Policy Zones (RPZ) ​101

Managing DNS Resource Records ​105

Managing DNS Views ​112

Managing Dynamic Domains ​119

Domain Scavenging ​127

DNS64 ​134

DNS Security Management ​138

DNSSEC ​139

Response Rate Limiting (RRL) ​143

Domain Blocking Using DNS Firewall ​149

Configuring TSIG Keys ​153

Configuring ACL (Access Control List) ​156

DNS Query Analytics ​160

DNS Audit Logs ​164

About DHCP Management ​166

Managing DHCP Scopes ​167

 ​4

DHCP Fingerprinting With Client Classes ​178

DHCP Options ​190

Custom DHCP Options ​198

Configuring DHCP Failover 209

DHCP Scope Audit Logs ​215

About IP Address Management ​217

The IPAM Stats Dashboard ​218

Analyzing Lease and Lease History ​220

Managing VLAN IP Address Inventory ​224

Managing Network IP Address Inventory ​228

Appendix 1- DNS options ​230

Appendix 2- DHCPv4 options ​230

Appendix 3- DHCPv6 options ​231

Appendix 4- DHCP service options ​231

Apendix 5- Relay agent information options ​231

Appendix 6- Client FQDN options ​231

Appendix 7- Netware/IP suboptions ​231

 ​5

About ManageEngine DDI Central

ManageEngine DDI Central is an comprehensive and easy to use DNS, DHCP and, IP

Address Management (IPAM) application. It can be provisioned to manage both

internal and external DNS and DHCP clusters.

ManageEngine DDI Central helps you to discover and manage existing installation of

ISC-Bind9 and ISC-DHCP clusters. It can also be provisioned as new DNS and DHCP

clusters to manage the infrastructure. ManageEngine DDI Central has DNS and

DHCP bundled with the product and it gets deployed on your servers while installing

the product.
 ​6

DDI Central Application Architecture

Table of Contents

DDI Console 1

DDI Node Agent 1

ManageEngine DDI Central has two components DDI Console and DDI Node Agent
to be downloaded.

DDI Console
DDI Console provides centralized User Interface to manage all your DNS, DHCP
clusters and also helps to manage your IP address inventory.

DDI Node Agent

DDI Node Agent must be deployed on all your DNS and DHCP servers to ensure
continuous visibility of your DNS and DHCP clusters. It is a small light-weight agent
which communicates with the DDI Console and helps to discover the existing
 ​7

configuration and provision new configuration changes from the DDI Console.

System requirements
 ​8

Table of Contents

Hardware requirements for ManageEngine DDI Central Console - main server 1

Hardware requirements for ManageEngine DDI Central Node Agent server 2

Software Requirements 3

Software libraries required 3

Port Requirements 3

Database Requirements 4

Network Port Configurations 5

Hardware requirements for

 ​9

ManageEngine DDI Central Console -

main server
ManageEngine DDI Central Console server hardware requirements for discovering

and managing existing installation of ISC-DNS and ISC-DHCP is as follows:

Parameter Essential/Professional

Processor 2.4 GHz Quad Core

RAM 32 GB

HDD 500 GB

Operating System 64 bit

 ​10

Hardware requirements for

ManageEngine DDI Central Node Agent
server

ManageEngine DDI Central Node Agent is an small light-weight agent that has to be

installed on all your existing ISC-DNS and ISC-DHCP clusters.

Parameter Essential/Professional

Processor 2.4 GHz Quad Core

RAM 24 GB

HDD 500 GB

Operating System 64 bit

Software Requirements
 ​11

Version requirements for

Software Minimum versions required for Evaluation
Production

Ubuntu 14 to 20.04/ Red Hat

Ubuntu 14 to 20.04/ CentOS 7/ Fedora 31/ version 7 to 9.1/ CentOS Stream

Linux OS
Red Hat 7 to 9.1/ Debian 8/ CentOS 7/ Debian 10 and

above

Chrome (preferred)/ Firefox/

Browsers Chrome/ Firefox/ Edge
Edge

Software libraries required

1. Open SSL for secured network communication

2. Sudoers file for user authorizations

Port Requirements
 ​12

Port Name Default Port Protocol Usage Inbound

Numbers

Web server 9090 TCP This is the port on Inboud

port which you will

connect to the DDI

Central Console

server from a web

browser. You can

change this at any

time from the

Settings tab.

Embedded 33306 TCP This is the default N/A

database port port used to

connect to the

PostgreSQL

database in DDI
 ​13

HTTPS Port 9443 TCP This is port Bidirectional

through which DDI

Central node

Agent

communicates

with the console

and also used to

connect web

console

Database Requirements

PostgresSQL Comes bundled with the product.

Note: In case of failover, please use PostgresSQL that has replication configured.
 ​14

Network Port Configurations

To ensure the optimal performance and seamless operation of the DDI Central

solution, the following network port configurations are required:

1. DNS (Domain Name System)

● TCP and UDP Port 53: Must be open for DNS query and response

traffic. DNS uses this port for both TCP and UDP protocols to handle

standard query and response action, as well as zone transfers (TCP).

2. DHCP (Dynamic Host Configuration Protocol)

● UDP Port 67 (Primary DHCP): Must be open for receiving DHCP

discovery requests from DHCP clients. This is the standard port on

which the DHCP server listens for and responds to DHCP discovery

messages and other requests from clients.

● TCP Port 647 (DHCP Failover): Must be open to enable communication

between primary and secondary DHCP servers in a failover

configuration. This port is used for synchronization of DHCP lease

information and other configuration data to ensure continuity and

 ​15

consistency of DHCP services in case one of the servers becomes

unavailable.

These port configurations are essential to allow the DDI Central system to

communicate effectively within your network infrastructure. Ensure that any

firewalls or network security systems are configured to permit traffic on these ports

for the DDI Central solution's components.

Quick Installation Guide

Table of Contents

Installing DDI Console 2

Installing DDI Node Agent 2

DDI console mode installation 3

 ​16

Starting DDI Central 7

Accessing the Web Client 7

Licensing Information 8

License components in DDI 9

Upgrading your license 11

Note:

ManageEngine DDI is available only for Linux platforms. ManageEngine DDI can

be deployed as an overlay for your existing Linux DNS and DHCP environment

that supports Internet Systems Consortium : ISC DHCP and ISC BIND9 DNS.

Installing DDI Console

1. Download DDI Console for Linux

2. Assign execute permission using the command: chmod a+x

ManageEngine_DDI_Console_xxxx.bin where
 ​17

ManageEngine_DDI_Console_xxxx is the name of the downloaded BIN file.

3. Execute the following command as 'root'.

./ManageEngine_DDI_Console_xxxx.bin -i console

4. Follow the instructions as they appear on the screen to successfully install DDI

Console on to your machine.

Installing DDI Node Agent

1. Download DDI Node Agent for Linux

2. Assign execute permission using the command: chmod a+x

ManageEngine_DDI_Agent_xxxx.bin where ManageEngine_DDI_Agent_xxxx is

the name of the downloaded BIN file.

3. Execute the following command as 'root'.

./ManageEngine_DDI_Agent_xxxx.bin -i console

Follow the instructions as they appear on the screen to successfully install DDINode

Agent on to your machine.

 ​18

DDI console mode installation

This is a quick walk-through of the console mode installation of DDI on a Linux box -

an easy thing to do if you are working on a Windows box and want to install on a

remote Linux system.

Step 1: Execute the binary with administrator privileges (sudo) and -i console

option.
 ​19

Step 2: Go through the license agreement and enter 'Y' to proceed. You can register

for technical support by providing the required details. (Name, E-mail ID, Phone,

Company Name)
 ​20

Step 3: Select the location

Step 4: Choose the installation directory

Step 5: Configure the Webserver and Listener Ports.

 ​21

Step 6: Verify the installation details and press 'Enter' to complete the installation.
​22
 ​23

i.e

During installation if you get an error message stating that the temp folder does not have enough

space, try executing this command with the -is:tempdiroption, where is the absolute path of an

existing directory.

./ManageEngine_DDI_xxxx.bin -is:tempdir

For non-x11 machines, use the following command:

./ManageEngine_DDIr_xxxx.bin -i console

Starting DDI Central

Once the ManageEngine DDI Central installation is completed, you can start the

service by executing following command on your linux box

systemctl start DDI

To check whether service is started, execute the following command:

systemctl status DDI

After ensuring service is started successfully, you can connect the web client using

both http and https as follows

 ​24

http://server_ip:9090

https://server_ip:9443

Accessing the Web Client

Once the service has successfully started, follow the steps below to access DDI

Central.

1. Open a supported web browser window

2. Type the URL address as http://DDI_ConsoleServer_IP:9090(where DDI

Console Server is the name of the machine on which DDI Console Server is

running, and 9090 is the default web server port)

3. Log in to DDI using the default username/password combination of

admin/admin

Licensing Information
● Essential Edition
 ​25

Manage 1 DNS Cluster(3 servers max), 1 DHCP Cluster(2 Servers max), 5 DNS

Zones, 5 IP Subnet, 1 User, and IPAM. This is entry level edition with basic DNS,

DHCP and IP Address Management. Advanced features are available in

Professional edition.

● Professional Edition

Manage 1 DNS Cluster(3 servers max), 1 DHCP Cluster(2Servers max), 15 DNS

Zones, 15 IP Subnet, 2 Users, and IPAM.Advanced feature like Domain

Blocking, DHCP Fingerprinting, Audit, Query Analytics, etc.

License components in DDI Central

Clusters in ManageEngine DDI Central
Clusters are logical groupings of servers - DNS, DHCP or both organized for

identification and administrative purposes. These clusters operate independently of

other clusters configured within DDI Central. Each cluster you add has its own

internalized IP address plans, IP inventory, IP Address Manager, DNS manager and

DHCP manager.

A single cluster can accommodate any number of DNS servers and DHCP servers.
 ​26

However, ManageEngine DDI enables you to add only one Primary DHCP server for

each cluster and the rest of DHCP servers act secondary servers configured under

DHCP failover configurations.

Essential Plan:

The Essential plan includes one DNS cluster and one DHCP cluster. With the single

DNS cluster, you can add up to three DNS servers into the DDI Central console.

Similarly, the single DHCP cluster allows for the addition of up to two DHCP

servers.

These servers can be grouped together within a single cluster or distributed across

multiple clusters in any combination as per your preference. There is no restriction

on the number of clusters you can create.

Professional Plan:

The Professional plan provides two DNS clusters and two DHCP clusters. This way

you can add up to six DNS servers and four DHCP servers in total. You have the
 ​27

flexibility to organize these servers by grouping them into a single cluster or by

creating multiple clusters. You can configure the clusters in any combination that

suits your needs, with no limit on the number of clusters.

You can also purchase additional DNS clusters, DHCP clusters, subnets, zones, and

users as add-ons. Please refer the ManageEngine Store page to check the prices of

DDI Central add-ons.

Once installed, DDI Central runs in evaluation mode for 30 days. You can obtain a

registered license for DDI Central at any time during the evaluation period by

contacting DDI Central Support. If you have not upgraded to the Licensed Edition by

the end of the evaluation period, DDI Central evaluation license expires and you will

have only read-only access.

Upgrading your license

After obtaining the new license from ZOHO Corp, save it on your computer, and

follow the steps below to upgrade your DDI installation:

1. Log in to the DDI Central web client

 ​28

2. Click Admin logo/icon in the top right corner of the web client.

3. Click the Register link present in that pop-up page.

4. In the License window that opens up, browse for the new license file and

select it.

5. Click Register to apply for the new license file

Note : The new license is applied with immediate effect. You do not have to shut

down or restart the DDI Central server after the license is applied.

Installing DDI Central using custom ISO

image
Download the Debian ISO image of the custom Linux distribution that will help you

run ManageEngine DDI Central in any environment like Windows using your VM

software.

Prerequisites
Virtual machine software like: VirtualBox, VMware, Hyper V, and KVM

Installing the DDI Console

 ​29

1. Start the Virtual Machine with the Debian ISO image

● Boot up your virtual machine software (like VirtualBox or VMware).

● Start the VM configured with the Debian ISO image.

● You will be greeted with a boot menu similar to the image below. Choose Live

System (amd64) to begin the Debian installation process. This live ISO image

allows you to boot into a fully functional Debian environment without

installing it on your hard drive.

 ​30

2. Explore the live Debian environment

You will reach a desktop environment, where you will see an unlisted desktop

account. Click on it.

 ​31

This will take you to a different screen that will ask you for the Username. Enter the

username as root.

On entering the username, you'll be prompted to enter the password. Now, enter the

password provided by the DDI support team via a dedicated email sent for

downloading ISO image.

Note: The password sent via email is only temporary. You should reset it in the steps

to follow as you proceed.

 ​32

3. Start the installer from the live environment

On successful login, you can install Debian onto the virtual machine's hard drive by

locating and double-clicking the Install Debian icon on the desktop, as shown in the
 ​33

image below.

4. Welcome screen of the installer

 ​34

Now, the welcome screen of the Calamares installer appears. Here, choose the

installation language as American English and proceed by clicking Next.

 ​35

5. Set up location and timezone

Select your location and timezone from the respective dropdown menus and click

Next.
 ​36

6. Configure the keyboard

Choose your keyboard layout from the Keyboard Model dropdown menu. For an

English (US) keyboard, you should select English (US).

 ​37

7. Disk partitioning
 ​38

● On the partitioning screen, configure the partitioning of your disk. If you're

okay with wiping the entire virtual disk, select Erase disk. This will delete all

data and install Debian 12.

● Confirm that the bootloader is installed to the correct location, typically the

Master Boot Record (MBR) of the VM's virtual disk.

 ​39

8. Create a User Account

Create a user account. Fill in the desired username and password, which will be used
 ​40

to log into Debian after the installation. Click Next.

9. Review installation summary

The image below summarizes your choices. If all the details are correct, proceed by

clicking Install.
​41
 ​42

10. Completing the installation

As shown in the image below, the installation process will begin. The progress bar

will indicate how far along the installation is. Wait for it to complete. After the

installation process completes, you will usually be prompted to restart the VM.

Note: Upon reboot, ensure to remove the installation ISO from the VM's settings to

avoid booting into the live environment again.

 ​43

11. Post-installation steps

Once Debian is installed, you can login to your new user account with the username
 ​44

and password from Step 8.

12. Installing and configuring your application

 ​45

After successfully installing Debian, you can now set up ManageEngine DDI Central

on your system. Open the terminal window.

 ​46

13. Reset the root password

On the terminal window, reset the temporary root password from Step 2 following

the steps below.

● Gain SuperUser access by entering the command sudo su to switch to the root

user. You will be prompted to enter the password for your current user (the

one with sudo privileges).

● Once you are logged in as root, reset the root password by typing the

command passwd. You will then be prompted to enter a new root password.

● After entering passwd, you’ll be asked to enter the new password twice to

confirm.

14. Access the Application Installation Directory

● Navigate to the directory where your application's .bin files are located

using the cd command in the terminal.

● cd /opt/ManageEngine/ddi/bin/
 ​47

15. Change file permissions

You might need to change the permissions of the scripts to make them executable.

This can be done using the chmod command.

 ​48

Note: Use the chmod command as specified below, introducing a / (slash) anywhere

within the chmod command would yield errors.

chmod 777 *

This command grants read, write, and execute permissions of all files in the current

directory.
 ​49

16. Run the installation script

● Execute the command - sh PostInstallation.sh 9090 9443

● This executes a shell script named PostInstallation.sh with two arguments, 9090

and 9443, which are http and https port numbers that the script needs to
 ​50

configure the application to.

● Wait till the script is run completely.

If you encounter errors, you can seek support from the ddi-support team.

17. Start the application services

Once the installation is complete and all configurations are set, start the application

services. Use the command systemctl for this purpose: systemctl start DDI
 ​51

18. Verify network configuration

● Use the ifconfig network command to view the configuration of network

interfaces and IP addresses. From the response generated, the IP address near

inet shows the IPv4 address assigned to the interface. This is the ip address

that is used to run the DDI application using the web browser.
 ​52

● The netmask indicates the network mask for the IP address, defining which

portion of the address is the network and which part is the host.

Note: Make sure that the correct ports are open and listening for the application to

communicate over the network.

19. Final verification

● Ensure that the application is running by accessing its web GUI through the

browser.

● Example: Using the IPv4 address and the port number from the image. DDI

application can be accessed using anyone of the following urls:

http://172.21.252.47:9090/ or http://172.21.252.47:9443/

● Test the functionalities of the application to confirm that it is operating as

expected.

Installing the DDI Node Agent

Follow the same steps from Step 1 through Step 13 to install DDI agent onto each of
 ​53

DNS and DHCP servers.

Note: DDI Console and DDI Node Agent cannot run in the same machine.Please

ensure to install DDI Node Agent in a different machine you want to manage.

Now for the further steps

14. Access the Application Installation Directory

Navigate to the directory where your application's .bin files are located using the cd

command in the terminal.

cd /opt/ManageEngine/ddiagent/bin/
 ​54

15. Change file permissions

You might need to change the permissions of the scripts to make them executable.

This can be done using the chmod command.

Note: Use the chmod command as specified below, introducing a / (slash) anywhere
 ​55

within the chmod command would yield errors.

chmod 777 *

This command grants read, write, and execute permissions of all files in the current

directory.
 ​56

16. Run the installation script

● Execute the command - sh PostInstallation.sh 9090 9443

● This executes a shell script named PostInstallation.sh with two arguments, 9090

and 9443, which are http and https port numbers that the script needs to

configure the application to.

● Wait till the script is run completely.

If you encounter errors, you can seek support from the ddi-support team.

17. Start the application services

Once the installation is complete and all configurations are set, start the application

services. Use the command systemctl for this purpose: systemctl start DDI
 ​57

18. Verify network configuration

● Use the ifconfig network command to view the configuration of network

interfaces and IP addresses. From the response generated, the IP address near

inet shows the IPv4 address assigned to the interface. This is the ip address

that is used to run the DDI application using the web browser.
 ​58

● The netmask indicates the network mask for the IP address, defining which

portion of the address is the network and which part is the host.

Note: Make sure that the correct ports are open and listening for the application to

communicate over the network.

Getting Started
To get started with ManageEngine DDI Central,

Execute the following steps in the order given below

1. Add Clusters

2. Add Servers

3. Add Users (optional)

4. Configure an SMTP server

5. Add Contact Groups (optional)

Adding Clusters
Upon successful signup, the first glimpse within the DDI Central UI reveals an empty
 ​59

dashboard. To get started, create clusters and add your DNS and DHCP servers to

your clusters for effective management of your network infrastructure.

To create new clusters

● Click on the plus ( + ) sign at the top right corner.

● The Add Cluster window appears prompting you to enter the name and type

of the cluster: DNS, DHCP or Both.

 ​60

● Clusters are logical groupings of servers - DNS, DHCP or both organized for

identification and administrative purposes. These clusters operate

independently of other clusters configured within DDI Central. Each cluster

you add has its own internalized IP address plans, IP inventory, IP Address

Manager, DNS manager and DHCP manager. A single cluster can

accommodate any number of DNS servers and DHCP servers.

● After making the necessary selection, click Save to create the cluster.
 ​61

Once the cluster is created you will be directed to the servers page where you'll be

prompted to add your DNS and DHCP servers.

Modes For Deploying Servers

DDI Central server incorporation modes

Servers can be added to the DDI Clusters using the Discovery mode or can be set up

as new servers from the scratch.

DDI Central as an overlay

Enable DDI Central to seamlessly discover and integrate your on-premises

infrastructure's complete DNS-DHCP server configurations, including the entire IP

address footprint, into the intuitive DDI Central console interface.

DDI Central as a DNS-DHCP-IPAM service provider

As ManageEngine DDI Central is bundled with DNS and DHCP services you can set
 ​62

up new servers, enable ManageEngine DDI Central to implement, configure, and

manage DNS, DHCP and IPAM services on your network infrastructure from scratch

as you install

Core to periphery DDI

Deploy DDI Central flexibly to manage both your on-premises internal and external

DNS-DHCP cluster of servers that are accessible via VPN, point-to-point

connections, private networks connected via MPLS(Multiprotocol Label Switching)

services offered by ISPs, and SD-WANs.

Note: ManageEngine DDI Central only supports Internet Systems Consortium

(ISC)'s ISC DHCP and BIND9 DNS servers.

Adding Servers

Table of Contents

Creating Servers

Advanced DNS-DHCP-IP address discovery 3

 ​63

Setting up servers through DDI Central 5

App Console Details 5

Creating Servers

Once the cluster is created, you'll be immediately directed to the Servers

page to add your DNS and DHCP servers. If not, you can add servers by

selecting the Settings menu from the menu bar along the left side of the

screen. From the submenus that appear in parallel, choose Servers.

● On the Servers page, click the Add Server button on the top left

corner.

● The Create Server page appears on the screen. Here, you can add your

DNS-DHCP servers either by discovering existing server configurations

or by simply adding the server to the DDI Central console and configure

it using the DDI Central user interface at later stages.

 ​64

Enter the server details like

1. SERVER NAME: A required field where you assign a unique name to the server

being configured or added for identification.

Note: No two servers in the same or different clusters can have the same

name.

2. TYPE: Select the type of server being set up, such as DNS, DHCP, or both
 ​65

(server that is configured for both DNS and DHCP services).

3. SERVER IP: Specify the IP address of the server being added.

4. AGENT HTTP PORT: Specify the port number used by the DDI Central Node

Agent installed in the server for HTTP connections.

5. AGENT HTTPS PORT: Specify the port number used by the DDI Central Node

Agent installed in the server for HTTPS connections.

6. DISCOVER EXISTING CONFIGURATIONS?: You have two choices to make

here; opt for Step 7 or Step 8 depending on your requirement.

Step 7 -> Advanced DNS-DHCP-IP address discovery

Specify any one of the options :DNS, DHCP, or Both to discover all the

existing configurations from the server, or

Step 8 -> Adding and configuring servers using DDI Central

Specify No if you just want to add and setup a new server from the scratch.

You can setup the required DNS, DHCP or combined configurations to your

server to get it configured through the user-friendly DDI Central user interface

later.

Advanced DNS-DHCP-IP address

discovery
 ​66

7. To discover all the advanced configurations of DNS-DHCP services, the whole

IP address plan and the current IP address inventory

Choose any one of the three options: DNS, DHCP, Both, for the Discover

Existing Configurations?

Note: Selecting either DNS or DHCP will result in the discovery of only the

DNS or DHCP configurations, respectively, from the server.

When discovering a DNS server with DDNS-enabled domains, ensure that

both DNS and DHCP servers are discovered at the same time for DDI Central

to capture the combined configurations. Similarly, while discovering DHCP

servers that provision IP addresses for dynamic domains, it is essential to

discover the corresponding DNS servers as well.

 ​67

Provide the essential Config Path and the Zone File path for the DNS servers,

while providing the Lease Path and the DHCP server path for the DHCP

servers.

Setting up servers through DDI Central

8. You can add new servers to DDI Central console and enable ManageEngine
 ​68

DDI Central to implement, configure, and manage DNS, DHCP and IPAM

services on your network infrastructure from scratch.

As DDI Central has DNS and DHCP bundled with the product and it gets

deployed on your servers while installing the product.

For this, you'll have to choose No for Discover Existing Configurations?

option.

App Console Details

9. APP CONSOLE: Enter the static IP address of the central server that hosts the

DDI Central application console associated with this server.

Note: It is crucial that this IP address remains constant to maintain consistent

connection between the central DDI Central console server and the Node

Agents installed in all your DNS and DHCP servers.

10.HTTP PORT: Specify the port number of the central DDI Central application

console server for HTTP connections.

11. HTTPS PORT: Specify the port number of the central DDI Central application

console server for HTTPS connections.

 ​69

12. Click Save to add the server into the ME DDI Central console.

If you have chosen the discovery option as outlined in Step 7, ManageEngine

DDI Central will begin to discover configurations from the designated paths

for each service.

Note: The discovery process takes a considerable amount of time depending

on the volume of configurations in the servers. Wait until the whole process

completes.

Once you add your server into the DDI Central console you can further

proceed modifying the discovered DNS-DHCP-IPAM configurations or quickly

start setting up the DNS-DHCP-IPAM configurations for the new server

through the user-friendly DDI Central user interface.

Configuring The SMTP Host

DDI Central Admins can configure to send email using a particular SMTP host.
 ​70

● Provide an SMTP username and password for the authentication of email

notifications. This is optional; you can enable or disable it anytime.

● Configure the SMTP host, sender address, and optional username and

password.

1. PROTOCOL: Choose the encryption protocol for SMTP communication:

either TLS (Transport Layer Security) or SSL (Secure Sockets Layer), both of

which ensure that email communications are encrypted for security.

 ​71

2. HOST: Provide the FQDN(Fully Qualified Domain Name) of your mail server in

the following format: hostname. domain. tld

3. PORT: The port number used for SMTP connections. It's set to 587 for TLS, 465

for SSL. If no encryption protocol is chosen the port number switches to the

traditional SMTP port 25.

Note: Port 25 does not imply any encryption and is often used for relaying

emails across servers. Due to its lack of security features, it's generally not

recommended for submitting emails from clients to servers. Additionally,

many ISPs block outgoing connections on port 25 to reduce spam.

4. FROM ADDRESS: A valid sender email address DDI uses to send mails incase

of password recovery and other notifications.

5. AUTHENTICATION: A toggle switch, which can enable or disable the

authentication required for sending emails through this SMTP host.

6. USERNAME: The username for authenticating with the SMTP host, often the

same as the email address.

7. PASSWORD: The password required for SMTP authentication.

To start the email notification service and subscribe to notifications pertaining to a

 ​72

cluster, set up a Contact group under the cluster by selecting Settings-> Contact

groups.

Adding Users

To add users as an admin:

● Select Settings->Users.

● Under the User Management tab, click on the Add User button in the right

corner.
 ​73

● Enter the essential details of the user, including Name, Username, email, and

password. You can enable or disable the login for this particular user. Set Yes

to enable the login. Enable the TOTP login for the user to add an extra layer of

security.

● Finally, Assign the appropriate role for the user.

● DDI Central provides two roles: Admin and Operator. The Admin role has

unrestricted access, while the Operator role has limited access, which can be

extended by granting specific permissions for each cluster or zone as needed.

● Click Save.
 ​74

● Provide the Username, Password, and URL for the other users you've added.

Make sure they login using the URL from their web browser.

● Once they login they'll be prompted to reset their password and login to the

DDI Central system.

● Enabling Two-factor authentication for the users

DDI Central enhances user account security by mandating two-factor

authentication (2FA) for all users associated with your organization. This

additional security layer requires verification through a time-sensitive code

generated by a compatible mobile authenticator application. The

following steps outline the 2FA process.

1. Users need a mobile device capable of running a TOTP-enabled

authenticator mobile app.

2. ManageEngine DDI Central is compatible with various mobile

authenticator apps, including Google Authenticator, Zoho's OneAuth,

Authy, and others.

3. Install your chosen authenticator app on your smartphone.

4. Link DDI Central to the authenticator app either by scanning the QR

 ​75

secret code displayed on the DDI Central login page or by entering the

code manually. This is a one-time process.

5. On subsequent logins, enter the TOTP displayed in your authenticator

app. The OTP adds an extra layer of security and can be generated

without an internet connection.

6. Upon first accessing DDI Central, all users except the Admin who

managed the installation process will need to reset their password.

This two-factor authentication approach ensures that access to DDI Central

accounts is secure, combining something the user knows (their password) with

something they have (a TOTP from the authenticator app).

User permissions

Admin can Operator can

-
Create, update, and delete user
 ​76

Add, update, and delete zones Update zone if operator has zone

permission

Create update and delete cluster -

Giving cluster and zone permission to -

the operator

Add, update, and delete servers -

Add SMTP details -

Able to see login and logout details of -

the user

Able to see DHCP and DNS audit report -

Reset client credentials Reset client credentials

 ​77

Enable TOTP for an user -

Delete TOTP device -

Add, update, and delete records in zone Add, update, and delete records in zone

if the operator has zone permission

Add, update, and delete named options Add, update, and delete named options

if the operator has cluster permission

Add, update and delete dhcp options Add, update and delete dhcp options if

operator has cluster permission

Add, update, and delete custom options Add, update, and delete custom options

if the operator has cluster permission

Add, update, and delete subnet, shared Add, update and delete subnets, shared

network, client class, host, host group network, client classes, host, host group

and vlan and vlan if the operator has cluster

 ​78

permission

Add, update and delete supernet Add, update and delete supernet if

operator has cluster permission

Add, update, and delete failover Add, update, and delete failover if the

configurations operator has cluster permission

Enable, add, update, and delete named update named_view if operator has

views cluster permission

Add, update and delete DHCP Zone Add, update, and delete DHCP Zone if

operator has cluster permission

Add, update, and delete records in Update view if operator has zone
 ​79

views permission

User Audits
The User Audit tab can be accessed by selecting the Audit menu from the left

menu bar. The User audit tab helps you monitor your users' login activities by

capturing the username, date, and timestamp of the latest login activities.
 ​80

Creating Contact Groups

DDI Central enables you to group specific users under your organization to create

special contact groups. You can associate the relevant contact group to be notified

of alerts or incidences concerning that domain and associated monitor.

To create a contact group

1. Select Contact from the left menu bar. In the Contact page, under the

Contact Groups tab, CloudDNS displays the list of contact groups created

under the organization.

2. Click on the Add Group button to create a new contact group.

 ​81

3. Enter the details of the group, like the group name.

4. For the group email, add the list of email ids of the members to send

notifications to, one by one, and click Add after each selection.

5. Select the required clusters one by one and click the Add button after each

selection. Click Save.

6. On successful association, the Contact Group tab on the Contact page

displays the list of members in the Contact Group as well as the list of

Associated Clusters.

7. To dissociate any cluster or contact from the Contact Group, click on the Edit
 ​82

button on the extreme right. From the Edit Group window, deselect the email

ids or the clusters using the minute close button at the top right corner of

each selection.

Monitoring servers

To monitor the load and performance of your DNS and DHCP servers:

Select Settings-> Servers . The Servers page appears listing the servers added.

First it displays the status of the DNS, DHCP4, and DHCP6 services of the cluster.
​83
 ​84

DDI Central also gives a visual snapshot of a different part of your server's load,

health and performance. CPU, memory, and disk percentages of your server

represent different aspects of the server's system resource usage, each playing a

unique role in the server's overall performance. Understanding the differences

between them can help diagnose performance issues or guide system upgrades.

1. CPU Percentage
 ​85

● The CPU (Central Processing Unit) percentage indicates how much of

the CPU's processing power is being used. It reflects the workload

being processed by the CPU of your server at any given moment.

● Implications: A high CPU percentage can mean the processor is

handling a lot of tasks simultaneously or dealing with a few very

demanding tasks. If the CPU usage is consistently high, the server

might slow down or become unresponsive, especially if it's attempting

to process more data than it can handle efficiently.

2. Memory (RAM) Percentage

● The memory percentage refers to the proportion of the computer's

RAM (Random Access Memory) that is currently in use. RAM is used to

store data and program instructions needed immediately or shortly by

the CPU.

● Implications: High memory usage indicates that a large amount of the

system's RAM is being used. If the server runs out of RAM, it starts using

disk space as virtual memory, which is much slower. Excessive memory

usage can slow down the system, cause programs to respond more

slowly, and may lead to system instability.

3. Disk Usage Percentage:

 ​86

● Definition: Disk usage percentage shows how actively the server's hard

drive (or SSD) is being read from or written to. It’s different from disk

capacity, which refers to how much data is stored on the disk.

● Implications: High disk activity can indicate that a lot of data is being

transferred to and from the storage device. This could be due to various

reasons, like file copying, intensive read/write operations by

applications, or because the server is using the disk for virtual memory.

Prolonged high disk usage can slow down the server, as the disk is

generally the slowest component in terms of data access.

For optimal performance, it's crucial to have a balanced server where no single

resource consistently becomes a bottleneck. For example, a powerful CPU can be

underutilized if the server doesn't have enough RAM or if the disk is too slow to

provide data quickly. Similarly, having a lot of RAM is less useful if the CPU isn't fast

enough to process the data held in the RAM, or if the disk is too slow to load new

data into the RAM efficiently. Regular monitoring of these percentages can help in

identifying and resolving performance bottlenecks in a computer system.

 ​87

About DNS Management

Domain Name System (DNS) Management refers to the process of translating

human-readable domain names (like ddi.manageengine.com) into IP addresses that

computers use to communicate with each other. Efficient DNS management is

crucial for ensuring that websites and online services are accessible, reliable, and

secure. It involves tasks like configuring DNS records (such as A, AAAA, CNAME, MX

records), managing domain names, setting up reverse DNS, and ensuring DNS

security with configurations like DNSSEC, domain views, Response Policy

Zones(RPZ) and more.

Organizations often use DNS management tools or services to streamline these

tasks, handle large volumes of DNS traffic, and protect against DNS-related attacks.

Good DNS management also plays a key role in optimizing website performance and

uptime, crucial for providing a positive user experience.

 ​88

DNS Domain Migrations

DDI Central enables you to add new DNS servers through a special mode called the

DNS Domain Migrations mode. When using this mode, it is necessary to skip the

discovery phase. This is done by selecting No for the Discover Existing

Configurations option.

This approach is particularly advantageous when integrating a new DNS server that

manages a vast number of domains. These domains can be added to your existing

cluster as either primary or secondary.

The DNS Domain Migration mode facilitates the rapid inclusion of all domains or the

selective migration of specific domains from the server being added. If you choose

None, the new DNS server will be incorporated into your DDI cluster without any

domains, allowing you to configure zones and other settings manually at a later

stage.
 ​89

To proceed, select whether the domains of this particular server should be

recognized as Primary or Secondary within your cluster, and click Save to begin the

migration process. As this can take some time, it is advisable to wait for further

prompts or indications on the screen before proceeding.

Creating Authoritative Zones

You can create a new domain using the Add Domain button or import domains in
 ​90

bulk using the Import button in the top right corner.

Add Domain

On clicking the Add Domain button, the Create Domain page appears as shown

below.

In the Create Domain page enter the value for the fields based on the descriptions

below.
 ​91

1. NAME: Name the new domain name you wish to create or manage.

2. TYPE: Select the type of DNS zone. DDI Central offers three types of Zones:

Authoritative, Forward and Response Policy Zones (RPZ). Now select

Authoritative.

Authoritative: This type indicates that the DNS server has the authority to

answer queries for the specified domain with authoritative data. This means it

holds the actual DNS records, such as A records, MX records, and so on, for

the domain. It is the definitive source for information about that domain, and

its answers are considered official.

Note: The type of the domain once chosen cannot be updated. To update the type

of the domain, delete the domain and re-configure it.

3. TTL (Time to Live): Specifies the resolving servers how long to cache

information about the domain before querying for it again. Specified in

seconds, and the default value is set to 86400.

4. NAMESERVERS: Enter the nameserver that has the authority to resolve

queries and providing responses to queries for this domain.

5. EMAIL: Enter the email address of the domain administrator or the personnel

responsible for managing the DNS zone.

 ​92

6. REFRESH: Specified in seconds, tells secondary nameservers how often to

check with the primary nameserver for updates.

7. RETRY: Incase the secondary nameserver fails to reach the primary, this value

specifies how long it should wait before retrying.

8. EXPIRY: Determines the duration, in seconds, for which a secondary

nameserver will attempt to contact the primary nameserver. After this period,

if no response is received, the secondary nameserver will consider the data

stale and cease responding to queries with it.

9. MINIMUM: Specifies the minimum TTL that tells the resolving servers how

long to remember that a particular record does not exist.

10.TSIG: Transaction Signature is a security protocol used to secure zone

transfer operations. "No TSIG" indicates that no transaction signature will be

used.

11. MASTER(S): Specifies the master DNS server for the zone. In a primary-

secondary setup, the master server is where the zone records are originally

created and managed.

12. SLAVE(S): Specifies secondary or slave DNS servers. These servers get their

zone data from the master server through zone transfers.

13. DDNS: Dynamic DNS allows for the automatic updating of a name server in
 ​93

the Domain Name System via DHCP servers.

14. Failing to enable DDNS here, you can alternative enable DDNS by navigating

to DHCP-> Domains, Add the domain there and specify the TSIG key for secure

dynamic updates.

Click the Save button at the bottom to create or update the domain with the

specified parameters, while Cancel would discard any changes made.

Import Domains
DDI Central enables you to bulk import records into the DDI Central console using

the Import button on the top right corner.

On clicking the Import button, the Import Domains window appears on screen.
 ​94

On the Import Domains window, enter the values for the following fields:

1. ZIP FILE: Upload the ZIP file containing domain information in a specific

format required by the system.

2. TYPE: Specify the type of DNS zone being imported. The default option

shown is Authoritative, indicating that the data being imported is for an

authoritative DNS zone. Authoritative DNS zones are responsible for

containing the DNS records for a particular domain.

 ​95

3. MASTER(S): Select one or more master DNS servers. The master server would

be the primary source of data for the zones being imported and would handle

DNS queries and updates.

4. SLAVE(S): Similar to the MASTER(S) field, select one or more slave (or

secondary) DNS servers. Slave servers receive zone data from the master

server and serve as backups to handle queries if the master is unavailable.

5. VIEW: Select a DNS view by its name to provide different information to

different sets of clients based on some pre-defined criteria. For example, you

might have an "internal" view for clients on your local network and an

"external" view for clients on the internet.

6. IMPORT: Once all fields are filled out and you are ready to import the domain

data, click the Import button to initiate the import process.

The two methods discussed above can help you create authoritative zones.

Creating Reverse Authoritative Zones

Reverse DNS is the process of resolving an IP address back to a domain name. It is

 ​96

commonly used for services such as email servers to verify that an IP address maps

to a domain name. Reverse DNS for an IP address is configured by setting up a PTR

(Pointer) record in the reverse DNS zone. This zone is named after the reversed IP

address in the case of IPv4, and after the reversed nibbles of the IP address in the

case of IPv6. Reverse zones can only be configured for authoritative zones.

Reverse zones for IPv4 addresses

Follow the steps below to create reverse authoritative zones for IPv4 addresses.

Prerequisites

● Determine the subnet for which you want to create the reverse zone.

● Determine the authoritative DNS server for this zone.

1. Create a reverse authoritative zone just like how you create a standard

authoritative zone by selecting DNS-> Domain-> Add Domain

2. However while entering the reverse zone name, make sure to derive it from

your IP block in reverse order, followed by .in-addr.arpa. For example, for the
 ​97

IP block 192.168.1.0/24, the reverse zone name should be 1.168.192.in-

addr.arpa.

3. Create PTR (Pointer) records within the reverse zone. PTR records map the IP

addresses within your network block to the corresponding domain names.

Each record will correlate an IP address to a hostname, with the IP address

portion written in reverse.

4. You can enable DDNS Dynamic updates. Ensure the DHCP server is in the

same network as the Zone. This automates the creation of PTR records,

configure the DHCP options to allow dynamic updates from the DHCP server

to the domain.

5. If you want to secure the reverse zone with DNS Security Extensions

(DNSSEC), you can sign the zone to generate the necessary keys and signing

policies.

6. Click Save to save your new reverse zone configuration.

7. Perform reverse DNS lookups on IP addresses within the network block to

ensure that the PTR records are correctly resolving to their respective domain

names.

Reverse zones for IPv6 addresses

 ​98

For IPv6 addresses, the process is similar to IPv4, but the notation and the domain

used for reverse DNS delegation are different. The domain used for IPv6 reverse DNS

is .ip6.arpa.

Here is how you derive the reverse zone name from an IPv6 address block:

Let's say you have an IPv6 address block of 2001:0db8:85a3::/48. To create a reverse

zone name for this block:

1. Expand the IPv6 address: Write out the full IPv6 address, filling in any

omitted sections with zeros.

2. Expanded IPv6 address: 2001:0db8:85a3:0000:0000:0000:0000:0000

3. Remove the bits beyond the prefix length: Since the prefix is /48, you keep

only the first 48 bits (which correspond to the first three blocks of the IPv6

address).

4. Address Prefix: 2001:0db8:85a3

5. Reverse the nibbles: Split the address into individual hexadecimal digits

(nibbles), and write them in reverse order. Each hexadecimal digit

corresponds to four bits.

 ​99

6. Reversed nibbles: 3.a.5.8.8.b.d.0.1.0.0.2

7. Add the .ip6.arpa domain: Append this reversed string of nibbles to .ip6.arpa.

8. Reverse Zone Name: 3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa

Creating Forward Zones

DNS Zone Forwarding or Forward Zones in DDI Central refers to the process of

redirecting queries for a specific DNS zone to another DNS server. This is typically

used when a DNS server is not authoritative for a particular zone but is configured to

pass queries for that zone to a server that is. This zone doesn’t contain actual DNS

records but rather a forwarding instruction.

To create a new Forward Zone:

1. Select the DNS menu from the menu bar along the left side of the

screen.From the submenus that appear, choose Domains.

2. Click on Add Domain and choose the type of the domain as Forward Zone.

3. The Create Domain page will appear as shown below with the following
 ​100

fields:

NAME: Enter the name of the domain that you want to create.

TYPE: Select the type of the domain as Forward.

FORWARDERS: In this field, add the IP address of the DNS servers to forward

queries to.

DNS SERVER(S): Here you select the server that will be authoritative for the
 ​101

domain you're creating.

VIEW: Allows you to select a DNS view, which can provide different data

responses based on the source of the DNS query. You can configure views for

forward zones in DDI Central. This would allow you to specify different

forwarding behaviors based on the client making the request. For example,

internal clients may be forwarded to an internal server, while external clients

are forwarded to a public DNS service.

Note: Certain configurations like DDNS and DNSSEC do not exist for Forward zones.

DNS Firewall(FRW) Response Policy

Zones (RPZ)

RPZ (Response Policy Zone) allows a nameserver to modify DNS responses based

on policies. It's often used for implementing security measures, such as blocking

known malicious domains, redirecting domains, or applying other customized

policies. When a query matches an RPZ policy, the DNS server can return a different

answer than what is stored in the authoritative data.

 ​102

A DNS Firewall using Response Policy Zones (RPZ) is a powerful mechanism in DNS

servers for implementing custom security policies. It's often used for implementing

security measures, such as blocking known malicious domains, redirecting domains,

or applying other customized policies. When a query matches an RPZ policy, the

DNS server can return a different answer than what is stored in the authoritative

data. It effectively allows DNS administrators to override DNS responses based on

predefined policies, enhancing security and control over network traffic.

Here's what DNS Firewall RPZ does:

1. Intercepts DNS Queries: When a client device makes a DNS query, the DNS

Firewall with RPZ intercepts this query. It then checks the requested domain

name against a set of policy rules.

2. Uses Policy Zones (RPZs): RPZs are special DNS zones that contain lists of

domain names along with the policy actions to be applied to them. These can

include known malicious domains, domains associated with phishing, spam,

or domains that an organization wants to block for other reasons.

3. Overrides Standard Responses: Based on the RPZ rules, the DNS Firewall can

modify the standard DNS response. For instance, if a client requests a domain

that is listed in the RPZ as malicious, the DNS Firewall can redirect it to a safe
 ​103

page, block the request, or provide an alternate response.

4. Prevents Access to Harmful Sites: By redirecting or blocking requests to

dangerous or unwanted domains, DNS Firewall RPZs protect users from

malware, phishing attacks, and other cyber threats.

5. Customizable and Flexible: Administrators can create custom RPZs tailored

to their organization’s specific security needs. They can also subscribe to

third-party RPZ feeds, which are regularly updated lists of harmful domains.

6. Logging and Reporting: DNS Firewall RPZs can log queries to blocked

domains, providing valuable insights into attempted access to harmful sites

and helping to identify patterns of malicious activity.

7. Complements Other Security Measures: While not a standalone security

solution, DNS Firewall RPZ is an effective layer in a multi-layered security

strategy, complementing firewalls, intrusion detection systems, and other

security measures.

To create a RPZ in DDI Central:

● Go to DNS-> Domains . Click on Add Domain button on the top right corner.

● On the Create Domain page, Choose the type of the domain as Response
 ​104

Policy Zone (RPZ).

● You can create the RPZ just like how an authoritative zone is created and the

records are added. It is just you are controlling the local access to a publicly

available suspicious domain with customized safe IPs.

● Configure various types of individual records for the RPZ offered by DDI

Central, so that whenever a client in your network queries for any subdomain

or domain configured as RPZ, it is the custom response you configured will be

visible to the client in your network.

● DDI Central logs the queries to the RPZs and the different views configured for
 ​105

it. All the stats can be visualized under DNS-> Analytics page.

● An RPZ cannot have dynamic configurations. DDI Central enables you to

apply a variety of DNS options to RPZs to have a granular control over the

clients accessing it.

● DNS Firewall with RPZ is a proactive tool for enhancing network security by

controlling and modifying DNS responses based on an organization's policies,

thereby safeguarding the network from various online threats and undesirable

content.

Managing DNS Resource Records

What are domain Resource Records

(RR)?

Resource Records (RRs) are the fundamental information elements of the Domain

Name System (DNS). Each RR defines a specific piece of information about the

domain. Here are the general components of an RR:

1. Name: The domain name to which this record pertains.

 ​106

2. Type: The type of the resource record, which defines the type of data

contained in the record (e.g., A, MX, CNAME).

3. TTL: Time to Live, which specifies how long the record should be cached by

DNS resolvers.

4. RDATA: Resource Data, the data of the resource record, varies according to

the type (e.g., the IP address for an A record).

The combination of these elements within a DNS record allows DNS servers to

accurately resolve queries by clients for various services related to a domain, such as

website addresses, email servers, and service locations.

The following are the types of resource records supported by DDI Central:

1. A (IPv4): Address record that maps a domain name to an IPv4 address,

allowing a domain to be associated with a physical machine or resource on an

IPv4 network.

2. AAAA (IPv6): Address record similar to the A record but for IPv6 addresses,

mapping a domain name to an IPv6 address.

3. CAA (Certificate Authority Authorization): Specifies which certificate

 ​107

authorities (CAs) are allowed to issue certificates for a domain, enhancing

security by restricting which CAs can issue certificates.

4. CNAME (Canonical Name): Redirects one domain name to another domain

name, allowing multiple DNS records to map to the same server without

specifying IP addresses.

5. DS (Delegation Signer): Holds the cryptographic signature for a DNSSEC-

secured domain, which is used to securely delegate a subdomain to another

DNS server or manager.

6. MX (Mail Exchange): Directs email to a mail server by specifying the server

responsible for accepting email messages on behalf of a domain with a

priority level.

7. NS (Name Server): Indicates the authoritative name server for a domain,

which is responsible for presenting information about the domain's DNS zone.

8. PTR (Pointer): Used primarily for reverse DNS lookups, mapping an IP address

(IPv4 or IPv6) to a domain name.

9. SPF (Sender Policy Framework): Defines which IP addresses are authorized

to send email from a domain, helping to prevent email spoofing.

10.SRV (Service Locator): Specifies the location of servers for specified

services, containing the hostname and port number for services such as VoIP,
 ​108

IM, etc.

11. TXT (Text): Allows administrators to insert arbitrary text into a DNS record.

Often used to provide information to external sources, such as verification

tokens for domain ownership or email security policies.

Creating resource records in DDI

Central

To add or update the resource records for a particular domain

1. Click on the domain name of your choice from the list of the domains that

you intend to create or update DNS records.

2. This will take you inside that particular domain, displaying various types of

records supported by DDI Central like A, AAAA, ANAME, CNAME, etc.

 ​109

3. Select the relevant record type you'd like to configure for your domain and

click on it.

4. To create a new record under the chosen record type, Click on the blue Add

button at the extreme right corner of the table header under the chosen

record type.

5. On the Create record type page, enter the subdomain or hostname.

 ​110

6. The Time-To-Live(TTL) attribute specifies the total number of seconds the

local resolver ought to cache the response for a record before requesting a

new one. The default is set to 86400 but can be modified as per your

domain's requirements.

7. DDI Central enables you to configure multiple hosts to provide responses for

a domain by clicking Add IP. To configure multiple hosts for a DNS record

click on Add IP after each entry.

 ​111

Importing and exporting zone data

DDI Central enables you to quickly create all of the records for your zone by

importing a zone file in BIND format, that represents zone files in a text format.

Importing
To create DNS records by importing a zone file in BIND format:

1. Get the zone file exported and saved as BIND file from the other DNS server

Make sure the zone file is in RFC-compliant format.

2. In the DDI Central, create a new zone or select a zone by clicking on its name.

3. Once you are inside the new zone, click the Import button in the top right

corner.

4. Now you can import the zone file as a BIND file.

Click the Import button at the bottom to start importing. You may have to wait a

few minutes for the records to be created as it depends on the number of records in

your zone file.

 ​112

Exporting
The same process is followed to export your zone files in DDI Central. Click the

Export button in the top right corner. On clicking the Export button, the zone files

are automatically downloaded as text files with the respective domain name in

BIND format.

Managing DNS Views

What are DNS views?

DNS views or Domain views serve different responses to DNS queries based on

various criteria, most commonly the source of the query or the host accessing it.

This indicates that the DNS server can present one set of DNS information to one

group of clients and a different set to another group, based on predefined views.
 ​113

Configuring Named Views

DDI Central enables you to create multiple views and name them for better

identification

Select the DNS menu the left menu bar. Now select Views from the submenus that

appear on the inner menu bar.

1. Select the DNS menu from the menu bar along the left side of the screen.

2. From the submenus that appear, choose Views.

3. If views have never been enabled for any of the existing zones, the screen will

display the message No View Available.

 ​114

4. Clicking on the Enable View button now will move all the existing domains to

a Default view. Clicking Yes will create a Default View entry in the Views page.

Here you can see under the match client field holding the value any,

indicating this configuration will apply to all clients.

 ​115

Default View

Default view for a domain refers to the unnamed or implicit view that is used

when no specific view has been defined for a set of DNS queries. In the default

view, BIND handles DNS queries as any standard DNS server would, without

applying different rules or data sets based on the query source. It simply
 ​116

serves the DNS zones and records as configured.

In more complex configurations where named views are used, the default

view can still exist. It would handle any queries that don't match the criteria of

the named views. For example, if there are views for internal and external

networks, the default view could handle queries from sources not covered by

these specific views.

5. To create a named View, click on the Add View button in the top right corner.

The Create View page appears.

6. Input a name for the new View in the designated field.

7. For the Match Clients field, input the list of IP addresses or specify named

Access Control Lists (ACLs) as required.

 ​117

8. Select the DNS options relevant for your selection of clients.

9. Once all the necessary information is provided and options are selected, click

Save.

Popular DNS options for Domain views

1. Match Clients: Determines which clients (usually specified by IP address or

network) the view applies to. It can be used to differentiate between internal
 ​118

and external network clients.

2. Match Destinations: Similar to match-clients, but this matches on the

destination address of the query instead of the source.

3. Recursion: Controls whether the server will perform recursive queries for

clients using this view. This can be enabled for internal clients and disabled

for external ones to prevent abuse.

4. Forwarders: Specifies different upstream servers for resolving DNS queries

for clients that match the view. This can redirect query traffic based on client

type or requested domain.

5. Response Policy Zone (RPZ): Implements response policy service, allowing

the server to modify or block DNS responses based on policies.

6. Order of Precedence: If a client matches multiple views, the order in which

the views are defined in the configuration file determines which one finally

applies.

7. Allow-recursion, allow-query, allow-transfer: These options within a view can

be used to control which clients are allowed to perform recursive queries,

make queries, or request zone transfers, respectively.

8. DNSSEC Validation: Controls whether DNSSEC validation is performed for the

clients that match the view. This might be enabled for external views to
 ​119

provide DNSSEC security for internet clients.

Managing Dynamic Domains

Table of Contents

Dynamic DNS (DDNS) 1

Enabling DDNS in ManageEngine DDI Central 3

Dynamic authoritative zones 4

Forward Mapping Dynamic Zones 4

Reverse dynamic Zones 6

Dynamic DNS (DDNS)

In DNS, a zone is a portion of the domain namespace, and the ability to create new

zones dynamically is very essential, especially in environments where zones need to

be added or removed without manual intervention.

Dynamic DNS (DDNS) can be enabled for various types of zones where it is necessary
 ​120

to dynamically update DNS records without manual intervention. Here are the types

of zones where DDNS can be enabled:

1. Primary Zones:

● DDNS is most commonly enabled on primary zones. In a primary zone,

the DNS records are stored and managed directly on the authoritative

DNS server.

● With DDNS, clients such as DHCP servers or DHCP clients can add,

remove, or update DNS records in the primary zone dynamically. This is

often used for automatically updating the DNS records of hosts as they

obtain IP addresses from a DHCP server.

2. Secondary Zones:

● While DDNS updates are not directly applied to secondary zones,

secondary zones can receive updates indirectly via zone transfers from

the primary zone.

● When a DDNS update is made to the primary zone, the updated

information is propagated to the secondary zones through the standard

zone transfer mechanism (AXFR).

3. Reverse Zones:
 ​121

A reverse domain needs Dynamic DNS (DDNS) for several reasons,

mainly related to the management of changing IP addresses and the

need to maintain accurate reverse DNS records.

Enabling DDNS in ManageEngine DDI

Central

To enable your DHCP server to dynamically provision IP address to your domains:

● When creating a domain via Domains -> Add Domain , enable DDNS and

assign a TSIG key for secure dynamic updates. If DDNS is not enabled at this

stage, it cannot be activated later through the DNS menu.

● Alternatively, add domains that require dynamic configurations by navigating

to DHCP -> Domains .

● On the Domains page, Click on the Add Domain button in the top right

corner.
 ​122

Note: For your DHCP server to provision network parameters like IP addresses to

your domains make sure your Domains and DHCP server are in the same network

address.

Dynamic authoritative zones

Dynamic DNS (DDNS) allows the automatic updating of a DNS record when an IP
 ​123

address changes. This is often used for hosts with dynamic IP addresses assigned by

a DHCP server.

Forward Mapping Dynamic Zones

To create a dynamic Forward Mapping Authoritative Zone,

● Enable DDNS for the zone via one of the methods discussed above This would

automatically enable the following DHCP options for the domain: ddns-

updates:true, ddns-update-style:interim, domainname

● Now select the subnet that you would like to provision IP addresses to the

domain. Within that subnet specify the option domainname and specify the

domain name you would like to create hosts to via dynamic updates like:

domainname: data.com. This would enable the specific subnet to provision

ip address to the hosts of that particular domain. Save the configurations.

● Now for an authoritative forward mapping zone, enabling DDNS would

automatically create an A record with a host name assigned to it. the host

name assumes variable IPs provisioned by the chosen subnet.

 ​124

● Example: In the provided example, ip6.com. is an IPv6 based Forward

mapping zone. Upon enabling DDNS, the DNS server will automatically

generate a AAAA record for the zone. Within the AAAA record you can find the

host name that holds dynamically variable IPv6 address provisioned by the

DHCP server.
 ​125

Reverse dynamic Zones

For an authoritative reverse mapping zone, enabling DDNS will automatically

generate PTR records that correspond to the hostnames within the authoritative A

(or AAAA) records of a forward mapping zone.

Example:

In the provided example, 1.1.1.in-addr.arpa. is an IPv4-based reverse zone. Upon

enabling DDNS, the DNS server will automatically generate a PTR record within this

reverse zone. These PTR records will correspond to the hostnames defined in the

authoritative A records of the forward-mapping zone to which the reverse zone is

linked.
 ​126

The PTR record's name is the reverse of the IPv4 address appended to in-addr.arpa.

The reverse zone name 1.1.1.in-addr.arpa. would be the reverse of the assigned IPv4

address and the corresponding PTR record within that zone points to

host.check.com. which is the hostname of the system that was assigned the IPv4

address. This enables reverse DNS lookups, where querying the IPv4 address in
 ​127

reverse notation returns the hostname host.check.com.

Domain Scavenging

Domain scavenging, more commonly known as DNS scavenging, refers to the

process of cleaning up stale DNS records that remain idle over time in the DNS

database. This mechanism is typically used to automatically remove outdated

records, such as those for IP addresses no longer in use, and can help prevent DNS-

related issues such as name resolution conflicts and unwanted bloats in the DNS

database. This practice is essential for maintaining an accurate and efficient Domain

Name System, particularly in environments where IP addresses and host

configurations frequently change. Here is an overview of domain scavenging:

1. Purpose: Scavenging helps remove stale resource records from DNS, which

might no longer be valid due to changes in network configuration, such as

decommissioned servers, expired DHCP leases, or devices that are no longer

part of the network.

 ​128

2. Automated Cleanup: The scavenging process is often automated. DNS

servers are configured to periodically scan the DNS records and remove those

that are outdated or no longer in use.

3. Aging and Refresh: Scavenging relies on two key concepts: the aging of

records and the refresh of these records. When a DNS record is created or

updated, it’s given a timestamp. If this record is not refreshed or updated

within a certain period (the aging time), it's considered stale.

4. Scavenging Interval: Administrators set a scavenging interval, which is the

frequency at which the DNS server checks for stale records. If a record is older

than the aging period by the time of this check, it will be notified to the user

through scavenge reports.

5. Prevents DNS Bloat: Regular scavenging prevents the DNS database from

becoming bloated with unnecessary records, which can slow down DNS

query responses and lead to inefficiencies in network operation.

6. Dynamic DNS Environments: Scavenging is particularly important in

dynamic DNS environments where DHCP is used to assign IP addresses. As

clients come and go, their DNS records need to be updated or removed to

reflect their current status.

7. Careful Configuration: Incorrectly configured scavenging can lead to the

 ​129

premature deletion of active DNS records. It’s important to set appropriate

aging and scavenging intervals to avoid disrupting network services.

8. Improves Network Security: By removing outdated records, scavenging can

also enhance network security. Stale DNS entries can be a security risk, as

they may point to unused IP addresses that could be exploited by malicious

actors.

Domain scavenging is a crucial maintenance activity for any network that uses DNS

and DHCP. It helps ensure that the DNS database remains up-to-date and free from

clutter, enhancing both the performance and security of the network.

Configuring domain scavenging in DDI

Central

To configure Domain scavenging in DDI Central:

Note: Scavenging can be configured only for A, AAAA. CNAME, PTR and TXT

records, as only these records are capable of receiving dynamic updates.

 ​130

● Select the DNS menu from the menu bar along the left side of the screen.

From the submenus that appear, choose Scavenging.

● First configure scavenging for your DNS infrastructure under the Configure

tab.

● On the Configure window that appears, the top field SCAVENGING PERIOD

is meant for all the A, AAAA. CNAME, PTR of the domains selected. This is the

duration after which a DNS record becomes eligible for scavenging if it has

not been refreshed. If the DNS record still remains un refreshed after this

period, DNS server considers the record stale and eligible for deletion and put

up in the report for the user to delete or reclaim it .

● SCHEDULE INTERVAL: This dropdown menu allows the user to select how

often the scavenging process should be scheduled to run. The options could

range from daily to monthly intervals.

● DOMAINS: Here, you can specify which domains are subject to the

scavenging process. Click Save.

​131
 ​132

● Once the scavenging is configured, the Configure page summarizes your

selections and shows the domains it targets to scavenge.

 ​133

● Once it detects stale records, the records will be displayed in the reports

section. Depending on the current state of the records, the user can delete it

or reclaim those records.

 ​134

DNS64

DNS64 is a mechanism used in IPv6 networks to facilitate communication between

IPv6-only clients and IPv4-only servers. This is especially important in the context of

the ongoing transition from IPv4 to IPv6. Since these are two different protocols and

not directly compatible, mechanisms like DNS64 are essential for interoperability.

This is accomplished in ME DDI Central using the DNS option dns64.

Configuring dns64 option involves setting up a DNS server that can synthesize

AAAA records (IPv6 addresses) from A records (IPv4 addresses) when no native

AAAA records are available. This configuration is typically done on a DNS server

that's designed to support DNS64 functionality.

DNS64 works by prefixing an IPv4 address with a specific IPv6 prefix. This prefix is

usually a /96 prefix, which leaves room for the entire IPv4 address. A common prefix

used is 64:ff9b::/96, but you can use a different one if required.

Example in ISC BIND format

1 options {
 ​135

2 // other options...

3 dns64 64:ff9b::/96 {

4 clients { any; };

5 // more specific configurations if needed

6 };

7 };

In this configuration:

● dns64 64:ff9b::/96 specifies the DNS64 prefix.

● clients { any; }; indicates that DNS64 translation should be applied to requests

from all clients. You can restrict this to certain clients or networks if necessary.

Configuring DNS64 in DDI Central

To configure it select DNS-> Config-> DNS Options

● On the DNS options page, click on the Options drop down box to search for

dns64 option.

● The dns64 option appears with all its attributes. Fill in the values for each
 ​136

attribute and click Save.

Here are the attributes within the dns64 option:

netprefix: This is the IPv6 prefix that is used to synthesize AAAA records. It's

typically a /96 prefix, and the IPv4 address is appended to this prefix to create the

IPv6 address in the synthesized AAAA record. Example value: dns64 64:ff9b::/96 {

... };

break-dnssec: This attribute, when set, allows DNS64 to synthesize AAAA records
 ​137

even for DNSSEC-signed domains. This can potentially break DNSSEC validation, as

the synthesized AAAA record does not actually exist in the DNS. Example value:

break-dnssec yes;

clients: Specifies for which clients the DNS64 rule applies to. You can define a

match list of IP addresses or subnets from which the clients are allowed to use

DNS64. Example value: clients { any; };

exclude: Used to define IP address ranges for which DNS64 should not synthesize

AAAA records. This is useful for networks or hosts that are reachable over native

IPv6. Example value: exclude { 2001:db8::/32; };

recursive-only: When set to yes, DNS64 synthesis is performed only for recursive

queries. It won’t synthesize records for authoritative answers. Example value:

recursive-only yes;

mapped: This attribute controls whether DNS64 synthesis is applied to domains that

have both A and AAAA records. If set, it will synthesize AAAA records even if native

AAAA records exist. Example value: mapped yes;

suffix: This optional attribute specifies a suffix to append to the synthesized IPv6

address. It's rarely used as the default behavior (without a suffix) is generally
 ​138

preferred. Example value: suffix ::1;

Each of these attributes fine-tunes the behavior of DNS64, allowing for

customization based on specific network needs, especially in environments

transitioning to IPv6 or operating in dual-stack (IPv4 and IPv6) scenarios. It's

important to configure these settings carefully to ensure proper network

functionality and to avoid unintended disruptions, particularly with regard to

DNSSEC and native IPv6 connectivity.

Click Save to see the dns64 option in effect.

DNS Security Management

DNS Security Management involves implementing and maintaining measures to

protect the Domain Name System (DNS), a critical component of your network

infrastructure. This includes safeguarding against DNS-based threats like cache

poisoning, DDoS attacks, and domain hijacking. Effective DNS security

management encompasses using secure protocols like DNSSEC to ensure data

integrity, implementing response rate limiting (RRL) to mitigate DDoS attacks, and

regularly monitoring and auditing DNS traffic for anomalies.

 ​139

Additionally, it involves ensuring proper configuration of DNS servers, keeping

software updated, and using access control lists (ACLs) to restrict unauthorized

access. Such comprehensive security practices are essential to maintain the

reliability and trustworthiness of DNS services, crucial for the seamless operation of

internet-based communications and services.

DNSSEC

DNSSEC, short for Domain Name System Security Extensions, is a suite of

specifications for securing certain kinds of information provided by the Domain

Name System (DNS). It is designed to protect against a range of DNS attacks such as

cache poisoning, where a DNS query is redirected from a legitimate to a malicious

site.

Why You Need DNSSEC

1. Integrity: DNSSEC ensures that the information you receive from a DNS query
 ​140

is exactly what the domain owner entered, with no modifications en route,

guaranteeing data integrity.

2. Authentication: It provides a means to verify that the source of your DNS data

is legitimate (authenticity) and not a malicious actor trying to intercept or

manipulate DNS queries.

3. Trust: By building a chain of trust from the root DNS servers down to the

specific DNS entry for a domain, DNSSEC prevents attackers from inserting

malicious DNS data into the responses to DNS queries.

What DNSSEC Does

● Digital Signing: DNSSEC works by digitally signing these records for DNS

lookup using public-key cryptography. Each DNS zone has a private key that is

used to sign the zone's DNS records, and a public key that is used to validate

the signatures.

● Chain of Trust: Starting from the DNS root zone, each level of the DNS

hierarchy has its own pair of keys and signs the keys for the level below it,

creating a chain of trust down to the individual DNS record level.

 ​141

● Non-Repudiation: Because of the digital signatures, DNS data cannot be

tampered with without detection, providing non-repudiation, which is the

assurance that someone cannot deny the validity of something.

● Validation: Resolving name servers, which are configured to use DNSSEC, can

then validate these signatures using the public key, ensuring that the DNS data

has not been modified.

DNSSEC is necessary to combat the inherent vulnerabilities in the traditional DNS

system that make it susceptible to various forms of attack. By providing a way to

verify the authenticity of DNS data, DNSSEC adds a layer of security to the domain

name lookup process.

Configuring DNSSEC in DDI Central

To enable DNSSEC:

● DDI Central deploys DNSSEC signing to sign the DNS responses of a

particular zone. Navigate to the domain of your choice and click on the

DNSSEC button with the icon of an opened lock on the top right corner.
 ​142

● Click on the Sign button.

● After the domain of your choice is signed successfully, a DNSKEY record, a

DS record are created automatically within the zone. DDI Central displays the

DNSSEC key tag, algorithm, digest type, digest under DS Records, flags

along with a public key, Key Signing Keys(KSK), Zone Signing Keys(ZSK)
 ​143

associated with the particular zone. Copy these details in your clipboard as

you'll need these details to update your registrar.

● You can also see the Unsign button with a closed lock on the top right corner

indicating DNSSEC is enabled for the zone.

● Once DNSSEC signing is enabled on a zone and the appropriate information

is given to your registrar, DNSSEC supporting resolvers will begin to validate

DNS responses returned by your on-prem nameservers.

● You can also revoke DNSSEC for a particular zone by clicking the Unsign

button at the top right corner.

Response Rate Limiting (RRL)

RRL, or Response Rate Limiting, is a security feature implemented in DNS servers to

mitigate the impact of Distributed Denial of Service (DDoS) attacks, particularly DNS

amplification attacks. It works by limiting the rate at which DNS responses are sent

from a server to a particular client or set of clients.

When a DNS server receives an unusually high volume of requests, possibly as part
 ​144

of an attack, RRL kicks in to restrict the number of responses sent back to any given

requester over a specified period. This helps to prevent the server from being used

as a tool in amplification attacks, where large numbers of responses are sent to a

victim's network, overwhelming its bandwidth. It is implemented in ME DDI Central

using the rate-limit DNS option.

Configuring RRL in DDI Central

To configure it select DNS-> Config-> DNS Options

On the DNS options page, click on the Options drop down box to search for rate-

limit option.

The rate-limit option appears with all its attributes. Fill in the values for each attribute

and click Save.

 ​145

Here are explanations for various attributes of the rate-limit option:

1. all-per-second: Limits the total number of all responses (regardless of type)

per second.

2. errors-per-second: Limits the number of error responses (like SERVFAIL) per

second.

3. ipv4-prefix-length and ipv6-prefix-length: Define the subnet mask length

for aggregating IPv4 and IPv6 addresses. This dictates how broadly the rate

limiting is applied across a range of IP addresses.

 ​146

For example, ipv4-prefix-length of 24 means that the server will apply rate limits

to all addresses in each /24 subnet as a group. Therefore, all requests originating

from the 192.168.1.0/24 subnet, for instance, would be collectively subject to the

specified rate limit.

4. exempt-clients: Specifies clients (usually by IP address or subnet) that are

exempt from rate limiting. This is often used for trusted networks.

5. log-only: When enabled, BIND logs the rate-limited responses without

actually enforcing the limits. This is useful for testing the configuration.

6. max-table-size: The maximum number of entries in the rate-limiting table. A

larger table can track more clients but requires more memory.

7. min-table-size: The minimum size of the rate-limiting table.

8. nodata-per-second: Limits the number of responses per second that result in

NODATA (no error but no data).

9. nxdomains-per-second: Limits the number of NXDOMAIN (non-existent

domain) responses per second.

10.qps-scale: A factor by which to scale the queries per second calculation. It

can be used to adjust the sensitivity of rate limiting.

11. referrals-per-second: Limits the number of DNS referral responses per

second.
 ​147

12. responses-per-second: Limits the number of identical responses per second

from a single IP address or subnet.

13. slip: Defines the behavior when a rate limit is exceeded. Typically, every nth

response will be truncated.

The slip setting determines how often the DNS server will send a truncated

response instead of dropping the response entirely when rate limiting is in

effect. A truncated response is a response that tells the querying client that it

should retry the request over TCP instead of UDP. Since TCP connections

require more resources to establish, attackers are less likely to use them,

making DDoS attacks less effective.

Here’s a breakdown of the slip option:

1. Value 0: The server will drop all responses that exceed the rate limit.

2. Value 1: The server will send a truncated response for every request

that exceeds the rate limit.

Values 2 and higher: The server will send truncated responses for one out

of every 'slip' number of requests that exceed the rate limit. For example, if

the slip value is set to 2, then the server will send a truncated response for

every second request that exceeds the limit.

 ​148

14. window: The time period, in seconds, over which BIND calculates the rate of

identical responses for rate limiting.

Example

1 rate-limit {

2 responses-per-second 10;

3 window 5;

4 ipv4-prefix-length 24;

5 ipv6-prefix-length 48;

6 slip 2;

7 nxdomains-per-second 5;

8 nodata-per-second 5;

9 errors-per-second 2;

10 all-per-second 20;

11 max-table-size 100000;

12 exempt-clients { 192.168.0.0/24; };

13 log-only yes;

14 };

15
 ​149

From the above configuration example, ME DDI Central will limit identical DNS

responses to 10 per second over a 5-seconds window. If the limit exceeds, DDI

Central will start sending truncated responses every second request (split=2). The

local network (192.168.1.0/24) is exempt from these limits, and the log-only setting

means the limits will be logged but not enforced, which is helpful for initial testing.

Domain Blocking Using DNS Firewall

Domain blocking using a DNS Firewall is a security measure that prevents users from

accessing specific websites or domains by intercepting DNS queries and filtering

out requests to undesired or malicious domains. When a user attempts to visit a

website, their device sends a DNS query to resolve the domain name into an IP

address. A DNS Firewall steps in at this point to screen the query against a set of

predefined security rules or blacklists.

The DNS Firewall first intercepts DNS queries from client devices on the network

before they reach the internet. It analyzes the domain name requested against a

database of blocked or suspicious domain names. If the domain is on the block list,
 ​150

the DNS Firewall applies the configured policy, which typically involves preventing

the resolution of the domain name into an IP address. Finally, the DNS Firewall

redirects the query to a safe page. DDI Central's Firewall based Domain Blocking

measure blocks collections of recognized malicious domains and directs the users

to a safe customized IP address.

Components of DNS Firewall based

Domain Blocking

● Blacklists: Lists of known bad domains, which can be custom-defined by the

organization or subscribed to from external security providers.

● Category-Based Filtering: Blocking domains based on categories, such as

adult content, social media, or streaming services. DDI Central also curates

most common collections of malicious or suspicious domains from third

party services and enables you add your own custom collection of malicious

sites.

To add a domain to the DNS Firewall Blacklist :

 ​151

1. Go to DNS->Config-> DNS Firewall.

2. You can start adding the domains to the blacklist one by one under a particular

category. Check the Block subdomains check box if you want to block all the

subdomains of the domain as well.

3. Once you click Add, you will see two separate lists, one that says Domains

Blocked and the other says Domains blocked along with subdomains. This

way, you can build your categories of malicious domains on your own.
 ​152

4. Once you are done building the list, specify the Redirection IP and click Save.

5. You can bulk import a customized list of malicious domains via CSV import for

quicker addition. You can also block as many categories based on your

organizational needs.

6. You can also click on the View list button on the top right corner of the page,

to import already existing categories into the current blacklist you are

building.
 ​153

7. This setup enhances network security by proactively preventing access to

potentially harmful web content and mitigating cyber threats.

Configuring TSIG Keys

TSIG (Transaction Signature)

 ​154

TSIG is a security protocol used in the Domain Name System (DNS) to provide

authenticated and secure communications between DNS servers and between DNS

servers and clients. TSIG uses shared secret keys and cryptographic signatures to

validate that the DNS messages are authentic and have not been tampered with. It's

primarily used for

1. Securing Zone Transfers: Ensuring that AXFR zone transfers occur only

between authorized servers.

2. Securing Dynamic Updates: Authenticating requests to update DNS records

dynamically, especially in Dynamic DNS (DDNS) environments.

3. Authenticating DNS Queries and Responses: Verifying the authenticity of

both the query and the response in DNS transactions.

TSIG adds an additional layer of security to DNS operations that is not provided by

standard DNS, which by itself has no mechanism for authenticating the source or

integrity of DNS data.

TSIG Key Templates in DDI Central

 ​155

The Key Templates are saved under the TSIG Key Templates tab on the Config

page with the following fields as shown below:

Key Name

The Key Name is mainly used to identify the key across the primary and secondary

name servers. Ensure a unique name is assigned to the key.

Algorithm
 ​156

TSIG Algorithm serves essentially as a cryptographic hash function that executes

HMAC operations to generate the TSIG key value. Currently, CloudDNS supports

the following algorithms HMAC MD5, HMAC SHA1, HMAC SHA224, HMAC SHA256,

HMAC SHA384, and HMAC SHA512 to generate the TSIG key.

Secret Key

The secret key value is an encoded base64 string with a maximum value of 255

characters that acts as a shared signature to provide transaction-level

authentication for the name servers during zone transfer operations.

Configuring ACL (Access Control List)

An ACL in the context of network administration is a set of rules that control network

traffic and limit access to networks and network resources based on predefined criteria.

In DNS servers like ISC BIND, ACLs are used to define which clients (based on IP

addresses or networks) are allowed or denied access to certain DNS services. Common
 ​157

uses of ACLs in DNS include:

1. Restricting Query Access: Defining which clients are allowed to query the DNS

server.

2. Controlling Zone Transfers: Specifying which secondary servers are allowed to

receive zone data from the primary server.

3. Limiting Dynamic Updates: Controlling which clients can dynamically update

DNS records, often used in conjunction with TSIG for secure DDNS.

ACLs allow for the implementation of security policies by controlling who can access

the DNS server and what actions they can perform, which is critical for maintaining the

integrity and security of the DNS infrastructure.

Managing ACL templates

ACL templates are predefined configurations that simplify the creation of Access

Control Lists (ACLs) in various network services, including DNS and DHCP servers. An

ACL template allows administrators to define a set of rules or criteria once and then

apply them across multiple instances, reducing redundancy and potential for error in
 ​158

configurations.

Usage of ACL Templates

ACL templates are typically used in environments where the same access restrictions or

permissions are needed across different zones, views, or services. Instead of defining

the same ACL multiple times, a template is created once and then referenced wherever

needed.

They can be applied gobally on the cluster level, within specific zones, views, or options.

Defining Named ACLs

To create Named ACLs

● Go to DNS-> Config-> ACL

● Click on ADD ACL button on the right.

● You can choose the type of the ACL: ISC Format or Template based ACL.

● For the DDI Central template, just enter the IPv4/IPv6 addresses one by one in the

allow and Deny lists.

 ​159

● For the ISC format

Follow the Example below:

Here's an example of an ACL in ISC BIND format:

1 acl "internal-network" {

2 192.168.0.0/24; // An internal subnet in CIDR

 ​160

notation

3 10.15.20.0/22; // Another internal subnet in

CIDR notation

4 localhost; // The keyword for the

loopback address (127.0.0.1)

5 localnets; // A predefined match list

for all local networks

6 ! 192.168.0.100; // Exclude a specific IP from

the ACL

7 2001:db8::/32; // An IPv6 subnet in CIDR

notation

8 key "transfer-key"; // A TSIG key for secure

transactions

9 };

DNS Query Analytics

 ​161

DNS analytics dashboard provides a network administrator with quick insights into

the DNS and leased IP activity related to a particular domain or network segment. It

helps in monitoring network usage, identifying potential issues, and understanding

traffic patterns.

To access the domain analytics

● Select the Select the DNS menu from the menu bar along the left side of the

screen.

● From the submenus that appear, choose Analytics.

● The analytics page appears, showing the current query rate and the total

queries handled by all the DNS servers in the cluster. At the top right corner of

the analytics Page, choose the type of Zones to view the query analytics.

● All: Displays analytics for all domains.

● Hosted Domains: Shows analytics specifically for domains that are

hosted.

● Blocked Domains: Presents analytics for domains that have been

blocked.
 ​162

Moreover, choose the required timeframe along which you want to analyze the

performance of domains.

Queries Per Second: Indicates the current rate at which DNS queries are being

processed by the server.

Total Queries: Displays the total volume of queries handled over a specific time

period.

Below these metrics, you can find the list of domains and their views queried. The list

also bears the query volume for even the non-hosted- domains un-resolvable by your

DNS servers.
 ​163

● To thoroughly evaluate a domain's performance, select a specific domain

from the list. This will display the domain's specific performance metrics,

including hourly query load over a user-defined timeframe.

● You'll also see details for IP addresses leased under this domain, such as lease

duration, MAC addresses identifying each host, and the vendors of the host

machines.

● Additionally, the total query load across all IPs, as well as individual query

loads, are visually represented in a doughnut chart accessible by selecting the

respective IP.
 ​164

● Furthermore, a separate doughnut chart provides a visual breakdown of the

query volume for different types of DNS records, illustrating the distribution

for each query type.

DNS Audit Logs

 ​165

ManageEngine DDI Central enables you to view the audit logs of specific domains.

Select the DNS menu from the menu bar along the left side of the screen. From the

submenus that appear, choose Audit.

The Audit page helps you continuously evaluate the overall security posture of your

domains and records using security audit logs to track who, what, and when with

respect to domain management and record updates.

You can also filter the logs for filtering the specific activities carried out by a
 ​166

specific user or a specific activity carried out around a certain time frame to detect

security breeches and malpractices.

Regularly reviewing your DNS infrastructure's security logs helps you ensure that

the access control mechanisms are performing adequately, determine whether

employees are sticking to your security practices, and catch new potential security

weaknesses.

About DHCP Management

Dynamic Host Configuration Protocol (DHCP) is a critical network service that

automatically assigns IP addresses and other network configuration parameters to

each device on a network, enabling them to communicate with other IP networks.

DHCP management streamlines the process of configuring devices on IP networks,

reduces the potential for error in assigning IP addresses, and conserves the number

of addresses used.

DHCP is a crucial aspect of network administration, as it ensures that devices can

 ​167

join the network with minimal manual setup, maintain connectivity, and have the

correct network settings for accessing local resources and the Internet. Effective

DHCP management includes overseeing IP address allocation, monitoring DHCP

servers, and ensuring the reliability and security of the service within an

organization's IT infrastructure.

Managing DHCP Scopes

What is a DHCP Scope?

A DHCP scope is a network topological element in DHCP defined as a pool of IP

addresses that a DHCP server can dynamically assign to clients on a particular

subnet. Each scope represents a range of IP addresses that are available for lease to

client devices, as well as configuration options associated with those IP addresses.

ManageEngine DDI Central supports the following network topological elements

that shape a network infrastructure:

 ​168

Subnets
● A subnet represents a basic segment of IP addresses (IPv4 or IPv6) within a

network. Defining, a subnet in DDI Central is used to define a range of IP

addresses that the DHCP server can assign to clients on a specific network

segment.

● Each subnet is defined by a range of IP addresses and a subnet mask,

determining the network's address range.

● To create or update a subnet go to DHCP-> Network-> Subnet.

● Define a new subnet by providing values for various attributes of the subnet

like:

Provide the first address of the pool to be associated with the new subnet.

● Provide a suitable description for the subnet to quickly identify its purpose

and convey the policy associated with it, for a common understanding of its

layout.

● Specify the subnet size using an appropriate prefix, which denotes the

number of IP addresses that the subnet can accommodate.

● Enable DHCP failover and select a DHCP server to take over the task of

assigning IP addresses for the subnet without any significant downtime.

● Assign the necessary DHCP options.

 ​169

● Click Save.

● Note: DDI Central also offers the option to clear the active subnets currently in

lease. Clearing all the leases for a subnet removes it from your database,

freeing up memory, but lease records stay intact, enabling IP addresses to

revert to their original states as per the lease records after a short interval of 5

minutes.

Shared Networks
● A shared-network defined in DDI Central is used when multiple logical IP
 ​170

networks (subnets) share the same physical network segment.

● Shared networks allow DHCP to serve multiple subnets on a single physical

network, providing different IP configurations to clients based on their

network segment.

● To create a new shared network, go to DHCP-> Network-> Shared Network.

● Assign a unique name and description for the shared network.

● Just add the required subnets and apply the necessary DHCP or custom

options .

● Click Save.
 ​171

Hosts
● A host declaration specifies settings for individual clients based on their

hardware (MAC) address.

● This is used for assigning fixed IP addresses or specific configurations to

particular clients, ensuring that a specific client always receives the same IP

address and settings.

● To create a Host with a fixed address, go to DHCP-> Network-> Host.

 ​172

● On the Host page, provide a unique name for the host, the mac address of the

host.

Host Groups
● Host groups are a group of hosts combined logically for easier management.

● Grouping hosts can simplify configuration, especially in large networks, by

applying common settings to multiple hosts.

● You can apply a multiple DHCP options over this combination of hosts for

customized management.
 ​173

Supernets
● Supernets, or supernetting, refers to aggregating multiple networks into a

larger network. In the context of DHCP, this is not a direct feature but rather a

concept of network design.

● Supernetting is used in IP routing more than in DHCP configurations. It's

about combining smaller subnets into a larger address space for routing

purposes.
 ​174

VLANs (Virtual LANs)

● VLANs are a network configuration that segments a physical network into

multiple logical networks at the data link layer (Layer 2).

● DDI Central enables DHCP servers to serve different VLANs as distinct subnets

or shared networks.

● Each VLAN you create within a subnet functions as a separate network, which

improves performance by reducing broadcast traffic, enhances security by

isolating sensitive data, and simplifies management by grouping devices

according to function, department, or project.You can also associate an

already existing VLAN to the subnet.

● Name and provide a suitable description to quickly identify the new VLAN.

Also assign a suitable VLAN ID.

● Note: VLAN IDs are represented by a 12-bit number, but the usable range of

VLAN IDs is from 2 to 4094.

Note: DDI Central enables you to define Supernets and VLANs only to simplify

network administration. However, no advanced DHCP configurations, such as DHCP

options or Client Classes, can be implemented on the Supernets and VLANs.

 ​175

Also, when discovering your current configurations from your network infrastructure

using DDI Central discovery tools, it's crucial to note that VLANs and Supernets

configured in your network will not be discovered. Therefore, ensure that you

configure them separately in DDI Central for comprehensive and accurate network

management.

Address Pools

● An address pool within a subnet specifies the range of IP addresses available

for dynamic assignment.

● Pools are used to control the distribution of IP addresses to clients within a

subnet. They allow for more granular management of IP address allocations,

including setting different options or restrictions for different pools within the

same subnet.

● When configuring options at the subnet level, you can add and define the

pool or address range within the subnet that should be configured with a

specific set of options. Multiple combinations of options can be applied to

various address ranges within the same subnet.

 ​176

● Address pool configurations in a subnet can either allow or deny specific

client classes for dynamic IP provisioning. If "Allow" is set to "yes," the pool

permits provisioning for the chosen client class, while setting it to "NO"

excludes provisioning for that class. Choosing "none" means the address pool

is open for dynamic provisioning to all clients in the subnet without class

restrictions.
 ​177

DHCP scope visualization

DDI Central also lets you organize and manage the scopes in a hierarchical manner

by providing hierarchical tree-view that show how different scopes relate to one

another within the network. The DHCP scope tree view enables admins to quickly

locate and access specific scopes, subnets, to manage configurations and

troubleshooting tasks for a specific scope.

DDI Central provides flexible and powerful ways to manage IP address assignment
 ​178

and network configurations. Understanding these elements is crucial for network

administrators to effectively design and manage their network's IP addressing

scheme.

DHCP Fingerprinting With Client

Classes

Client Classes and Sub Classes

Client classes and Sub Classes are powerful features used to group clients (DHCP

clients) and apply specific DHCP options or behaviors to those groups. These

classes and subclasses enable more granular control over how DHCP services are

delivered to different types of clients on the network.

 ​179

Client Classes
● A client class in ISC DHCP is a grouping of DHCP clients that share common

characteristics. These characteristics are usually defined by matching

specific criteria in the DHCP discovery or request messages that the clients

send.

● Classes are used to apply different DHCP configurations to different groups of

clients. For example, you might have different classes for different types of

devices (like printers, laptops, and phones) or different operating systems.

Example of a Client Class:

1 class "Printers" {

2 match if substring(hardware, 1, 3) = 00:11:22;

3 }

4 subnet 192.168.1.0 netmask 255.255.255.0 {

5 pool {

6 allow members of "Printers";

7 range 192.168.1.50 192.168.1.60;

8 }
 ​180

9 }

● In this example, a class named "Printers" is defined, which includes any client

whose MAC address starts with 00:11:22. Printers are then assigned IP

addresses from a specific range.

Subclasses
● A subclass in ISC DHCP is a more specific grouping within a class. Subclasses

are defined based on a subclass-specific value, such as a MAC address or a

client identifier.

● Subclasses allow for even more specific targeting of DHCP options and

configurations. They are useful in scenarios where a broad class needs to be

divided into finer groups.

Example of Subclasses:

1 class "MobileDevices" {

2 match if substring(option vendor-class-identifier, 0, 6) =

 ​181

"iPhone" or substring(option vendor-class-identifier, 0, 7) =

"Android";

3 }

5 subclass "MobileDevices" "iPhone" {

6 match if substring(option vendor-class-identifier, 0, 6) =

"iPhone";

7 }

9 subclass "MobileDevices" "Android" {

10 match if substring(option vendor-class-identifier, 0, 7) =

"Android";

11 }

● Description: This configuration first defines a broad class for mobile devices,

and then two subclasses for iPhones and Android devices, respectively. Each

subclass can then be given different IP ranges, options, or policies.

 ​182

Applications and Benefits

1. Customized Configuration: Allows network administrators to tailor DHCP

settings to the specific needs of different devices or user groups.

2. Network Management: Easier management of network resources and

policies by segmenting clients into manageable groups.

3. Policy Enforcement: Enforces different network policies for security, access

control, or bandwidth allocation based on client type.

Configuring Classes and Sub Classes in

DDI Central

To create a client class;

● Go to DHCP-> Network-> Client Class

● The Create Client Class page appears on the screen.

● Assign the Client class a unique name.

● ASSIGN TO: Assign the scope level for the client class, whether its

configurations should be applied for the matching client on a specific subnet

 ​183

level or global level. The Global option suggests it could be applied across all

subnets, whereas a specific Subnet could be chosen to restrict the class to a

particular network segment.

● CLASS TYPE: The class type field likely refers to the basis of the class

definition. Template might be an option here indicating that this class is a

template that can be reused or that you are creating this class based on a pre-

defined template.

● MATCH TYPE: This defines the method by which the DHCP server will match

clients to this class. Substring indicates that the server will look for a

matching string of characters within the client's DHCP messages.

● OFFSET: In the context of matching by substring, this defines the starting

position in the client's DHCP message where the matching should begin.

● LENGTH: This specifies the length of the substring that the DHCP server

should match against the client's DHCP message.

● MATCH STRING: The actual string of characters the DHCP server will look for

in the client's DHCP message to determine if it belongs to this client class.

● CONDITIONAL STATEMENT: This field allows for more complex matching

rules, perhaps using logical or comparison operators to evaluate whether

clients meet the criteria for this class.

 ​184

● Match Value / Sub Class: This section has a checkbox that is used to indicate

whether a match value should be used to further define subclasses within this

client class.

● MATCH VALUE: If subclasses are being defined, this field would be where you

specify the value that differentiates each subclass.

● DHCP OPTIONS: Here, you would specify any DHCP options that should be

applied to clients within this class. These could include options like DNS

servers, domain name, lease time, etc.

● CUSTOM OPTIONS: This section is likely for defining additional DHCP options

that are not part of the standard set, which could be specific to the

organization or the DHCP server software being used.

● Cilck Save.
 ​185

Classes and subclasses in DDI Central add flexibility and precision to DHCP

management, enabling complex scenarios and specific requirements to be met

efficiently. This is particularly useful in large or diverse network environments.

DHCP Fingerprinting with Client

Classes
 ​186

DHCP fingerprinting, a method of device identification through DHCP, leverages

client class parameters to provide a means for more granular network management

and resource allocation. This process involves the DHCP client sending additional

information to the DHCP server, which in turn uses this information to identify the

type of client and assign IP addresses or parameters accordingly. This technique is

especially useful in environments where different types of devices require distinct

network configurations or policies.

How DHCP Fingerprinting Works:

1. Client Class Parameters: When a DHCP client requests an IP address, it can

provide additional information in the form of vendor class identifiers (VCI) or

user class identifiers (UCI). These identifiers are part of the DHCP discovery or

request packets.

2. Server Recognition: The DHCP server is configured to recognize these

identifiers and categorize clients into different classes based on the provided

information.

Applications of DHCP Fingerprinting:

● Differentiated Resource Allocation: You can dedicate one address pool for

specific types of devices, like VoIP devices, and a separate pool for data
 ​187

devices. This is useful in networks where different device types have different

network requirements.

● Policy Enforcement: For source routing policies, where voice and data

packets are routed differently, DHCP fingerprinting helps in applying these

policies right from the point of network entry.

● Administrative Segmentation: In a large organization, managing devices

based on their type (like printers, workstations, mobile devices) becomes

easier with DHCP fingerprinting.

Example Scenario:
Consider a network where VoIP devices and data devices need to be segregated:

1 class "VoIP-Phones" {

2 match if substring(option vendor-class-identifier, 0, 4)

= "VoIP";

3 }

4 class "Data-Devices" {

5 match if substring(option vendor-class-identifier, 0, 4)

!= "VoIP";

6 }
 ​188

8 subnet 192.168.1.0 netmask 255.255.255.0 {

9 pool {

10 allow members of "VoIP-Phones";

11 range 192.168.1.10 192.168.1.50;

12 }

13 pool {

14 allow members of "Data-Devices";

15 range 192.168.1.51 192.168.1.100;

16 }

17 }

● In this configuration, two classes are defined based on the vendor class

identifier. VoIP phones are assigned IP addresses from a specific range,

separate from the range used for data devices. The same can be configured

using DDI Central GUI using templates or the above can be given ISC bind

format in the Condition text box and simply click Save.

 ​189

Benefits of DHCP Fingerprinting:

● Efficient Network Management: Allows for the dynamic assignment of IP

addresses and configurations based on device type, improving network

efficiency.

● Enhanced Security: Helps in implementing security policies tailored to

different device types.

● Quality of Service (QoS): Ensures that devices like VoIP phones that require
 ​190

higher QoS receive the necessary network configurations.

● Scalability: Makes the network more adaptable to the addition of new types of

devices without requiring major configuration changes.

Considerations:
● Accuracy: The accuracy of DHCP fingerprinting depends on the uniqueness

and consistency of the vendor or user class identifiers provided by the

devices.

● Configuration Complexity: Implementing DHCP fingerprinting can add

complexity to DHCP server configuration and requires thorough planning and

testing.

DHCP fingerprinting is a powerful tool in network administration, enabling the

categorization and appropriate management of different types of devices within the

network. It enhances the capability to efficiently allocate network resources, enforce

policies, and ensure optimal performance for all devices.

DHCP Options
 ​191

Table of Contents

DHCP Options 2

Options for IPv4 and IPv6 3

DHCP Option Configuration Levels 4

Global Configuration 4

Subnet Level 4

Pool Level 5

Client Class Level 5

Host Level 5

Shared Network Level 5

Options precedence in DHCP 6

 ​192

DHCP Options
DHCP (Dynamic Host Configuration Protocol) options are additional pieces of

configuration information that can be provided by a DHCP server to DHCP clients

during the lease negotiation process.

These options offer a standardized way to communicate various parameters and

settings to devices on a network dynamically. Each DHCP option is identified by a

specific code, and the values associated with these codes convey specific types of

information.

Here are some common DHCP options and what they typically do:

1. Subnet Mask (Option 1): Provides the subnet mask information, allowing

devices to understand the network's subnet structure.

2. Router/Gateway (Option 3): Specifies the IP address of the default gateway or

router that devices should use for routing traffic outside their local subnet.

3. Domain Name Server (DNS) (Option 6): Supplies the IP addresses of DNS

servers that devices can use to resolve domain names to IP addresses.

 ​193

4. Domain Name (Option 15): Specifies the domain name for devices on the

network.

5. Time Offset (Option 2): Provides the time zone offset in seconds from

Coordinated Universal Time (UTC).

6. NTP Servers (Option 42): Supplies the IP addresses of Network Time Protocol

(NTP) servers, allowing devices to synchronize their clocks.

7. Hostname (Option 12): Communicates the preferred host name for the client.

8. Broadcast Address (Option 28): Informs devices about the broadcast address

for their subnet.

9. TFTP Server Name (Option 66): Specifies the hostname or IP address of a

TFTP server. Often used in VoIP deployments for firmware updates.

10.Bootfile Name (Option 67): Specifies the name of the boot file that devices

should load from a TFTP server.

These options enhance the DHCP process by providing crucial configuration details,

allowing devices to function properly within a network without manual

configuration. DHCP options are particularly useful in scenarios where a large

number of devices need to be configured dynamically and consistently across the

 ​194

network. Different DHCP options cater to various aspects of network configuration,

from addressing to naming and time synchronization.

Options for IPv4 and IPv6

DHCPv4 (Dynamic Host Configuration Protocol for IPv4) and DHCPv6 (Dynamic Host

Configuration Protocol for IPv6) have separate sets of options. Each version of the

DHCP protocol has its own set of option codes to convey specific configuration

information to DHCP clients.

While some options may serve similar purposes in both DHCPv4 and DHCPv6 (e.g.,

DNS options), the option codes and formats are different due to the differences in

the underlying IP versions and the specific requirements of each protocol.

DHCP Option Configuration Levels

DHCP options can be applied at different levels within a DHCP server's

configuration. The application of options depends on the DHCP server software

 ​195

Here are common places where DHCP options can be applied:

Global Configuration
Options can be set at the global level, affecting the entire DHCP server. This is useful

for settings that are common to all scopes or subnets.

Subnet Level
DHCP options can be configured at the subnet level. Each subnet declaration in the

DHCP server configuration can have its own set of options. This allows for

customization based on the characteristics of each subnet.

Pool Level
Within a subnet, you define address pools. Options can be set at the pool level,

affecting the devices that receive IP addresses from that specific pool. Useful for

fine-grained control over specific ranges of IP addresses.

Client Class Level

Client classes group DHCP clients based on certain characteristics, such as

hardware type, client identifier, or other parameters.This allows for customization

based on the type or characteristics of DHCP clients. Once clients are grouped into
 ​196

classes, specific DHCP options can be applied selectively to those classes.

Host Level
Options can be set for specific hosts, providing individualized configuration

parameters. This is useful when you need to apply specific settings to particular

devices.

Shared Network Level

Options can be configured specifically for a shared network. Configurations at this

level apply to all subnets within that shared network. It allows for common settings

across multiple subnets.

Options precedence in DHCP

In ISC DHCP, options can be specified at multiple levels, and the server determines

which options to apply to a client based on a defined precedence. The typical order

of precedence for DHCP options in ISC DHCP is as follows:

1. Host-Specific Options: The highest precedence. If options are defined for a

 ​197

specific host (identified by its MAC address or client identifier), these options

override all others.

2. Class and Subclass Options: If the host is a member of a defined class or

subclass, options set for these take precedence next, unless overridden by

host-specific options.

3. Pool-Level Options: Options defined at the pool level come after class and

subclass options. These are specific to a range of IP addresses and override

subnet, shared-network, and global options for clients receiving an IP from

that pool.

4. Subnet-Specific Options: Options defined for a specific subnet. These are

applied to all IPs within the subnet unless overridden by higher precedence

options (like pool, class, subclass, or host).

5. Shared-Network and Global Options: Shared-network level options come

next, followed by global options which are the default settings across the

entire DHCP server.

6. Client-Requested Options: Lastly, if clients request specific options in their

DHCP requests, the server will provide these options if they are available and

configured, respecting the above precedence rules.

 ​198

DDI Central processes and applies the options according to these rules when

determining the final set of options to send to a DHCP client in the offered lease. It's

important to note that the most specific option will take precedence in the case of

conflicts, with host declarations being the most specific and global options being

the least specific.

Custom DHCP Options

Table of Contents

About Custom DHCP options 2

Custom Option- Data Types 5

Boolean Type Options 5

Integer Type Options 6

String Type Options 6

 ​199

Text Type Options 7

IPv4 Address Type Options 7

IPv6 Address Type Options 8

Array Type Options 8

Encapsulated Type Options (Option Spaces) 9

Record Type Options 10

About Custom DHCP options

Defining custom DHCP options enable network administrators to extend and tailor

DHCP functionality beyond the standard configuration parameters. Custom DHCP

options provide a way to convey specific information to DHCP clients during the

lease negotiation process. Here's a general process for defining custom DHCP

options:

In ManageEngine DDI Central, Custom Options are defined and values are provided

within the respective fields provided within the GUI by specifying details like: the
 ​200

user-defined option name, code, and any data type restrictions as shown in the

image below. These custom options can be defined at multiple levels. To define

cluster level custom options, go to DHCP-> Config-> Custom Option.

[option-name] [option-space] [option-description] [option- data-type] [option-

code] are the parameters that help define a custom DHCP option.

To create a Custom option in DDI Central:

Click on the green + (plus) button besides the Options dropdown box.

The Add Definition window appears. Here you can declare and define your

new Custom option in DDI Central:

 ​201

1. NAME: This is a required field where you would enter the name of the new

custom option you are defining. It should be a unique identifier that

accurately describes the option you're adding.

2. USE EXISTING SPACE: This toggle indicates whether the new custom option

should be added to an existing set of options (an option space) or if it's going

to define a new one. If the toggle is enabled (turned on), you should select an

existing space from the OPTION SPACE field.

 ​202

3. OPTION SPACE: If you are using an existing space (as indicated by the toggle

above), you would enter the name of that space here. This would be the

grouping or category under which your new option will be classified.

4. DESCRIPTION: This required field is where you would provide a detailed

explanation of what the custom option does and what values it expects; the

valid punctuation like: some data types accept only spaces while some

options accept comma separated values. The description helps users

understand the purpose, grammar, and usage of the option.

5. DATA TYPE: Here, you choose the type of data the custom option will use. The

data types include boolean, string, integer, IP address, etc., depending on

what the system allows.

6. CODE: This is a required field where you enter the specific code that identifies

the custom option. This is often a numeric value that is used in configuration

files or by the system to recognize the option.

7. Save Button: After filling out all the necessary information, click Save to save

the new custom option to the system.

 ​203

Note:

The option-name must be different from server-defined options and consist of

alphanumeric characters and '-'.

The option-code is typically between 128 and 254.

Supported option-types include boolean, integer[(signed) integer8, 16, 32,

unsigned integer 8, 16, 32], string, text and IPv4 or IPv6 address, array of IP

addresses, record and encapsulation.

Custom Option- Data Types

Boolean Type Options
The ISC BIND declaration format is shown below along with an example definition of

a boolean option named my-option with code 209.

Declaration: option my-option code 209 = boolean;

Once declared, this option can accept values based on the grammar defined.

Setting: option my-option true;

 ​204

Integer Type Options

Options of data type integer include specification of signed or unsigned (or blank)

and integer length of either 8, 16, or 32 bits.

Declaration: option bits-per-sec code 210 = unsigned integer 32;

Setting: option bits-per-sec 1544000;

String Type Options

A string type option consists of a hexadecimal-encoded colon-separated octet

string.

Declaration: option mac-manufacturer code 211 = string;

Setting: option mac-manufacturer a4:80:1f;

 ​205

Text Type Options

Text type options specify values encoded as ASCII text strings.

Declaration: option your-help-contact code 212 = text;

Setting: option your-help-contact 'John Smith';

IPv4 Address Type Options

The IP-address data type enables specification of an IPv4 address or resolvable

domain name.

Declaration: option our-file-server code 213 = ip-address;

Setting: option our-file-server 10.0.209.12;

 ​206

option our-file-server fileserv1.ipamww.com;

IPv6 Address Type Options

The IP6- address data type enables specification of an IPv6 address

Declaration: option our-video-server code 214 = ip6-address;

Setting: option our-video-server fc01:273e:90a:2::b1 ;

option dhcp6.some-server code 1234 = array of ip6-address;

option dhcp6.some-server 3ffe:bbbb:aaaa:aaaa::1, 3ffe:bbbb:aaaa:aaaa::2;

Array Type Options

Array options provide a way to specify multiple values for boolean integer or IP
 ​207

address data type values (all of the same type) by simply inserting 'array of' before

the data type. Array elements are defined when setting the option values using

comma-separated values.

Declaration: option my-ip-array code 198 = array of ip-address;

Setting: option my-ip-array 10.0.100.1 10.100.0.1;

Note:

Options can contain arrays of any of the supported data types except for the text

and string types, which aren’t currently supported in arrays.

Encapsulated Type Options (Option Spaces)

An option space groups multiple options, typically with a common purpose. This

grouping of options can be 'encapsulated' within a single user-defined option code.

Consider the example of creating a db option space to specify some database

connection suboptions.
 ​208

Declaration: option space db;

Setting value:

option db.db-server code 1 = ip-address;

option db.loginid code 2 = text;

option db.db-name code 3 = text;

option database-encapsulated code 221 = encapsulate db;

The first line option space db; defines the db option space. Next three suboptions

are defined within this space. Each suboption has a unique code which is typically

numbered from 1 since these are suboption code values. These suboptions are

encapsulated within the parent option of code 221 named database-encapsulated.

The setting statements below would set values to suboptions 1 2 and 3 encapsulated

within option 221.

Setting: option db.db-server 10.199.200.37;

option db.loginid 'database';

option db.db-name 'mydatabase';

 ​209

Record Type Options

While array options provide specification of multiple elements of the same type,

Record types options enable specification of multiple elements of different

types. Each element of the record is specified in order in the UI.

The following example defines an option of data type record including an integer (16

bit) text boolean and IP address as input values..

Note:

Unlike arrays, record element values accept only space separated not comma

separated.

Definition: option my-rec code 198 = { integer 16 text boolean ip-address };

Values: option my-rec 4096 'cio' true 10.10.99.12;

Configuring DHCP Failover

Note: ManageEngine DDI Central does not offer DHCP failover for IPv6 address

space. Failover is only available for IPv4 address space.

 ​210

To configure the DHCP failover configurations:

● Go to DHCP ->Config-> DHCP Failover

● Click on the Add DHCP Failover button on the top right corner.

● The Create Configuration page appears on the screen. Here enter the values

for the fields as shown in the image

Primary DHCP
 ​211

The primary DHCP server is the main server responsible for handling DHCP requests

and managing IP address leases. It works in conjunction with a secondary server to

provide redundancy and high availability. The primary server typically handles the

majority of DHCP requests and coordinates with the secondary server to ensure

lease database synchronization and service continuity.

Primary DHCP Port

Specify the network port number that the primary DHCP server will use for its

operations. The default port for DHCP services is typically 67 for servers. However, in

certain network configurations or for specific security or operational reasons, you

might choose to customize this port number. It's important to ensure that this port is

consistent and properly configured in both the primary and secondary DHCP servers

to facilitate smooth communication and service operation.

Secondary DHCP

Specify the configuration of the backup DHCP server. In a DHCP failover setup, there

are typically two servers: a primary and a secondary. The secondary server is on
 ​212

standby to take over the DHCP responsibilities if the primary server becomes

unavailable. This ensures continuity of service.

Secondary DHCP Port

Allows you to specify the network port number that the secondary DHCP server will

use for communication. The standard port for DHCP is 67 for servers and 68 for

clients, but this setting can be customized if needed.

MCLT (Maximum Client Lead Time)

MCLT is a crucial parameter in DHCP failover configurations. It defines the maximum

time that a DHCP client can extend its lease on an IP address without contacting the

server. This setting is important for ensuring consistency between the primary and

secondary DHCP servers in terms of lease information. It is defined only on the

primary DHCP server.

 ​213

Split

Split is a special property that enables you to specify the percentage of the IP traffic

to be handled by your Primary and Secondary Servers as a means of load balancing.

It is defined only on the primary DHCP server. Its values range from 0 to 256.

A value 256 indicates no load balancing. Even if the failover is enabled for a DHCP

server. The primary DHCP Server is the one solely responsible for listening and

serving the address requests.

A value 0 indicates that most of the requests are handled by the Secondary DHCP

server configured to handle the Failover .

A value of 128 means 50-50 load balancing where both the primary and the

secondary DHCP servers configured for a specific range of IP addresses equally

listen and serve the IP resources.

Max Response Delay

 ​214

Determines the maximum time a DHCP server will wait before responding to a client

request. This parameter is important for efficient allocation of IP leases and ensures

that clients are not left waiting too long for a response, which could lead to network

access issues.

Max Unacked Updates

In a DHCP failover configuration, the primary and secondary servers synchronize

lease information with each other. This setting controls the maximum number of

updates (regarding lease information) that can be sent from one server to another

without receiving an acknowledgment. It's important for ensuring that both servers

have consistent and up-to-date lease information.

Load Balance Max Seconds

This parameter sets the maximum time a DHCP server in a failover pair will wait to

receive a response from its partner during load balancing operations. It ensures that

if one server is not responding (possibly due to being down or overloaded), the other
 ​215

server can take over more of the load to maintain service continuity.

Click Save to bring the failover configurations into effect. Select the failover server

you create while enabling failover for each scope you define in DDI Central.

DHCP Scope Audit Logs

The DHCP scope audit logs page provides you an overview of the actions performed

on each scope configured in your network. It help you to continuously evaluate the
 ​216

overall security posture of your scopes using security audit logs to track the who,

what, and when with respect to each DDNS Zone, VLAN, Supernet, Custom Options,

Options, Pool Data, Client Class, Host, Host Group, Shared Network and Subnet.

Access the DHCP scope audit logs by navigating to DHCP-> Audit .

You can also filter the logs for filtering the specific activities carried out by a specific

user, or a specific activity carried out around a certain time frame on a particular

DHCP scope to detect security breeches and malpractices.

Regularly reviewing your DHCP security logs helps you ensure that the access
 ​217

control mechanisms are performing adequately, determine whether users are

sticking to your security practices, and catch new potential security weaknesses.

About IP Address Management

IPAM is a comprehensive system designed to plan, track, and manage IP address

space within a network for smooth identification and communication. It provides a

centralized repository for IP address information, offering administrators a bird’s eye

view of the network infrastructure to oversee the allocation and usage of IP

addresses.

ManageEngine DDI Central's IP Address Manager serves as the linchpin in

maintaining a robust and efficient network infrastructure. By seamlessly integrating

with your DNS and DHCP services, IPAM emerges as a key player in the evolving

landscape of network administration, offering not just solutions but a proactive

 ​218

approach to network management.

The IPAM Stats Dashboard

The IPAM stats dashboard presents an overview of the DHCP scopes or network

topological units.

To access ManageEngine DDI Central's IPAM:

1. Log into ManageEngine DDI Central with your login credentials.

2. Select the IPAM menu from the left menu bar. With the IPAM selected, an inner

menu bar appears parallel to the left menu bar.

3. By default, the Stats menu is selected in the inner menu bar.

The IPAM stats offering insights on the IP address inventory managed by your DHCP

server, referred as the Stats dashboard appears on screen. View IP address statistics

for DHCPv4 and DHCPv6 address spaces using the toggle at the top right corner.
 ​219

Total Subnet Usage

Provides quick insights on the overall utilization of all subnets within a network

infrastructure. It provides an aggregate view of the allocated and available subnets,

offering a comprehensive understanding of the subnet distribution across the

network.

Usage per Subnet

 ​220

Displays a bar graph showcasing the top 5 subnets with the highest IP utilization

percentage within each subnet managed by the DHCP server.

Devices Usage
Device Usage statistics provide insights into the distribution of assigned IPs among

various hardware vendors.

IP Usage
Displays bar graphs illustrating the total number of fixed, available, and active IPs in

the entire IPv4/IPv6 address space managed by the DHCP server.

Analyzing Lease and Lease History

To access the lease records of the DHCP server:

● Select the Lease menu from the left inner menu bar.
 ​221

● The Lease page appears displaying the list of IP addresses currently leased by

the DHCP server from a specific subnet, along with its the total lease duration,

the current availability state of the IP, the MAC address and the manufacturer

details of the host device associated with the IP during the lease period.

Note:

You can also export these lease records and download them as a CSV file for future
 ​222

references.

To select a different subnet, click on the dropdown box at the top right end and

choose the specific subnet by its network address.

Click on an IP address to probe through the lease history of that particular address.

The History page for the IP address appears displaying the following sections:
 ​223

DNS Relations
The DNS relations section displays a list of domain name records that was previously

leased with the selected IP address. It includes information such as the type of

record, the exact Fully Qualified Domain Name (FQDN) linked to the record, and the

root domain of the record.

History
The history section provides a comprehensive audit trail detailing the evolution of

the IP over time. It includes information on the host, identified by its MAC address

and the manufacturer of the host device, to which the IP was leased and the duration

of that lease. Additionally, it records the type of connection and precisely indicates

the availability state of the IP during the entire span of the lease.

DNS Queries
The DNS Queries provides two sections to help you quantify and visualize the query

volume handled by the IP during its association with various FQDNs.

The section on the left, lists a historical overview of the total query volume to each
 ​224

specific FQDNs when the IP was associated with them.

Additionally, the section on the right helps you visualize, in the form of line graphs,

the hourly query volume handled by the IP when it was associated with different

domain names along a custom time frame. To analyze these hourly readings more

accurately, make sure you select a custom time frame from the drop down calendar

at the left corner within the same section.

Managing VLAN IP Address Inventory

To visualize and take control of the IP allocations for the VLANs managed by the

DHCP server:

● Select the DHCP -> VLAN menu from the left menu bar.
 ​225

● The VLAN page appears displaying the list of all VLANS serviced by the DHCP

server.

● Click on a VLAN entry from the list to view detailed stats on that specific VLAN

from the Stats page.

 ​226

● Along the the top section of the Stats page, find the VLAN ID and the VLAN

Name along with the essential details like: the dedicated subnet leasing IP

addresses to the VLAN, the total number of available IPs in the subnet for the

VLAN, the number of active IP addresses allocated to the VLAN.

● The mid section of the Stats page displays the following infographics:

VLAN Usage: Illustrates the percentage of IP usage within the VLAN.

 ​227

Number of IPs in the subnet: A doughnut plot that illustrates and quantifies

the volume of Subnet's IP addresses based on their availability states like:

● Available: IPs that are not currently assigned and are ready for

allocation.

● Active: IPs that are currently in use and assigned to active

devices on the network.

● Abandoned: IPs that were previously assigned but are no longer

in use or have been released.

● Fixed: IPs that are reserved for specific devices or purposes,

ensuring they are not allocated to other devices.

● Free: Typically includes both IPs that are available for immediate

assignment and those that are reserved but not currently in use.

At the bottom section, you'll discover a list of each IP address in the subnet

responsible for provisioning IP addresses to the VLAN, along with their

availability states. You can click on any Available or Free IP address to directly

configure it for a host that is supposed to connect with the VLAN.

 ​228

Note:

You can also search through the list for a specific VLAN by its VLAN ID. In addition,

You can directly export the VLAN stats and download them as a CSV file for future

references.

Managing Network IP Address

Inventory

To visualize and take control of the IP allocations of each subnet managed by the

DHCP server:

Select DHCP -> Manage IP menu from the left menu bar.

The Manage IP tab displays the following three sections:

 ​229

The first section - Manage IP on the left displays the list of available/free IP(s) within

the subnet. Click on any desired IP from the list. This directly takes you to the Host

Page. Here you can directly assign the chosen IP address to any host or client.

The second section- Number of IP (s) on the top right visually depicts the volume

of IP addresses in different availability states along a doughnut plot :

● Available: IPs that are not currently assigned and are ready for allocation.
 ​230

● Active: IPs that are currently in use and assigned to active devices on the

network.

● Abandoned: IPs that were previously assigned but are no longer in use or

have been released.

● Fixed: IPs that are reserved for specific devices or purposes, ensuring they are

not allocated to other devices.

● Free: Typically includes both IPs that are available for immediate assignment

and those that are reserved but not currently in use.

The third section-Subnet Usage, on the bottom right corner, illustrates the overall

percentage of IP utilization within that subnet.

Appendix 1- DNS options

Appendix 2- DHCPv4 options

 ​231

Appendix 3- DHCPv6 options

Appendix 4- DHCP service options

Apendix 5- Relay agent information

options

Appendix 6- Client FQDN options

Appendix 7- Netware/IP suboptions

​232