{"id":7734,"date":"2022-05-16T12:20:21","date_gmt":"2022-05-16T19:20:21","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=7734"},"modified":"2022-05-16T13:30:57","modified_gmt":"2022-05-16T20:30:57","slug":"using-custom-rpzs-to-block-abusive-top-level-domains","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/","title":{"rendered":"Using Custom RPZs to Block Abusive Top Level Domains"},"content":{"rendered":"

Avoid driving expensive vehicles through bad neighborhoods<\/b>\u00a0<\/span><\/h3>\n

If you work in network defense or security operations and haven\u2019t looked at custom Response Policy Zones in a while (or ever!) you\u2019re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge,\u00a0 it\u2019s understandable that configuring rules for DNS resolution gets missed. For simplicity, this function resides in \u201cthe middle\u201dof our pantheon \u2013 the core network control layer not defined under \u201cedge defense\u201d and not within the purview of \u201cendpoint security\u201d. Often, I hear that rule management is someone else\u2019s dark art, or overly complicated, or that DNS was \u201ctaken care of years ago\u201d so not a high priority to look at. Sometimes it\u2019s been a case of threat researchers and network or security operations just not getting together (teams are busy!). But you\u2019d be surprised how little custom RPZs are used for enforcement across industries and sectors. If you knew that certain harmful sections of the Internet could be safely turned off for your organization, with high reliability, efficacy, and minimal disruption to the operations, wouldn\u2019t you examine this? For customers who use them effectively, custom RPZs serve to integrate threat location data across vendors, solutions and data sources, and offer a single point of universal enforcement. And that function is carried out by your own DNS Resolver \u2013 something that will be part of your network operations well into the next decade. Today, we are focused on one aspect of custom RPZs, which is the capability to take action on abusive top level domains.<\/span>\u00a0<\/span><\/p>\n

Defining the problem<\/b>\u00a0<\/span><\/h3>\n

First let\u2019s examine why people put policy rules in place to begin with. This is essentially to automate and repeat the functions of \u201cdon\u2019t do that, don\u2019t go there, don\u2019t allow that through\u201d. That logic naturally creeps into \u201cgo there, but only you and only between 3pm and 5pm\u201d and before long, a network firewall becomes a byzantine stack of potential conflicting rules in service of multiple masters. What\u2019s worse is if that segmented firewall function doesn\u2019t cover your entire sphere of responsibility and is taken down occasionally for maintenance. Your rule sets, however pristine, become useless if they don\u2019t interface with the traffic you are responsible for inspecting and securing 24x7x365. The ideal scenario here has been described to me as \u201cI set a rule once, it performs to precise expectation 100% of the time for 100% of my intended constituency and I rarely need to take another look at it\u2026.and oh, one more requirement \u2013 no angry phone calls complaining that I disrupted business operations\u201d. Additionally, since vendors, analysts, and peers are always finding new bad places, we need capacity to both distribute the data where it needs to be and to house it within the blocking mechanism we are using. Whew! Anything else I missed?<\/span>\u00a0<\/span><\/p>\n

So, we need a mechanism whereby effective rules can be applied to specific devices, specific network segments, or to entire networks at scale. This mechanism should also allow one to action specific FQDNs \u2013 those abusive subdomains mapped to legitimate base domains \u2013 or to entire zones for efficiency and accuracy. A DNS resolver with RPZs meets the need here. it\u2019s a critical network protocol, seemingly everything assigned an IP address starts making DNS queries to some place. DNS resolution is hierarchical \u2013 root TLD, second level domain, subdomain and so on. There\u2019s no fundamental redesign of anything required. This logic can be very similar to \u201cclose port 3389 on unnecessary devices facing the Internet\u201d or \u201cexamine SSH traffic NOT on port 22\u201d \u2013 rules that thousands of security practitioners apply today.<\/span>\u00a0<\/span><\/p>\n

Persistently bad neighborhoods: Abusive TLDs have been present for years<\/b>\u00a0<\/span><\/h3>\n

In some of the recent newsworthy attacks, researchers and arm-chair quarterbacks alike identified abusive domains used in the attacks as residing in root zone registries with questionable long term reputations. To introduce the problem fully, in the past ten years the TLD space has grown exponentially. Becoming a registrar does require proof of\u00a0 $70,000 in working capital and completion of an ICANN application \u2013 not a total free for all. However, supply created its own demand in many respects and there have been several in-depth studies on the use and abuse of the newest generic TLDs. In the IANA system there are now 1,541 top level domains, all of which your DNS resolver will dutifully go query with or without some controls in place. A growing number of these TLDs are 90% abusive. That is to say, at least 90% of the total population of second level domains contained therein have been proven harmful to legitimate networks. Why do these reprobate registries and registrars continue to operate in this fashion? Don\u2019t overthink the economics \u2013 the short answer is that they have zero incentive to work on this problem.<\/span><\/p>\n

Much research has already been done by experts in the community. These links below are just a few that show commonly abused TLDs which most if not all of YOUR network has no business interacting with. We greatly thank these researchers and partners for their contributions!<\/span><\/p>\n

https:\/\/security-soup.net\/good-domains-for-bad-guys-the-riskiest-tlds-for-malware-and-phishing\/#respond<\/span><\/a><\/p>\n

http:\/\/www.surbl.org\/tld<\/span><\/a><\/p>\n

https:\/\/www.spamhaus.org\/statistics\/tlds\/<\/span><\/a><\/p>\n

https:\/\/www.farsightsecurity.com\/assets\/media\/download\/VB2018-study.pdf<\/span><\/a><\/p>\n

https:\/\/docs.apwg.org\/reports\/apwg_trends_report_q4_2021.pdf<\/span><\/a><\/p>\n

Action Plan: Easy Prevention<\/b><\/h3>\n

A useful exercise is to take some of the newest and most exotic TLDs and simply examine a sample of your own DNS query\/response data to see how your devices, users, and applications are interacting with these. You simply set the response rule to allow+log. This can be thought of as conducting a \u201cTLD heat-mapping assessment\u201d if you need an official-sounding name for the initiative. Those of you using Splunk or Infoblox Reporting servers could run reports to parse out deduplicated counts of 24 hours of query data in order to build a pie chart of the TLDs your network is talking to. By pure volume, .com and .net will remain the kingpins on which TLD suffers the most abuse. Nobody is suggesting blocking those for an instant. Where we want to apply our energy is on those TLDs which, as a percentage of their total population of second level domains, serve abusive destinations. Apply the law of large numbers!<\/span>\u00a0<\/span><\/p>\n

https:\/\/data.iana.org\/TLD\/tlds-alpha-by-domain.txt<\/span><\/a><\/p>\n

is the seminal resource for to see all available standardized TLDs. Now there are some emerging variants for cryptocurrencies and the like \u2013 that is a whole other topic. The point of the thought exercise is to ask \u201cwhat systems and users I am responsible for securing can function perfectly fine without talking to these strange and highly abused corners of the Internet at all?\u201d This can be accomplished by setting a simple Response Policy Zone rule that defines the questionable TLDs. You can also run the following TIDE queries within BloxOne Threat Defense Advanced and then search within the results for the top ten problematic TLDs.<\/span><\/p>\n

\/tide\/api\/data\/threats\/state?type=host&&threat_level_from=80&field=detected,host,domain,tld,property,threat_level<\/span><\/p>\n

\/tide\/api\/data\/threats\/state?type=host&threat_level_from=80&profile=SURBL&field=detected,host,domain,tld,property,threat_level,profile<\/span><\/p>\n

In the one in a million chance that blocking on an abusive TLD causes a false positive for that rare legit record, you can add that unique record to a higher order RPZ list and resolve the matter in less than 5 minutes. Crisis averted!<\/span>\u00a0\u00a0\u00a0<\/span><\/p>\n

Back to that expensive vehicle where multiple drivers have access to the keys, and can instantly drive it all over town via DNS resolution. Instead of asking \u201cwhy were you in this bad neighborhood to begin with?\u201d you can put some realistic and appropriate DNS controls in place, focus on the asset or application that was trying to get to that bad place and work the issue proactively. Quiet down the alerts that are caused by interacting with likely hotbeds of abuse.\u00a0 And no angry phone calls.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

Avoid driving expensive vehicles through bad neighborhoods\u00a0 If you work in network defense or security operations and haven\u2019t looked at custom Response Policy Zones in a while (or ever!) you\u2019re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge,\u00a0 it\u2019s understandable that configuring rules for […]<\/p>\n","protected":false},"author":179,"featured_media":4043,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[2],"tags":[188,30,697,698,223,699],"class_list":{"0":"post-7734","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-security","8":"tag-response-policy-zones-rpz","9":"tag-dns","10":"tag-threat-location-data","11":"tag-dns-resolver","12":"tag-tld","13":"tag-fqdn","14":"entry"},"acf":[],"yoast_head":"\nUsing Custom RPZs to Block Abusive Top Level Domains<\/title>\n<meta name=\"description\" content=\"Using Custom RPZs to Block Abusive Top Level Domains. If you work in network defense or security operations and haven\u2019t looked at custom Response Policy Zones in a while (or ever!) you\u2019re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge, it\u2019s understandable that configuring rules for DNS resolution gets missed. For simplicity, this function resides in \u201cthe middle\u201dof our pantheon \u2013 the core network control layer not defined under \u201cedge defense\u201d and not within the purview of \u201cendpoint security\u201d.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Using Custom RPZs to Block Abusive Top Level Domains\" \/>\n<meta property=\"og:description\" content=\"Using Custom RPZs to Block Abusive Top Level Domains. If you work in network defense or security operations and haven\u2019t looked at custom Response Policy Zones in a while (or ever!) you\u2019re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge, it\u2019s understandable that configuring rules for DNS resolution gets missed. For simplicity, this function resides in \u201cthe middle\u201dof our pantheon \u2013 the core network control layer not defined under \u201cedge defense\u201d and not within the purview of \u201cendpoint security\u201d.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/\" \/>\n<meta property=\"og:site_name\" content=\"Infoblox Blog\" \/>\n<meta property=\"article:published_time\" content=\"2022-05-16T19:20:21+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-05-16T20:30:57+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/banner-Cybersecurity.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1471\" \/>\n\t<meta property=\"og:image:height\" content=\"434\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Chris Richardson\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Chris Richardson\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/\"},\"author\":{\"name\":\"Chris Richardson\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/person\\\/b8f3f1cabebf56f93d704a790f2eddf3\"},\"headline\":\"Using Custom RPZs to Block Abusive Top Level Domains\",\"datePublished\":\"2022-05-16T19:20:21+00:00\",\"dateModified\":\"2022-05-16T20:30:57+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/\"},\"wordCount\":1353,\"publisher\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/banner-Cybersecurity.jpg\",\"keywords\":[\"Response Policy Zones (RPZ)\",\"DNS\",\"threat location data\",\"DNS Resolver\",\"TLD\",\"FQDN\"],\"articleSection\":[\"Security\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/\",\"name\":\"Using Custom RPZs to Block Abusive Top Level Domains\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/banner-Cybersecurity.jpg\",\"datePublished\":\"2022-05-16T19:20:21+00:00\",\"dateModified\":\"2022-05-16T20:30:57+00:00\",\"description\":\"Using Custom RPZs to Block Abusive Top Level Domains. If you work in network defense or security operations and haven\u2019t looked at custom Response Policy Zones in a while (or ever!) you\u2019re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge, it\u2019s understandable that configuring rules for DNS resolution gets missed. For simplicity, this function resides in \u201cthe middle\u201dof our pantheon \u2013 the core network control layer not defined under \u201cedge defense\u201d and not within the purview of \u201cendpoint security\u201d.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/banner-Cybersecurity.jpg\",\"contentUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/banner-Cybersecurity.jpg\",\"width\":1471,\"height\":434},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/security\\\/using-custom-rpzs-to-block-abusive-top-level-domains\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Security\",\"item\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/category\\\/security\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Using Custom RPZs to Block Abusive Top Level Domains\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/\",\"name\":\"infoblox.com\\\/blog\\\/\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#organization\",\"name\":\"Infoblox\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/infoblox-logo-2.svg\",\"contentUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/infoblox-logo-2.svg\",\"width\":137,\"height\":30,\"caption\":\"Infoblox\"},\"image\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/person\\\/b8f3f1cabebf56f93d704a790f2eddf3\",\"name\":\"Chris Richardson\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/live-infoblox-blog.pantheonsite.io\\\/wp-content\\\/uploads\\\/avatar_user_179_1571767310-96x96.jpg\",\"url\":\"https:\\\/\\\/live-infoblox-blog.pantheonsite.io\\\/wp-content\\\/uploads\\\/avatar_user_179_1571767310-96x96.jpg\",\"contentUrl\":\"https:\\\/\\\/live-infoblox-blog.pantheonsite.io\\\/wp-content\\\/uploads\\\/avatar_user_179_1571767310-96x96.jpg\",\"caption\":\"Chris Richardson\"},\"description\":\"Chris Richardson has worked in the Anti-Fraud and Information Security Fields for over 15 years. Starting with IID (Internet Identity) in 2005, Chris built and managed the 24x7 External Threat Detection & Mitigation Team, supporting hundreds of customers and working with thousands of web hosts and registrars. Chris was part of the core leadership team that led IID\u2019s evolution into a leading distributor of timely, accurate, contextualized threat intelligence feeds that enhance existing Security deployments, and Chris has participated in several cross-sector working groups. In 2016, IID joined Infoblox to create holistic core network security solutions for customers in a variety of sectors.\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/author\\\/chris-richardson\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Using Custom RPZs to Block Abusive Top Level Domains","description":"Using Custom RPZs to Block Abusive Top Level Domains. If you work in network defense or security operations and haven\u2019t looked at custom Response Policy Zones in a while (or ever!) you\u2019re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge, it\u2019s understandable that configuring rules for DNS resolution gets missed. For simplicity, this function resides in \u201cthe middle\u201dof our pantheon \u2013 the core network control layer not defined under \u201cedge defense\u201d and not within the purview of \u201cendpoint security\u201d.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/","og_locale":"en_US","og_type":"article","og_title":"Using Custom RPZs to Block Abusive Top Level Domains","og_description":"Using Custom RPZs to Block Abusive Top Level Domains. If you work in network defense or security operations and haven\u2019t looked at custom Response Policy Zones in a while (or ever!) you\u2019re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge, it\u2019s understandable that configuring rules for DNS resolution gets missed. For simplicity, this function resides in \u201cthe middle\u201dof our pantheon \u2013 the core network control layer not defined under \u201cedge defense\u201d and not within the purview of \u201cendpoint security\u201d.","og_url":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/","og_site_name":"Infoblox Blog","article_published_time":"2022-05-16T19:20:21+00:00","article_modified_time":"2022-05-16T20:30:57+00:00","og_image":[{"width":1471,"height":434,"url":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/banner-Cybersecurity.jpg","type":"image\/jpeg"}],"author":"Chris Richardson","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Chris Richardson","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/#article","isPartOf":{"@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/"},"author":{"name":"Chris Richardson","@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/person\/b8f3f1cabebf56f93d704a790f2eddf3"},"headline":"Using Custom RPZs to Block Abusive Top Level Domains","datePublished":"2022-05-16T19:20:21+00:00","dateModified":"2022-05-16T20:30:57+00:00","mainEntityOfPage":{"@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/"},"wordCount":1353,"publisher":{"@id":"https:\/\/www.infoblox.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/#primaryimage"},"thumbnailUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/banner-Cybersecurity.jpg","keywords":["Response Policy Zones (RPZ)","DNS","threat location data","DNS Resolver","TLD","FQDN"],"articleSection":["Security"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/","url":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/","name":"Using Custom RPZs to Block Abusive Top Level Domains","isPartOf":{"@id":"https:\/\/www.infoblox.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/#primaryimage"},"image":{"@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/#primaryimage"},"thumbnailUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/banner-Cybersecurity.jpg","datePublished":"2022-05-16T19:20:21+00:00","dateModified":"2022-05-16T20:30:57+00:00","description":"Using Custom RPZs to Block Abusive Top Level Domains. If you work in network defense or security operations and haven\u2019t looked at custom Response Policy Zones in a while (or ever!) you\u2019re not alone. In the day-to-day commotion between identifying and reacting to events on end points or at the edge, it\u2019s understandable that configuring rules for DNS resolution gets missed. For simplicity, this function resides in \u201cthe middle\u201dof our pantheon \u2013 the core network control layer not defined under \u201cedge defense\u201d and not within the purview of \u201cendpoint security\u201d.","breadcrumb":{"@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/#primaryimage","url":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/banner-Cybersecurity.jpg","contentUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/banner-Cybersecurity.jpg","width":1471,"height":434},{"@type":"BreadcrumbList","@id":"https:\/\/www.infoblox.com\/blog\/security\/using-custom-rpzs-to-block-abusive-top-level-domains\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.infoblox.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Security","item":"https:\/\/www.infoblox.com\/blog\/category\/security\/"},{"@type":"ListItem","position":3,"name":"Using Custom RPZs to Block Abusive Top Level Domains"}]},{"@type":"WebSite","@id":"https:\/\/www.infoblox.com\/blog\/#website","url":"https:\/\/www.infoblox.com\/blog\/","name":"infoblox.com\/blog\/","description":"","publisher":{"@id":"https:\/\/www.infoblox.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.infoblox.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.infoblox.com\/blog\/#organization","name":"Infoblox","url":"https:\/\/www.infoblox.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/infoblox-logo-2.svg","contentUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/infoblox-logo-2.svg","width":137,"height":30,"caption":"Infoblox"},"image":{"@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/person\/b8f3f1cabebf56f93d704a790f2eddf3","name":"Chris Richardson","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/avatar_user_179_1571767310-96x96.jpg","url":"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/avatar_user_179_1571767310-96x96.jpg","contentUrl":"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/avatar_user_179_1571767310-96x96.jpg","caption":"Chris Richardson"},"description":"Chris Richardson has worked in the Anti-Fraud and Information Security Fields for over 15 years. Starting with IID (Internet Identity) in 2005, Chris built and managed the 24x7 External Threat Detection & Mitigation Team, supporting hundreds of customers and working with thousands of web hosts and registrars. Chris was part of the core leadership team that led IID\u2019s evolution into a leading distributor of timely, accurate, contextualized threat intelligence feeds that enhance existing Security deployments, and Chris has participated in several cross-sector working groups. In 2016, IID joined Infoblox to create holistic core network security solutions for customers in a variety of sectors.","url":"https:\/\/www.infoblox.com\/blog\/author\/chris-richardson\/"}]}},"_links":{"self":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/7734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/users\/179"}],"replies":[{"embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/comments?post=7734"}],"version-history":[{"count":2,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/7734\/revisions"}],"predecessor-version":[{"id":7736,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/7734\/revisions\/7736"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/media\/4043"}],"wp:attachment":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/media?parent=7734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/categories?post=7734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/tags?post=7734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}