Differences

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

--- infoblox_threat_defense:dfp [2025/03/24 15:22] – 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 13: / Line 13: @@
 Local On-Prem Resolution only works for NIOS-X and NIOS-XaaS. It does not work on NIOS nor Endpoint nor DoH nor External Networks. If you include any of these in any security policy that has "Local On-Prem Resolution", that functionality is just ignored on those platforms.
+===== Direct Query =====
+If you have DFP enabled on NIOS, then if you log onto NIOS CLI and make a dig command directed at a specific server (e.g. 8.8.8.8), then DFP will be bypassed. This allows you to test latency to other servers without interrupting DFP.
 ===== Add/Copy Source IP =====
 Also see [[https://www.staffordnet.uk/doku.php?id=infoblox_nios:forwarding#dfp_forwarding|Forwarding with DFP]]. Also see this page for information on what happens when Add/Copy is enabled but DFP is not running.
@@ Line 21: / 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 84: / Line 89: @@
 <code>forward only;
 forwarders { 127.0.0.1 port 1024; };</code>
+or (depending on whether **Fallback to the default resolution process if Infoblox Threat Defense Cloud does not respond** is enabled in NIOS DFP UI Config. See below for more details)
+<code>forward first;
+forwarders { 127.0.0.1 port 1024; };</code>
+If, and only if, you have enabled ''Fallback to the default resolution process if Infoblox Threat Defense Cloud does not respond'', then "forward first" is set. Keep in mind that while DFP is "HEALTHY" and BIND configuration has "forwarders { 127.0.0.1 port 1024; };" configured, it doesn't matter whether or not NIOS has global forwarders configured. Since DFP is HEALTHY, it means that the BIND configuration for forwarding/root hints recursion is overridden. Even if you have global forwarders and "forward only" configured in BIND, DFP being enabled means that is ignored. This means that DFP "fallback" will ALWAYS use root hints recursion because the global forwarding command configured in NIOS isn't readable while DFP is healthy.
 If the DFP on NIOS cannot access the four Threat Defense Anycast IP addresses, it will take about a minute to detect the failure. It will then remove the two lines of config (restoring original config if applicable; such as forwarding to 8.8.8.8) above from BIND and restart BIND to use local resolution configuration. During the BIND restart, DNS is also non-responsive. While BIND is being used locally for DNS, the DFP continues to monitor the Threat Defense Anycast IP addresses. When it determines that Threat Defense Anycast DNS is available once more, it will restart BIND to redirect queries to the cloud. The restart time on BIND will cause a DNS downtime for the network. This means that the failure>back-up time is over a minute while the back-up>normal DFP time is a few seconds.
@@ Line 93: / Line 105: @@
 If the local NIOS is told to use forwarders but NOT "only forwards" (i.e. forward first), then if you block the forwarder, all queries slow down as the NIOS still seems to try the forwarder each time. Wait and try something not in cache. (several seconds to resolve DNS),
-Note that blocking Anycast doesn't stop the DFP talking to CSP for MGMT (see [[infoblox:firewall_rules#nios_firewall_rules|NIOS Firewall Rules]])
+Note that blocking access to Threat Defense Anycast IP address doesn't stop the DFP talking to CSP for MGMT (see [[infoblox:firewall_rules#nios_firewall_rules|NIOS Firewall Rules]]) assuming that the "Infoblox Portal" configuration of the Grid or Member is not dependent on the Anycast IP address. The MGMT bit in Infoblox cloud runs on a separate set of IP addresses/domains.
 Note, in CSP you can configure Internal Domains on the DFP service. If configured, these will be applied to NIOS. This is in addition to any forward-forward zones configured in NIOS. The order is
@@ Line 103: / Line 115: @@
 Note, in CSP you can configure "Fallback Resolver" (External Resolver if you are a federal customer) but NIOS will ignore it and use its own fallback if configured in Grid or member DNS settings (i.e. root hints or, if configured, global forwarder).
-Note, if the CSP applies a security "redirect" on a value, if NIOS is using DFP and has DNSSEC validation enabled AND has Trust Anchors enabled, then the query will fail with SERVFAIL.
-If NIOS is HA, make sure to add both members to CSP and to enable a DFP service for BOTH members. If you don't, only the member with the service will work and if that member is passive, DFP won't work. WARNING. be sure to be careful when naming the host instances. Match the serial numbers to the actual NIOS serial number to make sure you don't mix up a and b. If you have only DFP service configured in CSP on one node and that node is the passive node in NIOS, DFP connectivity won't work.
+If you have the ''Fallback to the default resolution process if Infoblox Threat Defense Cloud does not respond'' option enabled in the NIOS DFP properties then if DFP returns a SERVFAIL to NIOS, NIOS will use root hints to try and resolve (if global forwarders are configured, they are ignored). You should NOT enable this feature if you also have DNSSEC validation and Trust Anchors enabled on NIOS. The reason is that an attacker may force a SERVFAIL for queries for a domain they own that come from Infoblox Cloud IP addresses. This forces NIOS to resolve the traffic locally because it can't tell the difference between SERVFAIL because the cloud is unavailable and SERVFAIL because DNSSEC validation failed for the query.
+When you enable ''Fallback to the default resolution process if Infoblox Threat Defense Cloud does not respond'', then the BIND configuration is updated (without requiring a BIND restart) from forward only
+<code>...
+	forward only;
+	forwarders { 127.0.0.1 port 1024; };
+...</code>
+to forward first.
+<code>...
+	forward first;
+	forwarders { 127.0.0.1 port 1024; };
+...</code>
+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.
 When using DFP, NIOS uses the LAN1 port to establish DoT on TCP-443 to Infoblox Anycast. This is true EVEN IF THE NIOS is HA. NIOS will not use the HA VIP for TCP-443. However, any plaintext queries will come from the HA VIP.
@@ Line 111: / Line 154: @@
 During HA failover, queries dropped for about 15 seconds in my lab.
-Internal Domains configured in CSP are only honoured if "Internal Resolver" is configured in DFP service instance of the NIOS appliance in the CSP.
+Internal Domains configured in CSP are only honoured if "Internal Resolver" is configured in DFP service instance of the NIOS appliance in the CSP. Ideally, internal domains hitting NIOS should be processed by native "conditional fowarders" in NIOS rather than being processed by DFP.
 When you join a NIOS member to the CSP, it may take 5-10 minutes to register fully.
 "Local On-Prem Resolution" in security policy only applies to DFP on NIOS-X. Not DFP on NIOS. Not Infoblox Endpoint. Not External Networks.
-If you have the ''Fall back to the default resolution process if Infoblox Threat Defense Cloud does not respond'' option enabled in the NIOS DFP properties then if DFP returns a SERVFAIL to NIOS, NIOS will use root hints to try and resolve (if global forwarders are configured, they are ignored).
 ===== IPAM Security Policy =====
-when you run a file of dig queries against a NIOS DFP, if you stop and start again, you get responses from cache. If you have two DFP and run one against the first DFP and then run the same against the second DFP, the DNS auth server gets both messages. This indicates the cache is in local NIOS itself.
+When you run a file of dig queries against a NIOS DFP, if you stop and start again, you get responses from cache. If you have two NIOS-X DFP only servers and run one against the first DFP and then run the same against the second DFP, the DNS auth server gets both messages. This indicates the cache is in local NIOS itself.
+If you have an IPAM based security policy in DFP (or local RPZ configured based on source IP), cache may will allow a client to bypass the security policy. If Client A is blocked from resolving example.com, then if Client B resolves example.com, it will be in cache and, while still in cache, Client A can resolve example.com. You can work around this by updating that NIOS member running DFP with a Max Cache TTL of something short (e.g. 1 second). This is done in the NIOS UI > Data Management > DNS > Members/Servers > Edit Member > General > Advanced > Max Cache TTL set value to 0.
-If you have an IPAM based security policy in DFP (or local RPZ for that matter), cache will allow a client to bypass the restriction. That is, if clientA is blocked from resolving example.com, then if clientB resolves example.com, it will be in cache and, while still in cache, clientA can resolve example.com. You can work around this with disabling cache (though that can impact performance) Member > DNS Views > Advanced > Max Cache TTL
 ===== NIOS DFP Logs =====
@@ Line 150: / Line 192: @@
 If you have LAN2 connected to Internet and you have LAN1 connected to internal network, and if LAN1 does not have internet access, you will need to add static routes to a NIOS appliance to get DFP working correctly. Specifically,
+  * 52.119.40.100/32
+  * 52.119.41.100/32
   * 103.80.5.100/32
-  * 52.119.41.100/32
-  * 52.119.40.100/32
   * 103.80.6.100/32
   * 3.209.116.255/32
   * 3.210.226.54/32
   * 3.212.42.44/32
-  * 18.235.149.1/32
+  * 3.214.29.106/32
+  * 3.214.194.152/32
+  * 3.213.214.20/32
   * 18.209.243.220/32
   * 18.233.189.178/32
-  * 3.213.214.20/32
+  * 18.235.149.1/32
-  * 3.214.194.152/32
-  * 3.214.29.106/32