---
title: "Best Practices"
canonical: "https://docs.infoblox.com/space/DeploymentGuideDNSInfrastructureProtection/1871118338/Best%20Practices"
format: markdown
---
When deploying DNS Infrastructure Protection:

- DNS Infrastructure Protection should not be deployed on the same Layer 2 as Clients, or where DHCP requests are broadcast. For example, in production, we're running our DNS Infrastructure Protection in a /29, or /126 for IPv6
- Clients generate a lot of broadcast, especially port 5353, and other traffic which results in spurious/useless messages. DHCP broadcasts will also create unnecessary noise.
- If you are running DHCP, then the expectation is that you use DHCP relay to the DNS Infrastructure Protection.
- If you are not running DHCP, then the reason for local layer 2 messages need to be understood and resolved. In a Lab environment, just disable the syslog reporting of rules (set EPS to 0).
- In situations where a volumetric attack may be experienced against recursive servers, it is best to use LAN2 exclusively for recursion, providing a clear recursion path, and to also make use of ANYcast for LAN1.
- Make sure the Grid is using reliable NTP sources, a minimum of 3, and is fully synchronized.


**Profiles**

It is a best practice, especially for PoC’s, to utilize Profiles for all members. You can then leave the Grid version of the rules unaltered, and hence you can revert to the default rule settings for individual rules, or entire categories at any time. The only time you will need to change the Grid level rules is when you add custom rules.

**Rules**

- With the exception of the DHCP system rules in general, and the TCP/UDP rules DNS query without Recursion Desired, all system rules should be enabled.
- When viewing the rulesets, sort by Order. The Order is the evaluation order of the rules which can prove useful for debugging and understanding rule deployment.
- Events Per Second (EPS) should either be 0 or 1 so as to reduce the chance of death by syslog. Values greater than 1 should only be used for short debug sessions. EPS limits the number of syslog entries per rule per client that can be generated.
- Setting EPS to 0 will prevent syslog messages, but the counts will still be available on the reporting server.
- Whitelisting should never be used, unless you have total and immediate control over the whitelisted client, and the reason is to give you a chance to formulate an appropriate remediation.
- Remember that like with a firewall ruleset, the last rule drops all. There must be an explicit pass somewhere (i.e. don’t disable every rule).

**Reporting**

- It is strongly recommended to have a Reporting member in the Grid.
- If you have not purchased a Reporting Member, you can consider deploying the free version.
- Remember to enable the security index.

**System alerts**

A Grid Master is able to generate SNMP and email alerts. Since these are real time, they should be configured for the categories that matter.

- System CPU/Memory/NIC usage
- Cache hit ratio
- NXDOMAIN hits
- Any issues with the status of services (DNS/DHCP/NTP/...)
- Notifications on Infrastructure Protection dropped traffic and Infrastructure Protection total traffic

**SIEM**

Use of any SIEM (Security Information and Event Management tool) is highly recommended since a great deal of Syslog information can be generated.

**Unresponsive Servers**

Recursive servers that aren’t responding tie up resources on members.

In the **Security** tab in the **Grid DNS Properties**, it is recommended to turn on the following two options:

- Limit recursive queries per server
- Limit recursive queries per zone

![image-20250417-002253.png](media://88d61dcf-f558-4342-9ef6-397eaeb957aa)