Differences

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

--- infoblox_uddi:dns [2026/01/21 07:49] – created bstafford
+++ infoblox_uddi:dns [2026/02/24 02:01] (current) – bstafford
@@ Line 1: / Line 1: @@
 ====== NIOS-X DNS ======
+===== Forward Only=====
 The "Forward only" option in NIOS-X. You can only tick this if at lease one forwarder is set. If a forwarder is set and "Forward only" is ticked, then recursion will never be used. If the forward 'target' servers go down then you loose the ability to resolve DNS that you are not authoritative for. If you untick "Forward only" then the BloxOne DDI appliance can fall back to recursing directly to the Internet to resolve queries.
+===== DDNS Updates=====
 NIOS DDNS Updates are processed by the primary member, synced to GM, GM then pushes to secondaries. If GM is offline, secondaries don't get data. If Secondary if offline, GM will queue until it is back online. For NIOS-X, members proxy DDNS update to cloud, cloud processes change, cloud pushes to all NIOS-X members. Cloud only queues for a few seconds. If NIOS-X host is offline, it won't get the updates.
-===== 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).
-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.
-===== 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:
-  * 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''.
+====== Anycast ======
+DNS Anycast can work in public cloud but only when using "[[https://www.linkedin.com/pulse/delivering-anycast-dns-aws-infoblox-universal-ddi-cloud-alban-fetahi-x4awe|AWS Cloud WAN]]" (AWS) or "[[https://www.linkedin.com/pulse/delivering-anycast-dns-azure-infoblox-universal-ddi-virtual-fetahi-mooce|Azure Virtual WAN]]" (Azure).
-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.
+===== TTL =====
+External DNS - 24h TTL minimum
-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.
+Internal DNS - 8h TTL should be fine especially for static records (should never go below 1 hour). For dynamic DNS records, look at DHCP lease time.
-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>