Proper DNS deployment one key to DNS security

Two basic tenants of information technology (IT) network security practices entail partitioning DNS server deployments and corresponding functions based on trust zones and in employing a multi-layered defense in depth style approach. I’ll use the term “trust sectors” instead of “trust zones” given the ambiguity of the word “zone” in a DNS context. Establishing an effective defense is critical as is preparation, monitoring, event detection to rapidly identify attacks in progress and enact recovery plans to perform mitigation actions to minimize or nullify their impacts. Event post-mortems are also critical to feeding back to the security plan to apply lessons learned to improve detection and recovery times.

Generally, DNS deployment designs should account for high availability, performance, scalability, human intervention and of course, security. Using a trust sector approach to DNS server deployment allows you to segment namespace and resolution responsibility which provides a solid foundation for achieving these objectives. Keep in mind that there is no “one size fits all” cookie cutter deployment architecture. However, by defining role-based server configurations as trust sectors, you can select which are applicable based on your environment’s scale and policies.

Based on the flow of DNS queries, I recommend defining the following four trust sectors based on query source and the context of the query.

  1. Recursive trust sector - this sector comprises internal (within the organization) queriers (stub resolvers) querying recursive servers out through a demilitarized zone (DMZ) to the Internet. This trust sector enables internal clients to access external/Internet websites and by necessity requires access to and from the Internet with associated security controls.
  2. Internal trust sector - internal stub resolvers desiring to access intranet sites make use of the internal trust sector. This sector comprises stub resolvers querying recursive servers which forward to internal authoritative DNS servers. As internal and presumably more sensitive destinations are published through these internal authoritative servers, security measures are required to control access to such information which could provide attackers a set of potential targets.
  3. External trust sector - this sector comprises your external or Internet-facing DNS infrastructure, whether in-house, outsourced or both. These servers publish Internet reachable destinations such as web and email servers. Query access is generally open to all, but important steps are required to disable recursion, mitigate reflector attacks, and prevent breaching your internal DNS or network in general.
  4. Extranet trust sector - for partners or suppliers, some organizations publish server information to support access to information such as inventories or pricing. Controls are required to constrain access only to said partners and to prevent infiltration into the internal network. 

I invite you to check out my DNS trust sector video for more information and details about configuring DNS servers and affiliated network elements to achieve a DNS security zones deployment in your network.

Comments

Post a Comment

Popular posts from this blog

Handy AAAA filter in BIND 9.8

The ISC introduced a pair of new configuration file options in BIND 9.8 to enable administrators to easily filter who may receive AAAA record type responses even if valid responses exist. For example, clients on subnets that do not have IPv6 network access can be excluded from receiving affirmative answers for AAAA queries. This feature provides simpler administration than the alternative mechanism using views. The first option, filter-aaaa-on-v4,defines whether the server will return AAAA records to certain clients. Such clients are defined by the address match list parameter of the second option, filter-aaaa. Note that BIND must be compiled with the --enable-filter-aaaa option on the configure command line to enable AAAA filtering. The syntax of these options is as follows: filter-aaaa-on-v4 (yes | no | break-dnssec) ; filter-aaaa {addr_match_list;} ; The filter-aaaa option identifies the address match list for which the filter-aaaa-on-v4 option is to be applied as described
Read more

Inglorious DDI

We all know how critical DHCP/DNS/IPAM (DDI) services are. Your network cannot function without them. But like most foundational elements of anything, they are certainly not glamorous...like good luck finding a home designer who specializes in home foundations. I would not be shocked should HGTV pass on my brilliant concept for a foundation building show. I suppose most people would find a show detailing footing depths and concrete pouring techniques rather boring.  Nevertheless, there are countless shows for redesigning and remodeling homes. On most episodes the foundation is out of sight, out of mind. If it's stable, no one wants to pay it attention, they just expect it to keep doing its job, supporting the structure. Once in a while a foundational issue is brought up that unexpectedly threatens to raise the budget to heighten the drama. All work stops until the issue is addressed. And you'll notice that the owner never denies paying the extra amount to fix the issue.
Read more

BIND 9.8.0 Adds DNS64 Support - Part 2 - How is it configured?

BIND 9.8.0 introduced a new dns64 option statement that can be configured within the server named.conf options block or within a view options block. Recall from a prior post that DNS64 configures a recursive DNS server to issue A record queries on behalf of a client requesting AAAA records, then appends the returned IPv4 address to a defined IPv6 prefix. This manufactured IPv6 address enables the querying host to connect to a NAT64 gateway which will terminate the IPv6 connection from the client and map it to an outbound IPv4 connection to the appended IPv4 address, completing the connection! Whew! BIND offers a number of useful parameters within the dns64 statement to control this process. The statement syntax is: dns64 IPv6_prefix { [clients {address_match_list };] [mapped {address_match_list };] [exclude {address_match_list };] [suffix IPv6_addr;] [recursive-only (yes|no);] [break-dnssec (yes|no);] }; The IPv6_prefix parameter is the prefix to which returned
Read more