Differences

This shows you the differences between two versions of the page.

--- infoblox_threat_defense:dfp [2025/11/08 11:31] – bstafford
+++ infoblox_threat_defense:dfp [2025/11/12 15:28] (current) – [Add/Copy Source IP] bstafford
@@ Line 7: / Line 7: @@
 DFP will maintain a management channel network session to BloxOne cloud. It will also maintain a separate DNS resolution channel (DNS-over-TLS on TCP-443). The management channel may be closed when not needed. DFP will try to keep the DNS resolution channel open but this isn't guaranteed.
-NOTE: If you connect NIOS to CSP and enable DFP, if you then "reset all license" and re-configure the NIOS box, it will auto-reconnect to CSP and auto-reconnect the DFP service.
+NOTE: If you connect NIOS to CSP and enable DFP, if you then "reset all license" and re-configure the NIOS box, it will auto-reconnect to CSP and auto-reconnect the DFP service (i.e. the join token survives the reset and license deletion)
 ===== Local On-Prem Resolution =====
@@ Line 24: / Line 24: @@
 If both Add and Copy are both ticked, Copy trumps add (i.e. if there is anything to copy, 'add' is not run as an action. If there is nothing to copy, add will run as an action).
+NOTE: Consider enabling ADD only for the DNS server that clients query directly. This prevents a malicious user from spoofing the source IP by adding their own EDNS0 data. By having ADD only, Infoblox will wipe the EDNS0 data and add the true source IP. If you set COPY at the client facing resolver, then spoofed entries can make their way up to Threat Defense Cloud. You can then set COPY at the recursive caching layer that sits (if it exists) between the DNS servers that clients query and the Threat Defense cloud.
 ===== DHCP/IPAM =====
@@ Line 131: / Line 133: @@
 Note, if NIOS is using DFP (rather than "direct global forwarding" to the TD Anycast IP addresses - which isn't recommended), and if the CSP applies a "redirect" to a query because it matched a security policy rule with "Redirect" as the action, and if the query is for a domain that has DNSSEC validation enabled, and if NIOS has DNSSEC validation enabled AND has Trust Anchors enabled, then the query will fail with SERVFAIL. This is because if NIOS has DNSSEC validation enabled AND has Trust Anchors enabled, then NIOS will try and run DNSSEC validation on the answer it gets back from DFP by using root hints. NIOS will use root hints for DNSSEC validation regardless of the DFP config.
+Assuming DFP is healthy:
+NIOS
+  * DNSEC Disabled (no trust anchors). Fallback Disabled. - IP answer and no log in Portal. 630 msec to resolve
+DNSEC Enabled (no trust anchors). Fallback Disabled. - SERVFAIL and also SERVFAIL log in Portal. 532 msec to resolve. Response cached locally for about 5 seconds.
+  * DNSEC Enabled (no trust anchors). Fallback Enabled. - IP answer and no log in Portal. 630 msec to resolve
+  * DNSEC Disabled (no trust anchors). Fallback Enabled. - IP answer and no log in Portal. 630 msec to resolve
+NIOS-X (DFP+DNS)
+Disable Signature Validation on DNS = You get IP and no log
+Enabled Signature Validation on DNS and NO Trust Root Anchor = You get SERVFAIL and log generated
 If a NIOS member is HA, make sure to add both nodes of the member to CSP and to enable a DFP service for BOTH nodes. If you don't, only the node with the DFP service can use DFP. If that node is becomes passive, then the active node will process DNS without DFP. WARNING: be sure to be careful when naming the host instances in the Infoblox Portal. Match the serial numbers to the actual NIOS serial numbers to make sure you don't mix up node A and node B as that just leads to confusion down the line.