Infoblox RPZ Threat Feeds

Official list of Infoblox Threat Feeds

Feed Revamp for NIOS

Test data here.

Some OpenSource feeds here.

ISC Guide to RPZ Deployment.

Official best practice.

Precedence: If you have a security policy at the top of the policy list (i.e. highest precedence), then if there is a DFP or an active Endpoint in that site or a DoH client, they will get processed by that security policy rather than the security policy they are actually aligned to further down the list of policies. The security logs will still have the information generated by Endpoint/DFP (e.g. private IP, endpoint name, etc). If the client is DoH client then you just get the public IP the traffic is coming from. If you have an Endpoint and go to a site of another company who protect their site with “External Network”, you Endpoint traffic will hit your tenant and only be processed by your tenant. The Endpoint/External Network precedence topic only applies if you have both the Endpoint and the External Network in the same tenant.

REMEMBER: ALL RPZ get evaluated BEFORE query is made. IP rules are ignored. IP Rules get evaluated when response is received.

Infoblox Threat Defense will never block *.infoblox.com even if it is explicitly blocked by Security Policy. This is because the domain is trusted and run by Infoblox and is necessary for basic functioning of the service.

When creating a security policy using RPZ feeds, the following is best practice in general.

• Applications being allowed to recurse out locally. (B1TD Cloud only - not NIOS)
• Application Filters - Use them for auditing rather than blocking.
• Custom allow lists. e.g. internal domain list and a SOC override/false positive list, etc. Consider allowing and not logging as the DNS query is logged separately in B1TD and can be configured to be logged separately in NIOS. If some domain access needs to be always permitted and logged, consider putting those in their own allow list.
• Custom block lists. e.g. SOC list of domains to block based on internal Threat Intelligence and list of domains the company prohibits access to.
• Infoblox RPZ feeds that have action set to block.
• Applications to block. (B1TD Cloud only - not NIOS)
• Web Categories to block. (B1TD Cloud only - not NIOS)
• Infoblox RPZ feeds that have action set to allow with log.
• Set RPZ feed to TTL of no more than 600 seconds (5 minutes).

Do not add Web Categories “allow with log” or Application “allow with log” rules unless you really know what you are doing. The data gets logged anyway and populates the Web Category and Application Insight reports anyway without the need for a rule to explicitly log. Also, “Allow - With Log” as an action for web content can impact Threat Insight in the cloud.

Where you have a number of RPZ feeds that are going to perform the same action (block or allow), then put the IP address based feeds at the bottom and FQDN based feeds at the top. Infoblox does not mix FQDN data and IP data in any feed other than the “bundle” feeds for NIOS. The reason for this is two fold. Firstly is can improve performance to do it this way as the FQDN needs to be resolved to get the IP for checking. On a busy appliance, checking and blocking based of FQDN can slightly improve performance. Secondly, blocking based on IP address is 'normally' not a great idea. Since many web threats can be hosted on the same IP as legitimate services it is much more accurate to block on FQDN. By putting IP data below FQDN data, we know that any IP block is hit only because there was no FQDN hit.

For Infoblox, if the RPZ feed name does not have _IP in it, it is a FQDN only feed. Generally, alert on _IP rules rather than block. The Extreme/High/Medium/Low feeds are an exception. They can contain both FQDN and IP data.

If using the -block and -log combination feeds, always put -log underneath the -block feed and only pick a single severity.

Remember, RPZ feeds are for recursive DNS only. They can't be used on a DNS server that is authoritative only. ADP and RRL can be used to protect authoritative servers.

In the list below “Allow” means “permit but do not log”. “Alert” means “permit and log”.

If you enable rebind protection, make sure you add dns.msftncsi.com to a custom allow list (no log) so that you don't fill up the security events with Windows trying to test if it is online (A record is public IPv4 but AAAA record is private IPv6).

As of NIOS 9.0.1 in Dec 2023: (Documentation) As of NIOS 9.0.7 in Oct 2025 - new column added. Note, running Threat Feeds AND Threat Insight is not supported on TE-1415 and TE-1425.

