Official list

Test data here.

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

As of NIOS 9.0.1 in Dec 2023: (Documentation)

OLD data

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.

• 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.
• FastFlux not seen in wild for years.
• DNS Messenger not 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, we don't check the returned IP. Thus, avoid 'allow' rules if possible. (the main use being the 'allow corporate domains' at the top as well as an override rule).
• If you are going to add Ext_ feeds in a high risk environment, make sure to add the originals just above them. This way, if the Ext_ feeds gets hit, you know for sure that the data was in the “extended so not necessarily still a threat” part of its lifecycle.
• Security policy rules should be ordered to give most specific reason why content was blocked. In general, choose your level of protection requirement - high, medium or low.
• Keep in mind that all DNS requests going through the BloxOne 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. 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.
• Block bogon. 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.
• The “Allow - Local Resolution” works on both B1 Hosts, 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. B1TD hosts can if B1DDI is installed as well. If B1DDI is not installed, root hints resolution isn't available anyway.
• Keep in mind, if there is a duplication between customers 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. When in doubt, put Infoblox first during POC and customer first in production. During POC it obviously helps to show that Infoblox identified the bad domain.
• If NIOS forwards to B1TD anycast IP 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.

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

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

Summary of how different 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.

• 20,000 records in an RPZ file (IP ranges only) can equate to a 20Mb CSV file when exported.
• 115,000 records in an RPZ file can equate to 6Mb CSV file when exported.
• 407,000 records in an RPZ file can equate to 21Mb CSV file when exported.

So a RPZ feed with 2.8 Million records could equate to about 150Mb for a CSV file.

If you are creating a combination RPZ, the three to avoid (as they will max out the limit) are

• Policy_NewlyObservedDomains
• Suspicious_EmergentDomain
• Suspicious_Generic

20K employees running on 2 or 4 TE-1415 appliances will all RPZ feeds from B1TD Advanced and with Threat Insight.

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 every download from the External Primary. NOT the External Secondary.

If using DFP on NIOS, enable “Fallback to default resolution if TD does not respond”

Log only (disabled) means it is disabled and the query falls through to the next rule.

If using “Lead secondary”, DNS secondary servers will need port tcp-53 access to the lead secondary.

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 BloxOne (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 other intel providers over the past year have repeatedly blocked Cloudflare endpoints that are in CNAMEs. This might seem cool, but indeed it is a bad idea. The Cloudflare endpoints are shared and 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.

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.

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

This is from August 2021. Just under 2 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.

These are called “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 extream protection for the military)
• Log - Goes along with the aligned Block list but contains entries that don't have as high a confidence level.

For the following reasons, the following feeds have been removed

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