{"id":652,"date":"2018-03-01T17:57:46","date_gmt":"2018-03-01T17:57:46","guid":{"rendered":"https:\/\/live-infoblox-blog.pantheonsite.io\/?p=652"},"modified":"2022-10-20T14:59:52","modified_gmt":"2022-10-20T21:59:52","slug":"good-hygiene-for-securing-dns-part-2","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/","title":{"rendered":"Good hygiene for Securing DNS (Part 2)"},"content":{"rendered":"

Picking up where we left off from\u00a0part 1<\/a>,\u00a0we are going to cover some of the more advanced DNS Security topics. If you haven\u2019t read the part 1 one yet, please do.<\/p>\n

As with part 1, the info is pretty generic, but the screenshots are from the Infoblox Grid Manager GUI.<\/p>\n

Let\u2019s take a look at the authoritative side first<\/strong>.<\/p>\n

A lot of organizations have what is called split view (or split horizon) DNS.\u00a0 This just means that the same Domain Name exists inside the company as outside the company but has a different dataset. If you do use split view DNS, then you will want to make sure that only those IPs that should get a specific view of data actually get the data.\u00a0 One reason this is important is that if you use a secondary service, you don\u2019t want your external answers being used internally and causing breakage (think internal only apps or sites). Another is internal answers leaking out to the internet and giving a potential attacker a leg up on reconnaissance.\u00a0 I can\u2019t tell you how many times I\u2019ve seen misconfigurations of the type above cause havoc and inconsistent results.\u00a0 Use match destination in addition to match client to help mitigate the detrimental effects.<\/p>\n

DNSSEC Signing your zones<\/em><\/strong><\/p>\n

If you decide to be a good netizen and sign your zones, then you have some decisions to make.\u00a0 The first of which is NSEC or NSEC3.\u00a0 NSEC was the first of the two specs but had the unfortunate side effect of being able to enumerate all the data in the zone.\u00a0 This effectively amounts to a zone transfer of the data, NSEC3 was created to resolve this issue.\u00a0 Some organizations dislike the idea of their zone data being enumerated but then some consider this security through obscurity. Personally, I think it is security through obscurity, but I\u2019d rather make it as difficult on an attacker as I can — maybe that is just me. There are performance implications between NSEC and NSEC3 but if you stick with the Infoblox defaults the difference in burden between the two should be negligible.\u00a0 In general, you want to make the bar high enough that it isn\u2019t easily solved and reversed (or more accurately a collision found).\u00a0 But also, the bar shouldn\u2019t be so high that it takes too long to verify.\u00a0 The Infoblox defaults for salt length are between 1 and 15 octets and 10 hash iterations.<\/p>\n

Now let\u2019s talk about the Key Signing Key (KSK) and Zone Signing Key (ZSK).\u00a0 Current NIST guidance is 1-2 years on the KSK and 1-3 months on the ZSK for the lifetime of the keys before they should be rolled.\u00a0 Additional guidance from NIST on the use of RSA keys, in general, is that it should be 2048 or more and that SHA-1 should not be used for new hashing.\u00a0 This leaves us with RSA\/SHA-256 with a size of 2048 or better for both KSK and ZSK.\u00a0 The rest of the defaults are fine, except if you upgraded from a release prior to 6.11 NIOS.\u00a0 Prior to 6.11 pre-publish was not an option.\u00a0 In that case, make sure to switch your ZSK rollover method to \u201cPre-publish\u201d.\u00a0 This will save you some reply size space, and some additional headache if you use an HSM to sign your zone.<\/p>\n

\"Securing<\/p>\n

On Infoblox, when you enabled DNSSEC Signing of the zone data it will also increase your object count because of the additional records added. \u00a0So, talk to your SE to make sure you have the right sized solution.<\/p>\n

Next, we will cover Response Rate Limiting (RRL<\/em><\/strong>).<\/em><\/p>\n

This feature is intended to be used on authoritative servers. \u00a0We will cover the recursive counterparts a little later on in the article.\u00a0 RRL does exactly what the names says, it limits the responses sent, but only over UDP, and it does so by putting clients into buckets based on network masks.\u00a0 Using this feature will keep you from being part of a DDoS without dropping real queries in a significant way.\u00a0 Over IPv4 it uses a \/24 bucket, and for IPv6 it uses a \/56 bucket for the credit\/debit response per second.\u00a0 The exact number you want to set your limit will be highly dependent on your configuration and what your normal traffic patterns are, but the Infoblox default is 100.\u00a0 Once a given bucket reaches the limit, the \u201cSLIP\u201d comes into play.\u00a0 The slip is to indicates which of the over the limit queries are to be answered with a truncation message, which would tell a real client to retry the query over TCP.\u00a0 The default value on Infoblox is 2, meaning that every other packet gets get the TC message telling the client to retry over TCP.<\/p>\n

There is some disagreement over what the value should be, and it really depends on your environment and goals.\u00a0 Some default configurations go with 1 while others use 2.\u00a0 The reason for going with 1 rather than 2 is to slow down the Kaminsky attack.\u00a0 Using a value of 2 brings the time execute a successful Kaminsky style attack down significantly.\u00a0 Fortunately, we have a different solution for that called DNSSEC \u2013 see the above and we will ignore the adoption rates for the purposes of this post.\u00a0 Using a slip value of 1 means that there will be more TCP conversations for DNS which is much more expensive in terms of resources used on the authoritative name server.\u00a0 So, if your customers are doing validation (like Google\u2019s public DNS and Comcast), then your better option for the slip value is 2.\u00a0 If, on the other hand, your customers are not likely to have DNSSEC validation enabled, then you may want to set your slip value to 1.\u00a0 Unfortunately, there isn\u2019t an Infoblox GUI widget that you can use for this. Instead, you will need to break out the CLI for this (show dns_rrl and set dns_rrl).<\/p>\n

If you are self-hosting zones you may benefit from the PT Platform which has a smart NIC that can further protect the host appliance from external attack using a ruleset that Infoblox produces and publishes.<\/p>\n

Now we will take a look at the recursive side.<\/strong><\/p>\n

The first thing we want is to make sure we don\u2019t make another DNS Admin\u2019s life miserable. There are a few ways we can handle this.\u00a0 The first way we covered in\u00a0part 1<\/a>\u00a0which is to use a third-party resolver service for recursion.\u00a0 Most definitely if you aren\u2019t going to use a third-party resolver service you will need to consider the recursive counterparts to RRL.\u00a0 Even if you are going to use a third-party recursion service, you will want to consider the measures.<\/p>\n

Recursive hold-down and limits<\/em><\/strong><\/p>\n

The first item we need to consider is going to be the hold-down for non-responsive servers. \u00a0This will actually protect your recursive server from bad upstream servers \u2013 bad here could be intentional, under attack, or unintentional configuration errors.\u00a0 After that, we want to set some limits on recursion per server and then per zone.\u00a0 This is so we don\u2019t put unnecessary stress on the upstream name servers.\u00a0 If you are using a third-party recursion service then you will want to tweak these numbers or uncheck the box, specifically you will probably want to bump the hold down timeouts up some and lower the duration to 30.\u00a0 You will also want to uncheck the \u201cLimit recursive queries per server\u201d box if you are using a third-party for recursion.\u00a0 If you are not using a third-party recursive service, then the Infoblox defaults as shown below should be pretty good for all but the very largest ISP installments.<\/p>\n

\"Securing<\/p>\n

Now that we\u2019ve taken care of not making other DNS admin\u2019s lives harder than necessary, let\u2019s talk about Response Policy Zones (RPZ).\u00a0 RPZ was created to solve the problem of malicious domains.\u00a0 It is a zone just like any other zone if you were to look at the contents.\u00a0 We only know it is an RPZ because we tell the NS that it is to be used for policy decisions.\u00a0 Those policy decisions are encoded using the existing DNS language.\u00a0 Before RPZ, in order to block a C&C or other malicious domain, you would have to create the zone on your infrastructure which could be problematic and potentially expensive in terms of resources.\u00a0 With RPZ there is no need to do that and you can just return substitution (or any of the policy actions like NXDOMAIN) for a single host in the domain in question.\u00a0 There are a few RPZ feed services out there \u2013 including several Infoblox feed options \u2013 that will help keep you safe from current threats.\u00a0 Typically, you want your RPZs a close to the clients as possible. This is so you can identify the specific client that has the issue right away without chasing down logs from other systems.\u00a0 The RPZ \u201chits\u201d are logged \u2013 if configured to do so \u2013 in the standard CEF format that your security people will be able to ingest using their tools.\u00a0 There is one more thing about RPZ but we will talk about that in the DNSSEC Validation section.<\/p>\n

DNSSEC Validation<\/em><\/strong><\/p>\n

Validation takes advantage of the zones that have been signed and \u201cchained\u201d to their parent zones which at some point are chained to the root zone.\u00a0 Thankfully it is easier to configure than to explain how it works.\u00a0 There are these things called trust anchors (sometimes called TAs). As it turns out this is just the RRData from DNSKEY Resource Records (RRs) where they have the \u201cSecure Entry Point\u201d (SEP) bit set (called the Key Signing Key or KSK).\u00a0 Currently, the root zone has 2 KSKs keys published.\u00a0 These are the 2010 Key which is what originally signed the root zone and the 2017 key which was scheduled to go into production back in October of 2017 but was put off due to concerns from\u00a0ICANN and the community<\/a>.\u00a0 Once you have installed these keys into your recursive resolver configuration, your server will validate answers for zones that are signed and chained to their parent all the way up to the root zone.\u00a0 If there is any part of the chain missing your server will not validate that zone even though it is signed.\u00a0 That is unless you add a specific TA that would allow validation of that zone.\u00a0 That is not a common configuration; more on that in a bit.<\/p>\n

And now to explain how the chain of trust works*.<\/em><\/strong><\/p>\n

*TLDR<\/strong>: Complicated, but it works kind of like the certificate authority model, but there is only one root.\u00a0 And the parent doesn\u2019t need to give you\u2019re the signed version because it is in DNS.\u00a0 The chain is established by using a special record called a Delegation Signer (DS).\u00a0 This record has the label of the delegation just like an NS record. But it is different because it only exists in the parent zone and not the delegated (or child) zone.\u00a0 The part that makes all this work is that the RRData of the DS RR is the fingerprint of the KSK of the delegated zone.\u00a0 As with most any other RRSet, it gets an RRSIG (Resource Record Signature) from the ZSK for the zone.\u00a0 The DNSKEY RRSet can be a special case, by which I mean that there are several methods that can be used in the signing operation.\u00a0 One method only signs the DNSKEY RRSet with the zone KSK, the other method (which Infoblox uses) is to sign the DNSKEY RRSet with the KSK and ZSK.\u00a0 Further to that, each of the above could use pre-publish or double signature.\u00a0 Using the DNSKEY RRSet and the configured TAs, we should be able to follow the KSK signature to the ZSK DNSKEY(s) which would sign a DS RRSet that leads us down to another KSK which signs as described above.<\/p>\n

If you have split view DNS, then you will also probably want to install a negative trust anchor for those zones that are signed externally.\u00a0 Or sign them and install a TA before enabling validation \u2013 this is not common in my experience.\u00a0 If you don\u2019t do one or the other, then your internal zones will show as bogus and your domain will disappear internally which would be not good.<\/p>\n

Remember how I said there was another consideration for RPZ?\u00a0 RPZ is a way of intentionally lying in DNS.\u00a0 This is diametrically opposed to why DNSSEC exists, so if we want to be able to tell some lies to clients downstream for a \u201cgood reason\u201d then we need to tell our recursive resolver to apply the RPZ anyway.<\/p>\n

Below is a screenshot of where you configured the trust anchors, negative trust anchors, and policy overrides for DNSSEC in Infoblox at the grid level.<\/p>\n

\"Securing<\/p>\n

Thanks for your time, and I hope you find it useful.<\/p>\n","protected":false},"excerpt":{"rendered":"

Picking up where we left off from\u00a0part 1,\u00a0we are going to cover some of the more advanced DNS Security topics. If you haven\u2019t read the part 1 one yet, please do. As with part 1, the info is pretty generic, but the screenshots are from the Infoblox Grid Manager GUI. Let\u2019s take a look at […]<\/p>\n","protected":false},"author":188,"featured_media":590,"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":[3],"tags":[28,30,44,15],"class_list":{"0":"post-652","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-community","8":"tag-ddi","9":"tag-dns","10":"tag-dns-firewall","11":"tag-security","12":"entry"},"acf":[],"yoast_head":"\nGood hygiene for Securing DNS (Part 2) - Infoblox Blog<\/title>\n<meta name=\"description\" content=\"DNS networks have become increasingly important in recent years. Find out how you can utilize advanced DNS security functionalities to improve your network.\" \/>\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\/community\/good-hygiene-for-securing-dns-part-2\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Good hygiene for Securing DNS (Part 2)\" \/>\n<meta property=\"og:description\" content=\"DNS networks have become increasingly important in recent years. Find out how you can utilize advanced DNS security functionalities to improve your network.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/\" \/>\n<meta property=\"og:site_name\" content=\"Infoblox Blog\" \/>\n<meta property=\"article:published_time\" content=\"2018-03-01T17:57:46+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-10-20T21:59:52+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/good-hygiene-securing-dns.jpeg\" \/>\n\t<meta property=\"og:image:width\" content=\"600\" \/>\n\t<meta property=\"og:image:height\" content=\"413\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Donald Rudder\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Donald Rudder\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"11 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/\"},\"author\":{\"name\":\"Donald Rudder\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#\\\/schema\\\/person\\\/ef196adb59fadb13c7f84408bcc9634d\"},\"headline\":\"Good hygiene for Securing DNS (Part 2)\",\"datePublished\":\"2018-03-01T17:57:46+00:00\",\"dateModified\":\"2022-10-20T21:59:52+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/\"},\"wordCount\":2143,\"publisher\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/good-hygiene-securing-dns.jpeg\",\"keywords\":[\"DDI\",\"DNS\",\"DNS Firewall\",\"Security\"],\"articleSection\":[\"Community\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/\",\"name\":\"Good hygiene for Securing DNS (Part 2) - Infoblox Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/good-hygiene-securing-dns.jpeg\",\"datePublished\":\"2018-03-01T17:57:46+00:00\",\"dateModified\":\"2022-10-20T21:59:52+00:00\",\"description\":\"DNS networks have become increasingly important in recent years. Find out how you can utilize advanced DNS security functionalities to improve your network.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/good-hygiene-securing-dns.jpeg\",\"contentUrl\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/wp-content\\\/uploads\\\/good-hygiene-securing-dns.jpeg\",\"width\":600,\"height\":413},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/community\\\/good-hygiene-for-securing-dns-part-2\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Community\",\"item\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/category\\\/community\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Good hygiene for Securing DNS (Part 2)\"}]},{\"@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\\\/ef196adb59fadb13c7f84408bcc9634d\",\"name\":\"Donald Rudder\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a835205b966d30d719c81be7116b55cfdb887af925e0d84efdf2304b84ec6572?s=96&d=blank&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a835205b966d30d719c81be7116b55cfdb887af925e0d84efdf2304b84ec6572?s=96&d=blank&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a835205b966d30d719c81be7116b55cfdb887af925e0d84efdf2304b84ec6572?s=96&d=blank&r=g\",\"caption\":\"Donald Rudder\"},\"url\":\"https:\\\/\\\/www.infoblox.com\\\/blog\\\/author\\\/donald-rudder\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Good hygiene for Securing DNS (Part 2) - Infoblox Blog","description":"DNS networks have become increasingly important in recent years. Find out how you can utilize advanced DNS security functionalities to improve your network.","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\/community\/good-hygiene-for-securing-dns-part-2\/","og_locale":"en_US","og_type":"article","og_title":"Good hygiene for Securing DNS (Part 2)","og_description":"DNS networks have become increasingly important in recent years. Find out how you can utilize advanced DNS security functionalities to improve your network.","og_url":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/","og_site_name":"Infoblox Blog","article_published_time":"2018-03-01T17:57:46+00:00","article_modified_time":"2022-10-20T21:59:52+00:00","og_image":[{"width":600,"height":413,"url":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/good-hygiene-securing-dns.jpeg","type":"image\/jpeg"}],"author":"Donald Rudder","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Donald Rudder","Est. reading time":"11 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/#article","isPartOf":{"@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/"},"author":{"name":"Donald Rudder","@id":"https:\/\/www.infoblox.com\/blog\/#\/schema\/person\/ef196adb59fadb13c7f84408bcc9634d"},"headline":"Good hygiene for Securing DNS (Part 2)","datePublished":"2018-03-01T17:57:46+00:00","dateModified":"2022-10-20T21:59:52+00:00","mainEntityOfPage":{"@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/"},"wordCount":2143,"publisher":{"@id":"https:\/\/www.infoblox.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/#primaryimage"},"thumbnailUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/good-hygiene-securing-dns.jpeg","keywords":["DDI","DNS","DNS Firewall","Security"],"articleSection":["Community"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/","url":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/","name":"Good hygiene for Securing DNS (Part 2) - Infoblox Blog","isPartOf":{"@id":"https:\/\/www.infoblox.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/#primaryimage"},"image":{"@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/#primaryimage"},"thumbnailUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/good-hygiene-securing-dns.jpeg","datePublished":"2018-03-01T17:57:46+00:00","dateModified":"2022-10-20T21:59:52+00:00","description":"DNS networks have become increasingly important in recent years. Find out how you can utilize advanced DNS security functionalities to improve your network.","breadcrumb":{"@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/#primaryimage","url":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/good-hygiene-securing-dns.jpeg","contentUrl":"https:\/\/www.infoblox.com\/blog\/wp-content\/uploads\/good-hygiene-securing-dns.jpeg","width":600,"height":413},{"@type":"BreadcrumbList","@id":"https:\/\/www.infoblox.com\/blog\/community\/good-hygiene-for-securing-dns-part-2\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.infoblox.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Community","item":"https:\/\/www.infoblox.com\/blog\/category\/community\/"},{"@type":"ListItem","position":3,"name":"Good hygiene for Securing DNS (Part 2)"}]},{"@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\/ef196adb59fadb13c7f84408bcc9634d","name":"Donald Rudder","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a835205b966d30d719c81be7116b55cfdb887af925e0d84efdf2304b84ec6572?s=96&d=blank&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/a835205b966d30d719c81be7116b55cfdb887af925e0d84efdf2304b84ec6572?s=96&d=blank&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a835205b966d30d719c81be7116b55cfdb887af925e0d84efdf2304b84ec6572?s=96&d=blank&r=g","caption":"Donald Rudder"},"url":"https:\/\/www.infoblox.com\/blog\/author\/donald-rudder\/"}]}},"_links":{"self":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/652","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\/188"}],"replies":[{"embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/comments?post=652"}],"version-history":[{"count":3,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/652\/revisions"}],"predecessor-version":[{"id":8186,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/posts\/652\/revisions\/8186"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/media\/590"}],"wp:attachment":[{"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/media?parent=652"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/categories?post=652"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.infoblox.com\/blog\/wp-json\/wp\/v2\/tags?post=652"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}