Official best practice.

The following table shows an aggressive block policy in best practice order based on feed confidence followed by severity.

Default Allow should be above “custom” allow lists in order to avoid the Infoblox Threat Defense putting a warning label on the security policy.

NOTE: For on-prem NIOS security policies, follow something similar to the above. Threat Insight on NIOS will need its own feed below the custom block list near the top.

NOTE: for US_OFAC_Sanctions_IP, “MED” covers everything in “High” and “Embargoed”. “High” covers everything in “Embargoed”. So pick only one for efficiency/avoid pointlessly duplicating data.

• After changing the TSIG key in NIOS, NIOS doesn't tell you that a DNS service restart is required. However, you do need to restart or the AUTH will fail.
• Neither FastFlux not DNS Messenger have been seen in wild for years.
• Remember, smaller threat databases are not necessarily worse. If a threat has not been seen in the wild for over 5 years, why keep the entry in the database?
• Remember, when a FQDN is matched to an allow rule, Infoblox doesn't check the returned IP. Thus, avoid 'allow' rules if possible. The main use for allow rules are the 'allow corporate domains' at the top as well as an override rule.
• Keep in mind that all DNS requests going through the Infoblox cloud get logged under DNS. So there is still a log. Thus, you should only log actions in security policy if you actually need a log for security. e.g. Consider carefully before logging the custom allow list at the top of the security policy. Do you really need “Security” alerts for it? They will be logged under “DNS” regardless.
• The logic of the “custom-allow” list is that “These domains must always resolve regardless of security threat. The logic of the “custom-block” list is that “These domains must never resolve regardless of security threat.
• A thought on the bogon list. Large organizations should be blocking access to these IP ranges at their border routers. Note that there are some (rare) applications that use bogons in DNS responses for legitimate uses. Some customers have found they needed to add amazonaws.com because some of their responses to sub-domains contained CGNAT IP's that were needed but would have been blocked by Bogon feed.
• The “Allow - Local Resolution” action for “Application Filter” in security policy in cloud works on both NIOS-X DFP, Infoblox Endpoint and NIOS DFP. However, for NIOS DFP you must configure the DNS on that NIOS appliance to “Use forwarders only” and specify a target (e.g. 1.1.1.1). NIOS cannot use root hints to resolve “Local Resolution” requests. NIOS-X DFP can only honour the “Allow - Local Resolution” action if Universal DDI is also licensed (i.e. it isn't a pure Threat Defense install). This is because without Universal DDI, the DFP on NIOS-X is very simple and can only forward to cloud or local DNS if it is an internal domain.
• Keep in mind, if there is an overlap between customer's block list and Infoblox RPZ, does the customer want to see their feed listed in the security log or Infoblox's? That will determine where in the list they should place their custom block list.
• If NIOS forwards to Infoblox Threat Defense Anycast IP over plain text and has “copy source IP” enabled, it will include internal source IP. However, be aware that this will permit ISP to see private IP if they do deep packet inspection on DNS traffic.

REMEMBER! When creating local RPZ feeds, example.local is NOT equal to *.example.local.

When setting a “policy override” at an RPZ level, we are telling NIOS to ignore the individual actions set within the RPZ and apply the same action for any match in the RPZ

• None (Given) - This means do not apply a policy wide override. Allow the individual rules in the policy to dictate what they are doing. Mainly use this on custom feeds.
• Log Only (Disable) - Log in syslog that the RPZ would have been match but don't actually match. Keep moving down the list of RPZ feeds and look for another match (there may or may not be one).
• Passthru - Override any action and just match the rule but permit the traffic without modification.
• Block (No Such Domain) - Override any action and just match the rule but block the traffic with NXDOMAIN.
• Block (No Data) - Override any action and just match the rule but permit the block the traffic.
• Substitute (Domain Name) - Override any action and just match the rule but block the traffic by responding with a substitute domain.

Summary of how different Newly Observed Domain feeds work:

• SURBL – 3 days, newly registered (data from DNS registries)
• Farsight – 3 days, first query seen in their pDNS
• Infoblox – 7 days, first seen active in multiple sources
• PaloAlto – 32 days, first seen in multiple sources
• Cisco – 1 day, 2nd query seen in sampled OpenDNS traffic

So, where possible, combine SURBL Fresh, Farsight NOD, Infoblox NOED and Infoblox Suspicious NOED.

Data configured under Policies > On-Prem DNS Firewall.

• For each Grid:
  • Version of NIOS
  • Appliance count, model, form factor and licences
  • Grid wide licences
• What name server groups exist already?
• Use lead secondary? (Other NIOS devices will use Zone Transfers to get data from lead secondary)
• NTP already configured and device synced?
• Block threats on the appliances/forward to BloxOne cloud or both?
• If forwarding to BloxOne cloud, apply URL filtering and/or application filtering?
• What threat feeds should be used? Block or Log?
• Send notifications to secondary servers?
• Full list of internal domains? We need to add them to the whitelist.

• Configure Distribution Server. TSIG keys can take an hour to create.
• US West: 54.69.93.185
• US East: 52.2.30.79
• TSIG Algorithm
• Name:
• Key:

• For local RPZ zones, always make the name end with a .rpz to be nice to the admins in the future.
• NIOS will only ever download from the External Primary. NOT the External Secondary. Don't bother marking anything as External Secondary when creating a NIOS RPZ. If you have two external servers as External Primary then if one is not reachable, NIOS can get data from the other.
• If using “Lead secondary”, DNS secondary servers will need port tcp-53 access to the lead secondary. (i.e. it isn't Grid replicated data)
• For custom allow and block RPZ lists, remember the google.com is not the same as *.google.com.
• What Public IP addresses will be used? What public IP addresses will we use for receiving notifications of updates?
• You can have local RPZ as well as forward to Infoblox Threat Defense (e.g. for URL logging)
• Outbound is tcp/udp on 53 to the two IP addresses above.

In theory an attacker might use a CDN (e.g. *.azureedge.net) for C2 and all Web Proxy categorizations will be “content server” (or something similar).

• Exfiltration will be detected (would we detect and block subdomains of a CDN if tunneling is detected?)
• If the domain the CDN CNAME points to is bad it is still a candidate for suspicious/malware feeds which would block the resolution of the CNAME in the CDN domain.
• Infoblox will block hostnames that they know are bad or suspicious, and that aren't shared hosting with other sites. For example, a number of threat intel providers in 2022 repeatedly blocked Cloudflare FQDNs that were in CNAMEs. This is bad because the Cloudflare endpoints are shared and just because they contain phishing doesn't mean they should be blocked; Escalations have happened from customers who were blocked from their own website or a critical service because of a 3rd party intel (Not-Infoblox intel) that includes the Cloudflare endpoint.

If you have internal NIOS appliances forwarding to a DMZ NIOS appliance caching server, and if the caching server is doing the RPZ feeds, you will find that it will not work by default. This is because, by default, the first NIOS box to receive the query till tell the box it forwards to to not do RPZ. When configuring an internal DNS forwarder to point at a DMZ Infoblox RPZ server, you must go (in the Grid manager) to Data Management > DNS > Member > Edit > General > Advanced and then untick “Apply RPZ rules only on this member if possible”

Officially: Select this check box if the forwarders must not apply RPZ rules to the responses that is returned to the other member, when this RPZ member queries other Grid member details”.

Custom list is good for shorter lists of data such as “always allow” (e.g. domains you own) and “always block” (e.g. domains you prohibit). You can add descriptions to each line (can't do that with RPZ) and you can also set the level (low-high) and confidence (low-high) (can't do that with custom RPZ). Also, the data will remain in the custom list forever.

Custom RPZ feeds are meant more for working with TIDE data, combining TIDE data with your own uploads. The data should always have expiry dates on it which is why custom lists can be better for stuff that never changes (e.g. domains you always allow). You can easily merge things like country IP data, etc.

Another nice thing about custom RPZ feeds is that you can pull the data easily to other tool. e.g. dig with correct commands to do a zone transfer. Put that through a small shell script to filter the data into host file format and you can put it on a PiHole.

You can block (or allow) traffic based on answer IP by using Custom list. This can be done for a single IP by adding x.x.x.x/32. If you don't add /32, it will be added automatically when you save the Custom list. You can also add subnets such as y.y.y.y/24.

Be aware that 52.119.40.100 is the CSP resolver address used for DNS Forward Proxy.

NIOS 8.6 connects to grpc.csp.infoblox.com without any config being applied.

May 2023 > Oct 2023

• Suspicious = 65% > 74%
• NOED = 30% > 12%
• Other = 5% > 14%

From here In previous NIOS releases, RPZ query name recursion was enabled by default. The DNS recursive name server performed RPZ recursive lookups for the fully qualified domain name that was part of an RPZ. Starting with NIOS 7.1.0, RPZ query name recursion is disabled by default. When RPZ query name recursion is disabled, the DNS recursive name server sends responses for the domains being queried, without forwarding queries to the authoritative name servers. This can speed up recursive RPZ lookups by eliminating unnecessary recursions for domains that are known to be malicious, possibly caused by internal DDoS attacks on the recursive server. You can enable RPZ query name recursion by selecting the Enable RPZ query name recursion (qname-wait-recurse) check box. When you select this check box, the appliance performs RPZ query name recursions. You can configure this at the Grid, member, and DNS view levels.

To get the size of RPZ feed from Infoblox (or any RPZ feed or zone transfer). Allow for a few extra lines when using this method as it doesn't strip lines from start and finish that are not data.

dig @52.2.30.79 axfr -y hmac-sha256:<keyname>:<tsigkey> infoblox-base.rpz.infoblox.local | wc -l

In August 2021, just under 2 million records in total. In January 2025, just under 38 million records in total.

• SURBL = “Spam Uniform Resource Identifier (URI) Real-time Block List (BRI)”
• EXT = Extended. This is for feeds that take the “normal” feed and extends the TTL so the data is available for longer. This may mean the data is less accurate.
• NCCIC = National Cybersecurity & Communications Integration Center
• DHC AIS = Department of Homeland Automated Indicator Sharing - AISCOMM
• OFAC = US Treasury Office of Foreign Assets Control
• LITE = Smaller version of the main RPZ so that smaller appliances can load it.
• EECN = Eastern Europe (non-EU) and China.
• ETIQ = Proofpoint.

Cloud Only Feeds for Threat Insight.

For the following reasons, the following feeds have been removed

• Data consolidated from multiple feeds into one (e.g. the cleanup in Dec 2024).
• IP addresses are frequently reused for multiple sites, and blocking the ones associated with such systems ran the high risk of inadvertent blocking (I.E. False Positive).
• The curation process for these feeds (I.E. removing false positives) frequently left these feeds empty.

• Spambot IPs (Deprecated on 1 April 2023)
• Bot_IP (Deprecated on 1 April 2023)
• ExploitKit_IP (Deprecated on 27 July 2023)
• Ext_ExploitKit_IP (Deprecated on 27 July 2023)
• Ext_TOR_Exit_Node_IP (Deprecated on 27 July 2023)
• NCCIC_Host (Deprecated on 27 July 2023)
• NCCIC_IP (Deprecated on 27 July 2023)
• SURBL_Fresh (Deprecated on 22 August 2023)
• SURBL_Multi (Deprecated on 22 August 2023)
• SURBL_Multi_Lite (Deprecated on 22 August 2023)
• Base (Deprecated on 31st Dec 2024)
• AntiMalware (Deprecated on 31st Dec 2024)
• Ransomware (Deprecated on 31st Dec 2024)
• AntiMalware_IP (Deprecated on 31st Dec 2024)
• Malware_DGA (Deprecated on 31st Dec 2024)
• NOED (Deprecated on 31st Dec 2024)
• Suspicious_Domains (Deprecated on 31st Dec 2024)
• Suspicious_Emergent_Domains (Deprecated on 31st Dec 2024)
• Suspicious_Lookalikes (Deprecated on 31st Dec 2024)
• Ext_Base_AntiMalware (Deprecated on 31st Dec 2024)
• Ext_AntiMalware_IP (Deprecated on 31st Dec 2024)
• Ext_Ransomware (Deprecated on 31st Dec 2024)
• Spambot_DNSBL_IP (Deprecated on 31st Dec 2024)
• Extream_Block (Deprecated on 31st Dec 2024. Was a combination feed)
• Extream_Log (Deprecated on 31st Dec 2024. Was a combination feed)
• High_Block (Deprecated on 31st Dec 2024. Was a combination feed)
• High_Log (Deprecated on 31st Dec 2024. Was a combination feed)
• Med_Block (Deprecated on 31st Dec 2024. Was a combination feed)
• Med_Log (Deprecated on 31st Dec 2024. Was a combination feed)
• Low_Block (Deprecated on 31st Dec 2024. Was a combination feed)
• Low_Log (Deprecated on 31st Dec 2024. Was a combination feed)

While they are now deprecated as part of the general threat feed clean up ion 31st Dec 2024, there used to be “Combination Feeds”. An official guide is here.

These feeds are accessible for NIOS only (not for CSP Security Policy). The reason is because prior to NIOS 9.0, the version of BIND used on NIOS was limited to 32 RPZ feeds. This meant that users could not import all the available feeds and also use custom feeds. To get around this, a group of feeds were developed that would allow users to aggregate several feeds into one and uses can choose which feed based on their approach to risk. Version 9.0 of NIOS allows up to 64 RPZ feeds and the CSP never had this limitation.

Note that there is no overlap between what ends up in a level's “block” category and what ends up in the “log” category. Thus, the average business should pick a level (e.g. medium) and then block “Medium_Block” and allow but log “Medium_Log”.

• Extreme - Not suitable for most users.
• High - For environments where it is more important to block potential malicious behavior than it is to avoid blocking the occasional non-malicious site.
• Medium - For most organizations.
• Low - For organizations that are more concerned about accidental blocks than allowing the occasional threat. Examples: Service Providers, Universities, Public WiFi Access Points.

• Block - Contains entries that should be blocked with confidence given the level of protection needed (e.g. low protection for public wifi and extreme protection for the military)
• Log - Goes along with the aligned Block list but contains entries that don't have as high a confidence level.

Disable NSDNAME/NSIP processing to prevent major performance impacts (approx. 45%). This feature can also cause massive outage if a legitimate NS server gets onto your block list.

RPZ NSDNAME (Name Server Domain Name)

• Definition: This trigger matches the domain name of the authoritative name server (found in the NS records) during recursive resolution.
• Use Case: If a malicious actor uses ns1.badactor.com to host 5,000 phishing websites, you can create an RPZ rule targeting ns1.badactor.com.rpz-nsdname. Any domain utilizing that name server will be blocked.
• Key Advantage: It catches new malicious domains immediately, even if they aren't listed in a reputation feed yet, as long as they use the same compromised name server.

RPZ NSIP (Name Server IP Address)

• Definition: This trigger matches the actual IP address (IPv4 or IPv6) in the A/AAAA records of name servers associated with domains (glue records).
• Use Case: If a malicious server changes its name (e.g., from ns1.badactor.com to ns1.sneaky.com) but keeps the same IP address (e.g., 192.0.2.55), NSDNAME might fail, but NSIP will still block it.
• Functionality: It protects against attackers who try to evade NSDNAME filters by changing name server names.

In NIOS, you get the following syslog on the member doing the RPZ feed

• Facility = daemon
• Level = INFO
• Server = named

Under Data Management > DNS > Response Policy Zones you can check “Last Updated” column to see if the RPZ has been downloaded.

You can filter with “Message contains X” where X is the name (or part of the name) of the RPZ feed.

To look for all successful transfers, filter on “Message contains Transfer completed”.

The following is an example syslog output when adding ib-extreme-block.rpz.infoblox.local

zone ib-extreme-block.rpz.infoblox.local/IN: Transfer started.
transfer of 'ib-extreme-block.rpz.infoblox.local/IN' from 52.2.30.79#53: connected using 10.1.1.53#37963 TSIG portal.208.mydomain-infoblox-zrm6ts0f
transfer of 'ib-extreme-block.rpz.infoblox.local/IN' from 52.2.30.79#53: failed while receiving responses: end of file
transfer of 'ib-extreme-block.rpz.infoblox.local/IN' from 52.2.30.79#53: Transfer status: end of file
transfer of 'ib-extreme-block.rpz.infoblox.local/IN' from 52.2.30.79#53: Transfer completed: 6056 messages, 1861125 records, 45218200 bytes, 32.973 secs (1371370 bytes/sec)
rpz: ib-extreme-block.rpz.infoblox.local: reload start
rpz: ib-extreme-block.rpz.infoblox.local: using hashtable size 19
zone ib-extreme-block.rpz.infoblox.local/IN: Transfer started.
transfer of 'ib-extreme-block.rpz.infoblox.local/IN' from 52.2.30.79#53: connected using 10.1.1.53#36777 TSIG portal.208.mydomain-infoblox-zrm6ts0f
zone ib-extreme-block.rpz.infoblox.local/IN: transferred serial 1671105914: TSIG 'portal.208.mydomain-infoblox-zrm6ts0f'
transfer of 'ib-extreme-block.rpz.infoblox.local/IN' from 52.2.30.79#53: Transfer status: success
transfer of 'ib-extreme-block.rpz.infoblox.local/IN' from 52.2.30.79#53: Transfer completed: 6057 messages, 1861306 records, 45223143 bytes, 17.607 secs (2568475 bytes/sec)
(re)loaded policy zone 'ib-extreme-block.rpz.infoblox.local', now with 1855281 qname, 0 nsdname, 5744 IP, 0 NSIP, 0 CLIENTIP entries
rpz: ib-extreme-block.rpz.infoblox.local: new zone version came too soon, deferring update for 60 seconds
rpz: ib-extreme-block.rpz.infoblox.local: reload done
rpz: ib-extreme-block.rpz.infoblox.local: reload start
rpz: ib-extreme-block.rpz.infoblox.local: using hashtable size 19
(re)loaded policy zone 'ib-extreme-block.rpz.infoblox.local', now with 1855559 qname, 0 nsdname, 5744 IP, 0 NSIP, 0 CLIENTIP entries
rpz: ib-extreme-block.rpz.infoblox.local: reload done

Log “Level” = INFO

Facility = “local4”

• CEF:0
• Infoblox
• NIOS
• 9.0.0-48842-de455822b346
• RPZ-QNAME
• PASSTHRU
• 4
  • app=DNS
  • dst=192.168.53.53
  • src=192.168.1.1
  • spt=60476
  • view=_default
  • qtype=A
  • msg=“rpz QNAME PASSTHRU rewrite baddomain.example.corp [A] via baddomain.example.corp.stafford-allow.rpz”
  • CAT=RPZ

• CEF:0
• Infoblox
• NIOS
• 9.0.0-48842-de455822b346
• RPZ-QNAME
• PASSTHRU
• 4
  • app=DNS
  • dst=192.168.53.53
  • src=192.168.1.1
  • spt=52904
  • view=_default
  • qtype=A
  • msg=“disabled rpz QNAME PASSTHRU rewrit baddomain.example.corp [A] via baddomain.example.corp.stafford-allow.rpz”
  • CAT=RPZ

(this one is blocking based on an IP block list)

• CEF:0
• Infoblox
• NIOS
• 9.0.0-48842-de455822b346
• RPZ-IP
• NXDOMAIN
• 7
  • app=DNS
  • dst=192.168.53.53
  • src=192.168.1.1
  • spt=52904
  • view=_default
  • qtype=A
  • msg=“rpz IP NXDOMAIN rewrite baddomain.example.corp [A] via 32.4.3.2.1.rpz-ip.stafford-block-manual.rpz”
  • CAT=RPZ

Redirecting *.slashdot.org to time1.google.com

• CEF:0|
• Infoblox|
• NIOS|
• 9.0.6-53318-82020f7ffaad|
• RPZ-QNAME|
• Local-Data|
• 7|
  • app=DNS
  • dst=192.168.1.53
  • src=192.168.1.2
  • spt=56910
  • view=_default
  • qtype=A
  • msg=“rpz QNAME Local-Data rewrite www.slashdot.org [A] via www.slashdot.org.forward-control”
  • CAT=RPZ

The reporting sever generates additional log. In this example, the RPZ is called “forward-control” and www.slashdot.org is substituted for time1.google.com

• TIMESTAMP=2025-05-28 12:39:26,
• VIEW=_default,
• CLIENT=192.168.1.2,
• RPZ_SEVERITY=7,
• DOMAIN_NAME=www.slashdot.org,
• RPZ_QNAME=www.slashdot.org.forward-control,
• MITIGATION_ACTION=A1,
• REDIRECTION_RECORD=N/A,
• CAT=RPZ:forward-control,
• GST=0,
• LID=N/A

A note on RPZ Severity

• Informational = 4
• Warning = 6
• Major = 7
• Critical = 8

Official SYSLOG Severity levels

• 0 (Emergency): System unusable, kernel panic.
• 1 (Alert): Action must be taken immediately (e.g., primary ISP loss).
• 2 (Critical): Critical conditions (e.g., failing hardware, primary application failure).
• 3 (Error): Error conditions, non-urgent failures.
• 4 (Warning): Potential errors if no action is taken (e.g., low disk space).
• 5 (Notice): Unusual but not error conditions, ongoing events.
• 6 (Informational): Normal operational messages (e.g., application start/stop).
• 7 (Debug): Detailed information for developers

A note on Mitigation Action

• A1 = Substitute (Domain) and Substitute Record
• PT = Passthru
• NX = No Such DOMAIN_NAME
• ND = No Domain

• Facility: daemon
• Level: INFO
• Server: named

• zone ransomware.rpz.infoblox.local/IN: sending notifies (serial 1684944367)
• zone ransomware.rpz.infoblox.local/IN: Transfer started.
• transfer of 'ransomware.rpz.infoblox.local/IN' from 54.69.93.185#53: connected using 192.168.11.153#52143 TSIG portal.2000512.infoblox.site-infoblox-lfkcpgqd
• zone ransomware.rpz.infoblox.local/IN: transferred serial 1684952096: TSIG 'portal.2000512.infoblox.site-infoblox-lfkcpgqd'
• transfer of 'ransomware.rpz.infoblox.local/IN' from 54.69.93.185#53: Transfer status: success
• transfer of 'ransomware.rpz.infoblox.local/IN' from 54.69.93.185#53: Transfer completed: 1 messages, 6 records, 426 bytes, 0.160 secs (2662 bytes/sec) (serial 1684952096)
• rpz: ransomware.rpz.infoblox.local: reload start
• (re)loaded policy zone 'ransomware.rpz.infoblox.local', now with 438513 qname, 0 nsdname, 0 IP, 0 NSIP, 0 CLIENTIP entries
• rpz: ransomware.rpz.infoblox.local: reload done
• zone ransomware.rpz.infoblox.local/IN: sending notifies (serial 1684952096)

When a new copy of the RPZ is downloaded (transferred)

• rpz: bogon.rpz.infoblox.local: reload start
• (re)loaded policy zone 'bogon.rpz.infoblox.local', now with 1 qname, 0 nsdname, 16 IP, 0 NSIP, 0 CLIENTIP entries
• rpz: bogon.rpz.infoblox.local: reload done

You can force a new download with

set dns transfer <zone> [view]

set dns transfer public-doh.rpz.infoblox.local zulu