This is an old revision of the document!
Table of Contents
InfoBlox Best Practice
If you are configuring a dual-stack network for the host, you must set the minimum MTU value for the IPv4 address to 1280; if you do not, the IPv6 address will not be functional.
DDI
- DNS - If the Round Trip Time (RTT) between client and DNS server is greater than 200ms, then the user starts to notice.
- DHCP - normally very tolerant of latency between client and DHCP server.
- NTP - normally very tolerant of latency between client and NTP server.
Return Minimal Responses
The option “Return Minimal Responses” should generally be disabled for external facing DNS servers.
It has been see that enabling “Return Minimal Responses” can cause issues when Microsoft clients query NIOS which has a forwarder to a Microsoft Active Directory domain controller.
This means it returns
;; ANSWER SECTION: _mssms_mp_swa._tcp.domain.internal.local. 14400 IN SRV 0 0 80 domaincontrollerhostname.domain.internal.local.
Instead of
;; ANSWER SECTION: _mssms_mp_swa._tcp.domain.internal.local. 14400 IN SRV 0 0 80 domaincontrollerhostname.domain.internal.local. ;; ADDITIONAL SECTION: domaincontrollerhostname.domain.internal.local. 1200 IN A 1.2.3.4 domaincontrollerhostname.domain.internal.local. 1200 IN AAAA 2002:2002:2002::2002:2002
That extra bit is needed by the Microsoft clients so “Return Minimal Responses” had to be disabled.
NIOS
- vNIOS for Hyper-V is not recommended as a Grid Master or Grid Master Candidate. Specifications
- When running NIOS in MS Hyper-V with dynamic memory allocation enabled, your system might experience high memory usage. To avoid this issue, Infoblox recommends that you disable dynamic memory allocation.
- For optimal performance, vNIOS for Hyper-V is not recommended as a Grid Master or Grid Master Candidate.
- DNS forwarding proxy is not supported on any appliance that is running on a memory lower than 4 GB. source
- There might be a significant performance impact on your appliance and network during the DNS forwarding proxy installation process depending on the network connectivity between NIOS and BloxOne Threat Defense. Every node will have to install the DNS forwarding proxy before serving DNS recursive queries, which includes the HA nodes. source
- If DHCP scavenging is not enabled, it should be, and it definitely can reduce the lease count. If scavenging is not enabled, leases remain in the database even after they have expired.
- Enable single client lease feature of DHCP.
- Enable the NIOS Object Change Tracking feature to reduce the quantity of data transferred. When you enable this feature, the appliance tracks the changes that are made to NIOS objects and periodically synchronizes changed objects.
- Enable Object Change Tracking (docs). Do this under Grid Properties.
- The Object Change Tracking feature is optimized to reduce impact on the DDI services and it runs only on the Grid Master. The synchronization process synchronizes 1000 objects at a time with a 2 second pause in between. There might be a slight impact on the Grid Master Candidate as they get updates from the Grid Master. When protocol services are running on the Grid Master Candidate you might encounter a 5% drop in the protocol performance. This feature does not impact the services that are running on the Grid members.
BloxOne
NOTE: The following notes do not reflect official Infoblox best practice. These are just notes that I've made along the way.
- BloxOne DNS zone should be assigned to an IPSpace. Failure to do so can result in licence issues as “used IP addresses” may be counted twice.
- OPH should be assigned to an IPSpace. Failure to do so can result in licence issues as “used IP addresses” may be counted twice.
- Consider adding cloudfront.net to the allow list. Cloudfront is a CDN. Unlike other CDN's (e.g. Fastly and Akamai) Cloudfront (used to?) allow uses to visit their URL's directly rather than through the original website using them as a CNAME. This can lead to URL filtering platforms (e.g. SURBL FP) to mark the cloudfront.net sub-domains as phishing, etc.
DNS
In accordance with RFC 6303 consider adding the following PTR zones as standard.
RFC 1918 Zones
- 10.IN-ADDR.ARPA
- 16.172.IN-ADDR.ARPA
- 17.172.IN-ADDR.ARPA
- 18.172.IN-ADDR.ARPA
- 19.172.IN-ADDR.ARPA
- 20.172.IN-ADDR.ARPA
- 21.172.IN-ADDR.ARPA
- 22.172.IN-ADDR.ARPA
- 23.172.IN-ADDR.ARPA
- 24.172.IN-ADDR.ARPA
- 25.172.IN-ADDR.ARPA
- 26.172.IN-ADDR.ARPA
- 27.172.IN-ADDR.ARPA
- 28.172.IN-ADDR.ARPA
- 29.172.IN-ADDR.ARPA
- 30.172.IN-ADDR.ARPA
- 31.172.IN-ADDR.ARPA
- 168.192.IN-ADDR.ARPA
(And from here)
- 100.51.198.IN-ADDR.ARPA
- 113.0.203.IN-ADDR.ARPA
RFC 5735 and RFC 5737 Zones
- 0.IN-ADDR.ARPA
- 127.IN-ADDR.ARPA
- 254.169.IN-ADDR.ARPA
- 2.0.192.IN-ADDR.ARPA
- 100.51.198.IN-ADDR.ARPA
- 113.0.203.IN-ADDR.ARPA
- 255.255.255.255.IN-ADDR.ARPA
Local IPv6 Unicast Addresses
- 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
- 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA
IPv6 Locally Assigned Local Addresses
- D.F.IP6.ARPA
IPv6 Link-Local Addresses
- 8.E.F.IP6.ARPA
- 9.E.F.IP6.ARPA
- A.E.F.IP6.ARPA
- B.E.F.IP6.ARPA
