Differences

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

--- infoblox_threat_defense:security_policy [2026/01/21 09:38] – bstafford
+++ infoblox_threat_defense:security_policy [2026/01/21 09:41] (current) – bstafford
@@ Line 3: / Line 3: @@
 ===== Local Resolution =====
-BloxOne DFP and Endpoints are able to "resolve locally". This option is only available for B1 Threat Defense customers as BloxOne DDI customers cannot send queries to the cloud in the first place (i.e. all queries are resolved locally).
+NIOS-X DFP and Endpoints are able to "resolve locally". This option is only available for Infoblox Threat Defense customers as customers with only Universal DDI cannot send queries to the cloud in the first place (i.e. all queries are resolved locally).
-B1 Hosts, NIOS DFP and B1 Endpoints can be configured to resolve queries locally on an Application by Application basis as configured in the security policy rule. if B1DDI is purchased, they can also be configured to resolve everything locally and use B1TD for security lookup only. The caveat for NIOS is that local resolution (be it for a single application or for all traffic) requires that the DNS server acting as a DFP must not use root hints. It must be configured to forward all queries to another DNS server (remember, so long as DFP is up and running, the "forward to x.x.x.x" will be ignored unless the security policy says to resolve locally or resolve a specific application locally. B1 DDI hosts don't need to "forward only" as they can use root hints to resolve local traffic.
+NIOS-X hosts, NIOS DFP and B1 Endpoints can be configured to resolve queries locally on an Application by Application basis as configured in the security policy rule. If Universal DDI is purchased, they can also be configured to resolve everything locally and use Infoblox Threat Defense for security lookup only. The caveat for NIOS is that local resolution (be it for a single application or for all traffic) requires that the DNS server acting as a DFP must not use root hints. It must be configured to forward all queries to another DNS server (remember, so long as DFP is up and running, the "forward to x.x.x.x" will be ignored unless the security policy says to resolve locally or resolve a specific application locally. NIOS-X hosts don't need to "forward only" as they can use root hints to resolve local traffic.
 ===== Security Policy Precedent =====
-For any FQDN being queried in B1TD Cloud, if the domain is a CNAME to another FQDN, then the CNAME FQDN is also checked against the security policy. If the original FQDN matches a security policy then the secondary FQDN that is CNAME point to is not checked/is irrelevant because:
+For any FQDN being queried in Threat Defense Cloud, if the domain is a CNAME to another FQDN, then the CNAME FQDN is also checked against the security policy. If the original FQDN matches a security policy then the secondary FQDN that is CNAME point to is not checked/is irrelevant because:
   * If the original domain is blocked, there is no point in checking the CNAME.
   * If the original domain is in an allow list, then we assume we must resolve the FQDN regardless.
@@ Line 15: / Line 15: @@
 Remember the hidden "PASSTRHU" list (e.g. ''infoblox.com'', ''pool.ntp.org, etc'') forms an invisible security rule "above" user defined security rules. This is why you can block fastly.net in your security policy but ''www.infoblox.com'' still resolves even through it is a CNAME to ''agcdn.pantheon.map.fastly.net''.
-Example: If you block ''agcdn.pantheon.map.fastly.net'' at the top of your security policy, then if have a CNAME ''www.example.com'' as a CNAME to ''agcdn.pantheon.map.fastly.net'' , you will find queries to ''www.example.com'' are blocked but queries to ''www.infoblox.com'' are still allowed because the PASSTHRU list is HIGHER than the user defined user rules.
+Example: If you block ''agcdn.pantheon.map.fastly.net'' at the top of your security policy, then if have a CNAME ''www.example.com'' as a CNAME to ''agcdn.pantheon.map.fastly.net'', you will find queries to ''www.example.com'' are blocked but queries to ''www.infoblox.com'' are still allowed because the PASSTHRU list is HIGHER than the user defined user rules.
 It is also important to remember that if a FQDN query is blocked because of the CNAME used, then the security log will only show the original FQDN and will not indicate that it was blocked because of a CNAME.