====== Security Policy ======
When you have "Local On-Prem Resolution" AND "Block DNS rebinding attacks" enabled on a security policy, then any NIOS-X or NIOS-X-as-a-Service instance that has conditional forwarding to on-prem servers that respond to internal domains with RFC1918 addresses will be blocked. This would also apply if NIOS-X was doing a global forwarder to a DNS server that also responds to internal domain. The "Block DNS rebinding attacks" just sees RFC1918 and blocks it.

===== Local Resolution =====
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).

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 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.
	
If you have a security rules that blocks the secondary CNAME domain and that rule is ABOVE any rule that allows the original FQDN or if there simply isn't an explicitly allow rule for the original FQDN, then the query will be blocked because of the block rule for the secondary CNAME.

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.

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.

It is almost as if B1TD cloud makes the query first and then checks the domain AND CNAME values against teh security policy. Since the block list is hit first and matches the CNAME redirect, the query is blocked. If it hit the allow list first (for the original domain) it would allow the query and not bother with the CNAME.

So, on receiving a query,
<code>IF query IN block list
	THEN block and end
ELSE (i.e. query in allow list OR query is not on a list)
	THEN 
	IF cname in block list AND is ABOVE any existing query allow rule.
		THEN block and end
	ELSE (i.e. cname is in block list BELOW query allow OR cname is in allow list OR cname is in no list)
		THEN allow query, resolve and end</code>
===== URL Filtering =====
When Infoblox filters a DNS name, it returns one of the following IP addresses
<code>52.4.105.248</code>
<code>3.215.231.251</code>
<code>35.168.95.233</code>
When you go to this IP, you will see the Infoblox block page.


ByPasscodes will redirect users to <code>https://smartproxy.b1tdc.infoblox.com</code>


If you access this page over HTTPS, the page will be signed by the Infoblox BloxOne Root CA.

You must install this certificate as a trusted Root CA to avoid browser errors.