DFP = DNS Forward Proxy

On NIOS, you don't have to put a domain into “Internal domains” for NIOS DFP to recognize a record for a forward zone. Just creating the forward zone in NIOS is enough for NIOS to forward as required without bothering the DFP. If you put block lists on the cloud security policy for zones that NIOS forwards to, the security policies won't do anything as they are not consulted by NIOS.

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.

Local On-Prem Resolution is supported for XaaS running Threat Defense. Both the security logs and the DNS logs will be visible in the Infoblox Portal. NIOS-X with “Local On-Prem Resolution” will only show Security Logs in Infoblox Portal.

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.

Also see Forwarding with DFP. Also see this page for information on what happens when Add/Copy is enabled but DFP is not running.

In NIOS you can configure global forwarders and set “Add” or “Copy” source IP. This feature is for forwarding only. It will not apply when (if) NIOS reverts to recursing using root hints.

If you are forwarding from NIOS to NIOS with DFP, the original NIOS must have “Add” at least and the DFP NIOS must have “Copy” enabled.

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).

Remember, Threat Defense Endpoint and the DFP on the NIOS-X servers both query the Infoblox Threat Defense cloud using DoT (NOT DoH). However, they make the query over the non-standard port tcp-443. tcp-443 is normally used by DoH and tcp-853 is normally used but DoT. Not in this case. This traffic cannot be decrypted or the session will break.

+ednsopt=65523:0a0a0a0a

This is 10.10.10.10 encoded as 0a0a0a0a

BloxOne accepts custom headers:

• 65522 - Site ID
• 65523 - Source IP
• 65524 - Source MAC address
• 65525 - ? (36adae19 converts to number which converts to 917351961 which converts to 54.173.174.25)
• 65526 - DNS View

Just convert from ASCII to HEX and numbers to HEX (remove the . from IP and : from MAC)

• Source = 10.10.10.10
• DNSView = prod
• MAC = ab:cd:ef:12:34:56
• dig example.com @52.119.40.100 +ednsopt=65523:0a0a0a0a +ednsopt=65526:70726F64 +ednsopt=65524:616263646566313233343536

Example: Option 65523 with value c0a8634e (Hex) converts to 3232260942 (Decimal) which converts to 192.168.99.78.

• Decimal to Hex is here)
• IP to Decimal is here

When forwarding to internal domains, subnet data is not included by DFP unless it is already in the packet when it is sent to DFP. i.e. DFP will copy any existing EDNS0 data when forwarding internally but will not add anything. The status of the GeoLocation setting is irrelevant as it only applied to traffic passing through the Infoblox cloud.

Onprem Policy Cache (OPC) is what is used to block tunneling on DFP.

DNS forwarding proxy can process up to 10,000 concurrent DNS queries. If this limit is exceeded, the client will receive a DNS response with the response code SERVFAIL. (Documentation)

DNS forwarding proxy can serve multiple DNS queries through a single TCP connection sequentially: that is, by handling one DNS query at a time. However, if a client sends multiple queries simultaneously, the DNS forwarding proxy can establish more than one connection. The maximum number of TCP connections is tied to the maximum allowed number of concurrent DNS queries: 10,000.

DNS forwarding proxy can serve multiple DNS queries through a single TCP connection sequentially: that is, by handling one DNS query at a time. However, if a client sends multiple queries simultaneously, the DNS forwarding proxy can establish more than one connection. The maximum number of TCP connections is tied to the maximum allowed number of concurrent DNS queries: 10,000.

NIOS 8.5.4 DFP still connects to CSP as of Jan 2025.

The NIOS DFP process (Docker container) needs to resolve certain FQDN's in order to connect to cloud. The DFP process does not use NIOS configuration to choose which DNS server to use for recursion. That is a specific configuration option for DFP specified under Grid Properties > CSP Config > CSP Resolver. e.g.

• app.noa.infoblox.com
• cp.app.noa.infoblox.com
• csp.infoblox.com

NOTE: Don't set CSP Config (specifically, the Join Token) at a Grid level. That will cause all members of the Grid to join the CSP. Set it at a member level as you will likely only need GM/GMC and DNS servers to connect.

To configure DFP, you must first join the NIOS member to the CSP by adding a join token to Grid Properties > CSP Config > CSP Resolver. If the member cannot access the BloxOne Anycast DNS to resolve BloxOne domains, update the value of CSP Resolver (e.g. to the local DNS resolver if required).

DFP is a separate CoreDNS docker image that is separate to BIND. When enabled, DFP will run on 127.0.0.1:1024 and will add the following two lines to the BIND config. (replacing existing config if those lines already exist (e.g. forwarding to 8.8.8.8)

forward only;
forwarders { 127.0.0.1 port 1024; };

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.

Remember, if the DFP has been configured to forward to a GEO IP, this will also be tested.

During failure, DFP will re-test the Anycast DNS every five seconds. However, it doesn't seem to be consistent in “which” of the four Anycast IP addresses it tests.

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 NIOS Firewall Rules)

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

Client Query > DTC > RPZ > NIOS Conditional Forwarder > DFP Internal Domain Forwarder > Infoblox Cloud

This means that if NIOS has a conditional forwarder to a domain that the CSP has configured as an internal domain, the NIOS configured take priority over whatever Internal Domain forwarding is configured in CSP. This allows for more flexibility in which internal domains get forwarded to where.

When configuring internal domains for DFP in CSP, remember, if applying to NIOS and if NIOS has DNSSEC validation enabled, you must add the internal domains to the negative trust anchor list in the NIOS configuration. interestingly, the DNSKEY/DS queries for internal domain that NIOS appliances receive will be forwarded to the DFP. So local conditional forwarder is ignored for DNSSEC queries (DNSKEY/DS) even with “use forwarders only” on the conditional forwarder.

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.

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.

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.

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).

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.

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

Once the NIOS DFP realises that it can't reach the BloxOne Anycast DNS, it will generate the following RED message in the NIOS GUI:

NIOS/DFP Service has failed. Cloud/DFP is unhealthy.

And the following error in SYSLOG

• Facility = user
• Level = ALERT
• Server = monitor[1145192]
• Message = Type: DFP, State: Red, Event: NIOS/DFP Service has failed. Cloud/DFP is unhealthy. state change from 140 to 141

Once the NIOS DFP starts, it generates log

NIOS/DFP Service is starting. Cloud/DFP is healthy. state changes from 141 to 143

And the following error in SYSLOG

• Facility = user
• Level = ERROR
• Server = monitor[8704]
• Message = Type: DFP, State: Yellow, Event: NIOS/DFP Service is starting. Cloud/DFP is healthy. state changes from 141 to 143

NOTE: There doesn't seem to be a syslog for when the fail-back-to-DFP action takes place

Palo Alto Networks Prisma Access DNS Proxy can be configured to use Infoblox B1TD public IP for external DNS recursion.