WWW Cisco Com Web About Security Intelligence DNS BCP HTML

Cisco Systems, Inc.
Worldwide [change] Log In Account Register My Cisco
Products & Services Support How to Buy Training & Events Partners Go
DNS Best Practices, Network Protections, and Attack Identification

Contents
Overview
What is DNS?
Maliciously Abusing Implementation Flaw s in DNS
Protections for Spoofing
Detecting and Preventing DNS Attacks using Cisco Products and Features
DNS Tools and Resources
Overview
This w hite paper provides information on general best practices, netw ork protections, and attack identification techniques that operators and administrators can use for
implementations of the Domain Name System (DNS) protocol. Cisco Security
Intelligence Operations
What is DNS?
DNS is a globally distributed, scalable, hierarchical, and dynamic database that provides a mapping betw een hostnames, IP addresses (both IPv4 and IPv6), text records, mail Related Links
exchange information (MX records), name server information (NS records), and security key information defined in Resource Records (RRs). The information defined in RRs is Products and Services
grouped into zones and maintained locally on a DNS server so it can be retrieved globally through the distributed DNS architecture. DNS can use either the User Datagram Cisco Security Intelligence
Protocol (UDP) or Transmission Control Protocol (TCP) and historically uses a destination port of 53. When the DNS protocol uses UDP as the transport, it has the ability to deal Operations
w ith UDP retransmission and sequencing.
Security Services
DNS is composed of a hierarchical domain name space that contains a tree-like data structure of linked domain names (nodes). Domain name space uses Resource Records Security and VPN Products
(RRs) that may or may not exist to store information about the domain. The tree-like data structure for the domain name space starts at the root zone ".", w hich is the top most Cisco IntelliShield Alert Manager
level of the DNS hierarchy. Although it is not typically displayed in user applications, the DNS root is represented as a trailing dot in a fully qualified domain name (FQDN). For
example, the right-most dot in "www.cisco.com." represents the root zone. From the root zone, the DNS hierarchy is then split into sub-domain (branches) zones. Feedback
Each domain name is composed of one or more labels. Labels are separated w ith "." and may contain a maximum of 63 characters. A FQDN may contain a maximum of 255
characters, including the ".". Labels are constructed from right to left, w here the label at the far right is the top level domain (TLD) for the domain name. The follow ing example What prompted you to visit this page?
show s how to identify the TLD for a domain name: Existing netw ork problem
com is the TLD for w w w .cisco.com as it is the label furthest to the right. Best practice implementation
Research/certification training
Dom ain Nam e Space
The follow ing diagram illustrates a sample of the Domain Name System hierarchy starting from the root ".". Everything below the ".org" domain name space is in the org domain Referred by cow orker/colleague
and everything below ".cisco.com " domain name space is in the cisco.com domain. Referred by Cisco employee
Figure 1. Dom ain Nam e Space What additional topics should be
open in browser PRO version Are you a developer? Try out the HTML to PDF API pdfcrowd.com
covered?
How could this information be more

useful or relevant?
Submit
The DNS protocol specification and implementation w as originally defined in RFC 882 and RFC 883. These RFCs w ere made obsolete by RFC 1034 and RFC 1035 and have
been updated by multiple RFCs over the years.
Im portant DNS Term inology

To understand DNS and the DNS-specific recommendations in this document, it is important that operators and administrators are familiar w ith the follow ing terms:
Resolver: A DNS client that sends DNS messages to obtain information about the requested domain name space.
Recursion: The action taken w hen a DNS server is asked to query on behalf of a DNS resolver.
Authoritative Server: A DNS server that responds to query messages w ith information stored in RRs for a domain name space stored on the server.
Recursive Resolver: A DNS server that recursively queries for the information asked in the DNS query.
FQDN: A Fully Qualified Domain Name is the absolute name of a device w ithin the distributed DNS database.
RR: A Resource Record is a format used in DNS messages that is composed of the follow ing fields: NAME, TYPE, CLASS, TTL, RDLENGTH, and RDATA.
Zone: A database that contains information about the domain name space stored on an authoritative server.
Prim ary Function of DNS

DNS primarily translates hostnames to IP addresses or IP addresses to hostnames. This translation process is accomplished by a DNS resolver (this could be a client application
such as a w eb brow ser or an e-mail client, or a DNS application such as BIND) sending a DNS query to a DNS server requesting the information defined in a RR. Some
examples of the DNS resolution process follow :
If the DNS server is only configured as an authoritative server and it receives a DNS query message asking about information w hich the server is authoritative, it w ill cause
the server to inspect locally stored RR information and return the value of the record in the 'Answ er Section' of a DNS response message. If the requested information for
the DNS query message does not exist, the DNS server w ill respond w ith a NXDOMAIN (Non-Existent Domain) DNS response message or a DNS Referral Response
message.
If the DNS server is authoritative, not configured as a recursive resolver, and it receives a DNS query message asking about information w hich the server is not
authoritative, it w ill cause the server to issue a DNS response message containing RRs in the 'Authority Section' and the address mapping for the FQDN from that section
may be present in the 'Additional Section'. This informs the DNS resolver w here to send queries in order to obtain authoritative information for the question in the DNS query.
This is also know n as a DNS Referral Response message.
If the DNS server is not authoritative but is configured as a recursive resolver and it receives a DNS query asking about information, it w ill cause the server to recursively
query (iterative queries) the DNS architecture for the authoritative DNS server of the information included in the DNS request. Once the recursive DNS resolver has obtained
this information, it w ill provide that information to the original DNS resolver using a DNS response message and the RR w ill be non-authoritative (since the recursive DNS
resolver is not authoritative for the requested information). The recursive DNS resolver may also have know ledge about the requested information stored in DNS cache. If
the requested information is present in the DNS cache, then the recursive DNS resolver w ill respond w ith that RR information.
Figure 2 illustrates the iterative process used by a DNS recursive resolver (DNS Recursor, server) to answ er the DNS query message (question) on behalf of the DNS resolver
(DNS Resolver, client) and provide a DNS query response message (answ er).
Figure 2. Recursive Query
1. The DNS resolver sends a query message to the recursive resolver asking for the address of w w w .cisco.com.
2. The DNS recursor sends a query message to the root name servers looking for the .com domain name space.
3. The root name servers send a DNS referral response message to the DNS recursor informing it to ask the gTLD name servers for the .com domain name space.
4. The DNS recursor sends a query message to the gTLD name servers looking for the .cisco.com domain name space.
5. The gTLD name servers send a DNS referral response message to the DNS recursor informing it to ask the .cisco.com name servers, ns1.cisco.com or ns2.cisco.com,
about this domain name space.
6. The DNS recursor sends a query to ns1.cisco.com or ns2.cisco.com asking for w w w .cisco.com.
7. The .cisco.com name servers, ns1.cisco.com or ns2.cisco.com, send an authoritative DNS query response message to the DNS recursor w ith the A (address) RR
information for w w w .cisco.com.
8. The DNS recursor sends a DNS query response message to the DNS resolver w ith the A (address) RR information for w w w .cisco.com.
DNS Messages
All legitimate DNS messages sent or received are composed of multiple sections. These sections of the DNS message contain fields that determine how the message w ill be
All legitimate DNS messages sent or received are composed of multiple sections. These sections of the DNS message contain fields that determine how the message w ill be
processed by the device receiving the message. These sections also contain information about the question (query messages) a device is asking or answ ers (response
messages) a device may be providing. The sections present in a DNS message are Header, Question, Answ er, Authority, and Additional.
Note that there are situations w here sections of the DNS message may be empty. An example is a 'DNS Referral Response Message', in w hich the Answ er section is empty,
but the Authority and Additional sections are present and contain RR information.
For more information about the sections of a DNS message, their format, and the fields they contain, consult RFC 1035, Section 4., Messages.
Maliciously Abusing Implementation Flaws in DNS

Flaw s in the implementation of the DNS protocol allow it to be exploited and used for malicious activities. Because DNS is such a critical protocol for Internet operations,
countless operating systems, and applications, operators and administrators must harden DNS servers to prevent them from being used maliciously. Some of these flaw s are
presented in this document to inform operators how they can be used maliciously. Techniques are shared that can be used to prevent these types of activities.
DNS Open Resolvers

A DNS open resolver is a DNS server that allow s DNS clients that are not part of its administrative domain to use that server for performing recursive name resolution.
Essentially, a DNS open resolver provides responses (answ ers) to queries (questions) from anyone asking a question. DNS open resolvers are vulnerable to multiple malicious
activities, including the follow ing:
DNS cache poisoning attacks

DNS cache poisoning attacks
Resource utilization attacks
Denial of Service (DoS) or Distributed DoS (DDoS)
DNS Cache Poisoning Attacks

DNS cache poisoning occurs w hen an attacker sends falsified and usually spoofed RR information to a DNS resolver. Once the DNS resolver receives the falsified RR
information, it is stored in the DNS cache for the lifetime (Time To Live [TTL]) set in the RR. To exploit this flaw in the DNS resolver implementation so it w ill store the falsified
information, an attacker must be able to correctly predict the DNS transaction identifier (TXID) and the UDP source port for the DNS query (request) message. Attackers use this
exploitation technique to redirect users from legitimate sites to malicious sites or to inform the DNS resolver to use a malicious name server (NS) that is providing RR information
used for malicious activities.
DNS Am plification and Reflection Attacks

DNS amplification and reflection attacks use DNS open resolvers to increase the volume of attacks and to hide the true source of an attack, actions that typically result in a DoS
or DDoS attack. These attacks are possible because the open resolver w ill respond to queries from anyone asking a question. Attackers use these DNS open resolvers for
malicious activities by sending DNS messages to the open resolvers using a forged source IP address that is the target for the attack. When the open resolvers receive the
spoofed DNS query messages, they respond by sending DNS response messages to the target address. Attacks of these types use multiple DNS open resolvers so the
effects on the target devices are magnified.
Resource Utilization Attacks

Resource utilization attacks on DNS open resolvers consume resources on the device. Examples of such resources include CPU, memory, and socket buffers. These types of
attacks try to consume all available resources to negatively impact operations of the open resolver. The impact of these attacks may require the device to be rebooted or a
service to be stopped and restarted.
Prevent DNS Open Resolver Configurations

Multiple vendors have products that implement the DNS protocol and that can be configured as a DNS open resolver intentionally or unintentionally. A configured open resolver
exposed to the Internet allow s anyone to send DNS queries to the resolver. The examples that follow are configurations for some vendor products that are broadly deployed
throughout the Internet. These example configurations show how to prevent a DNS server from acting as an open resolver.
Berkeley Internet Nam e Dom ain

Berkeley Internet Name Domain (BIND), a softw are product of Internet Systems Consortium, Inc., implements the DNS protocol that is discussed in this document. The follow ing
configurations can be applied to BIND so that the DNS server is prevented from acting as an open resolver. These configurations are applied in the 'named.conf' configuration
file.
Note: Recursion is enabled by default for Version 9.5 of the BIND softw are and prior. BIND also allow s operators to define view s that can use the follow ing configuration
methods for disabling recursion. View s are not discussed in this document.
Note: The example configurations for BIND w ill use version 9.5.
1. Disable Recursion
// Disable recursion for the DNS service
//
options {
options {
recursion no;
};
2. Permit Recursion from Trusted Sources

// Permit recursive DNS queries for DNS messages with source
// addresses in the 192.168.1.0/24 netblock
//
options {
allow-recursion {192.168.1.0/24;};
};
3. Permit Queries from Trusted Sources

// Permit DNS queries for DNS messages with source addresses
// in the 192.168.1.0/24 netblock. The 'allow-query-cache'
// options configuration can also be used to limit the IP
// addresses permitted to obtain answers from the cache of
// the DNS server.
//
// Note: The function of 'allow-query-cache' changed between
// BIND version 9.4 and 9.4.1. Additional information about
// using this options configuration can be found in the BIND
// 9.5 Administrator Reference Manual (ARM).
//
options {
allow-query {192.168.1.0/24;};
};
4. Permit and Deny Recursion Using an ACL

// Create an Access List (ACL) defined as 'recursive-permit'
// that will permit devices in the ACL to use the DNS server
// for recursive DNS queries.
//
acl recursive-permit {
192.168.1.0/24; 10.0.1.0/24; 172.16.1.0/24; 172.31.1.0/24;
};
// Create an Access List (ACL) defined as 'rfc5735-deny' that

// will deny devices in the ACL from using the DNS server for
// recursive DNS queries.
//
acl rfc5735-deny {
0.0.0.0/8; 10.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12;
192.0.0.0/24; 192.0.2.0/24; 192.88.99.0/24; 192.168.0.0/16;
198.18.0.0/15; 198.51.100.0/24; 203.0.113.0/24; 224.0.0.0/4;
240.0.0.0/4;
// Apply 'recursive-permit' ACL created above to the options

// 'allow-query' or 'allow-recursion' configuration and then
// apply the 'rfc5735-deny' ACL created above to the 'blackhole'
// configuration.
options {
// Output Truncated.
allow-recursion { recursive-permit; };
allow-query { recursive-permit; };
// Output Truncated.
blackhole { rfc5735-deny; };
};
// The 'blackhole' options configuration can be used to prevent

// the DNS server from accepting queries for IP addresses that
// are explicitly configured or defined in an ACL. This option
// will also prevent the DNS server from using devices defined
// in the ACL for resolving queries. The 'blackhole' option may
// also be used to prevent the DNS server from sending queries
// to known malicious DNS servers.
Other configuration options for BIND are available for limiting how devices can obtain answ ers to recursive DNS messages. Operators can use the 'allow -recursion-on'
configuration option to select w hich addresses on the DNS server w ill accept recursive DNS queries. BIND also allow s operators the ability to select w hich addresses on the
DNS server w ill provide answ ers from the DNS cache using the 'allow -query-cache-on' configuration option. Operators may also configure BIND to only listen on specific
interfaces using the 'listen-on' or 'listen-on-v6' options configuration. For additional configuration options, consult the BIND 9.5 Administrator Reference Manual that can be used
to secure BIND.
Note: Team Cymru also provides a Secure BIND Template that operators can use as a guide for hardening their DNS servers.
DNS Server Service

The DNS Server service is a softw are product provided by Microsoft Corporation that implements the DNS protocol. The follow ing configurations can be applied to the DNS
Server service to prevent the server from acting as an open resolver. These configurations are applied to the DNS Server service either through the Window s user interface
(UI) or from the command-line (CLI).
DNS Server service: Disable Recursion using Window s User Interface

The follow ing steps provide information on how to disable recursion for the DNS Server service using the Window s User Interface (UI).
1. Open DNS using the follow ing procedure:
Left-click on Start
Left-click on Control Panel
Double-click Administrative Tools
Double-click DNS
2. Within the console tree, right-click the DNS server that recursion w ill be disabled for and then select Properties.
3. Next, left-click the Advanced tab.
4. Within Server options, select the Disable recursion check box and then left-click on OK.
DNS Server service: Disable Recursion using Window s Com m and-Line

The follow ing example provides information on how to disable recursion for the DNS Server service using the Window s Command-Line) CLI.
1. Open a Command Prompt using the follow ing procedure:
Left-click on Start
Left-click on Run
The Run dialog box will appear
Type cmd in the text box to the right of "Open:"
2. At the Com m and Prom pt, issue the follow ing command:
DnsCmd ServerName /Config /NoRecursion {1|0}
DnsCm d: This is the name of the tool used from the CLI to perform administrative tasks for the DNS Server service.
/Config: Specifies that the argument for the DnsCmd command applies to the configuration of the DNS Server service.
/NoRecursion: Specifies that an argument of 1 or 0 w ill follow to disable or enable recursion for the DNS Server service.
{1|0} This is the name of the tool used from the CLI to perform administrative tasks for the DNS Server service.
Using either of the previous configuration examples for the DNS Server service w ill disable recursion for all resolvers sending recursive DNS queries to the server. If recursion
is disabled, operators w ill not be able to use DNS forw arders on that server.
Microsoft provides additional information operators can use to harden the configuration of the DNS Server service. More information is available in the Securing the DNS Server
service or Security Information for DNS documentation.
Microsoft Window s also provides a feature called DNS Server Secure Cache Against Pollution that ignores the RRs in DNS response messages received from a non-
authoritative server. Note that this feature is enabled by default on Window s 2000 Service Pack 3 (SP3) and Window s Server 2003, and that using this feature w ill also
produce more queries sent from the DNS server.
Random ization for DNS Transaction Identifier

DNS uses transaction IDs (TXID) for tracking queries and responses to queries. The DNS transaction ID is a 16-bit field in the Header section of a DNS message. DNS
implementations use the transaction ID along w ith the source port value to synchronize the responses to previously sent query messages. Flaw s have been discovered in DNS
w here the implementations do not provide sufficient entropy in the randomization of DNS transaction IDs w hen issuing queries. Attackers analyze the transaction ID values
generated by the DNS implementation to create an algorithm that can be used to predict the next DNS transaction ID used for a query message. If attackers are able to predict
the next transaction ID used in the DNS query along w ith source port value, they can construct and send (spoof) DNS messages w ith the correct transaction ID. Even though
the DNS message sent by the attacker is falsified, the DNS resolver accepts the query response because the transaction ID and source port value match up w ith the query the
resolver sent, resulting in the DNS resolvers cache being poisoned.
Note: The transaction ID field for the DNS protocol is only 16 bits in length, so this value can range from 0 through 65535.
During the configuration of BIND for Unix and Linux based systems, it is recommended that operators use /dev/random w ith the --w ith-random dev=PATH argument to the
configure script. /dev/random is a special file used for generating random numbers, also know n as random number generator (RNG) or pseudorandom number generator
(PRNG). Other operating system implementations of /dev/random are different and operators should consult the vendors operating system documentation for details on its
implementation. /dev/random is recommended because it creates an entropy pool (a group of random bits stored in one place) for generating unpredictable random numbers.
Once the bits have been depleted from the entropy pool, a new pool w ill be created containing random bits. Using /dev/random w ill assist BIND in generating random DNS
transaction IDs.
Use /dev/random When Configuring BIND

[user@server ~/bind-9.5.0]$
[user@server ~/bind-9.5.0]$ ./configure --with-randomdev=/dev/random
.....<configuration output truncated>.....
[user@server ~/bind-9.5.0]$
UDP Source Port Random ization in BIND

DNS uses both the source port value and transaction ID for tracking queries and the responses to queries. Flaw s have been discovered in DNS w here the implementations do
not provide sufficient entropy in the randomization of the UDP source port w hen issuing queries. Malicious users can analyze the source port values generated by the DNS
implementation to create an algorithm that can be used to predict the next UDP source port value used for a query message. If the next UDP source port value used in the DNS
query along w ith the transaction ID can be predicted, an attacker can construct and send spoofed DNS messages w ith the correct UDP source port. Even though the DNS
message sent by the attacker is falsified, the DNS resolver accepts the query response because the UDP source port value and the DNS transaction ID match up w ith the
query the resolver sent, resulting in the DNS resolvers cached being poisoned.
Note: The source port field for the UDP protocol is only 16 bits in length, so this value can range from 0 through 65535.
The follow ing configurations can be applied to BIND so the DNS server w ill randomize the UDP source port for DNS messages. To use these configurations, apply them to the
options section in the 'named.conf' configuration file.
Configuration UDP Source Port Randomization
// The 'query-source' and 'query-source-v6' configurations
// option allows the operator to select the interface(s)
// and UDP source port value used for sending DNS queries.
// If a value of '*' is used for the source port, then a
// port will be used from pool of random unprivileged ports.
// Query port pools are used by default unless a port value
// is explicitly configured.
//
options {
query-source address * port *;
query-source-v6 address * port *;
// Additional configuration options are available for UDP

// source port randomization. This is achieved through the
// "queryport" options added to version 9.5 of BIND.
// * use-queryport-pool: Enabled by default unless the
// port value is explicitly configured for the query-
// source or query-source-v6 options configuration.
// * queryport-pool-ports: Defines how many random ports
// the pool will contain. The default is 8 ports.
// * queryport-pool-updateinterval: Defines in minutes
// when the query port pool will be recreated (select
// a new group of random unprivileged ports). The
// default is 15 minutes.
//
// By increasing the number of ports allocated to the query
// port pool, it will be harder for malicious users to predict
// the next UDP source port used in DNS queries. Operators
// may also decrease the time interval for the recreation of
// query port pool, thus allowing for random ports to be
// selected in shorter intervals and making predictability
// of source port values harder to determine.
//
// Note: Operators should test any non-default changes prior
// to deploying to production environments.
queryport-pool-ports <number>;
queryport-pool-updateinterval <number>;
};
Maliciously Abusing Resource Record Tim e To Live

When a DNS resolver sends a query asking for information, an authoritative or a non-authoritative server may respond w ith a DNS query response message and the relevant
resource record (RR) data or an error. The RR contains a 32-bit Time To Live (TTL) field used to inform the resolver how long the RR may be cached until the resolver needs to
send a DNS query asking for the information again. This field can be used maliciously by setting the value for an RR to a short or long TTL value.. By using a short TTL value,
malicious users can leverage DNS to distribute information about a large number of devices hosting malicious code or being used for malicious activities to DNS resolvers. The
hostname to IP address mapping for devices in the requested domain name space w ill rapidly change (usually anyw here from several seconds to a few minutes). This is
know n as a Fast-Flux (FF) netw ork. Abusing the TTL value using this technique for an RR in a DNS query response messages is know n as Single-Flux. This malicious
technique makes it difficult for operators to use traceback methods and identify compromised hosts participating in the Fast-Flux netw ork.
Another multifaceted technique used by attackers is to rapidly change hostname to IP address mappings for both DNS A (address) RRs and DNS NS (name server) RRs,
creating a Double-Flux (DF) netw ork.
Additional information about Fast-Flux is available in Know Your Enemy: Fast-Flux Service Netw orks.
Another potentially malicious use of a short TTL is using a value of 0. This value informs the DNS resolver that the RR information received in the DNS query response message
should not be stored in the cache of the resolver.
Note: DNS SOA RRs are alw ays distributed to resolvers w ith a TTL value of 0.
Attackers can also use long TTL values for RRs so that DNS resolvers w ill cache the information received in the query response message for an extended period of time. This
technique can be used for storing malicious RR information in the cache of a resolver for an extended period of time. If the resolver is a recursive or open resolver, then it can
distribute the RRs for the malicious host to many resolver clients, thus allow ing use for malicious activities. This method differs from the Fast-Flux technique that uses a short
TTL value and operators are able to use traceback techniques to more easily identify malicious hosts distributing this information.
To prevent a DNS server from storing RR information in the cache of the resolver for the value of the TTL received in the DNS query response message, the follow ing options
configurations can be used for BIND.
Maximum Cache Length for RRs

// The 'max-cache-ttl' configurations option allows the
// operator to define the amount of time the DNS server
// will store RR information in the resolver cache.
//
// Note: Operators should test any non-default changes
// prior to deploying to production environments.
options {
max-cache-ttl <number>;
};
Maximum Cache Size

// The 'max-cache-size' configurations option allows the
// operator to define the amount memory a DNS server will
// use for storing RR information in the resolver cache.
// When data stored in cache has reached the configured
// memory limit, BIND will purge RR information from the
// cache to store new RR information.
//
// Note: If this options configuration is set to a low
// value, it may cause the DNS server to issue queries
// more often since entries stored in the cache will be
// purged quicker. This is dependent on the amount of
// queries the DNS server processes.
//
// Note: Operators should test any non-default changes prior
// to deploying to production environments.
options {
max-cache-size <number>;
};
Segregating Authoritative and Recursive Resolvers

Authoritative and recursive resolvers have different primary functions. An authoritative DNS server distributes information to DNS resolvers for authorative domain name
space. A recursive resolver recursively w alks through the DNS architecture and locates the authoritative DNS server for the information in the DNS query (question asked),
then distributes an answ er or error for that information using a DNS query response message to the resolver w ho asked the question.
Because the functions of these resolvers are used for different purposes, the resolvers should be segregated.
Authoritative DNS servers should be used only for responding to queries for domain name space for w hich the server is administrative. Queries from anyone (queries
source from the Internet) may be allow ed for information w e know (authoritative RRs).
Recursive DNS servers should be used only for responding to queries from DNS resolvers inside its administrative domain. Queries from know n sources (clients inside your
administrative domain) may be allow ed for information w e do not know (for example, for domain name space outside our administrative domain).
Authoratative and recursive resolver functions should be segregated because authoritative DNS servers primarily distribute information about hosts accessible via the Internet
and they are also accessible via the Internet for distributing this information. By combining these resolver functions on a single DNS server and allow ing the server to be
accessible via the Internet, malicious users could employ the authoritative DNS server in amplification attacks or easily poison the DNS cache. A recursive DNS resolver must be
protected from the Internet and only trusted sources should be able to send DNS queries. One approach for controlling w hat DNS queries are permitted to exit the netw ork
under an operators control is to only allow DNS queries sourced from the internal recursive DNS resolvers.
Dom ain Nam e System Security Extensions

DNS Security Extensions (DNSSEC) adds security functions to the DNS protocol that can be used to prevent some of the attacks discussed in this document such as DNS
cache poisoning. DNSSEC adds data origin authentication and data integrity to the DNS protocol. DNSSEC specifications, implementation, and operational information is defined in
multiple RFCs.
RFC4033: DNS Security Introduction and Requirements

RFC4034: Resource Records for the DNS Security Extensions
RFC4035: Protocol Modifications for the DNS Security Extensions
RFC5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
RFC4310: Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
RFC4641: DNSSEC Operational Practices
Protections for Spoofing

The DNS protocol leverages the User Datagram Protocol (UDP) for the majority of its operations. UDP is a connectionless protocol and, as such, it can be easily spoofed. Many
of the attacks described in this document rely on spoofing to be successful.
Several security controls can be implemented to limit spoofing. These controls are described in the follow ing sections.
Unicast Reverse Path Forw arding

Unicast Reverse Path Forw arding (Unicast RPF) is a feature that can reduce the effectiveness of packets w ith spoofed source addresses. A netw ork device using Unicast
RPF evaluates the source of each IP packet against its local routing table in order to determine source address validity. While it can detect and filter some spoofed traffic,
Unicast RPF does not provide complete protection against spoofing because spoofed and valid packets w ith the same source address may arrive on the same interface.
Unicast RPF operates in tw o modes: strict and loose. In strict mode, the Unicast RPF feature uses the local routing table to determine if the source address w ithin a packet is
reachable through the interface on w hich the packet w as received. If it is reachable, the packet is permitted; if it w as not, the packet is dropped. Strict mode Unicast RPF is best
deployed on netw ork boundaries w here traffic asymmetry is not prevalent.
Strict mode Unicast RPF is enabled on Cisco IOS devices using the interface configuration command ip verify unicast source reachable-via rx; the previous format of this
command w as ip verify unicast reverse-path. Strict mode Unicast RPF can be enabled on the Cisco PIX, ASA, and FWSM firew alls using the ip verify reverse-path
interface interface configuration com m and.
In loose mode Unicast RPF, if the source address of a packet is reachable through any interface on the Unicast RPF enabled device, the packet is permitted. If the source
address of the IP packet is not present in the routing table, the packet is dropped. Loose mode Unicast RPF can be enabled on Cisco IOS devices using the ip verify source
reachable-via any interface configuration command; loose mode Unicast RPF is not available on Cisco PIX, ASA or FWSM firew alls.
More information about Unicast RPF is available in the Applied Intelligence Understanding Unicast Reverse Path Forw arding w hite paper.
IP Source Guard
IP source guard is a Layer 2 security feature that builds upon Unicast RPF and DHCP snooping to filter spoofed traffic on individual sw itch ports. DHCP snooping, w hich is a
prerequisite of IP source guard, inspects DHCP traffic w ithin a VLAN to understand w hich IP addresses have been assigned to w hich netw ork devices on w hich physical
sw itch port. Once this information has been gathered and stored in the DHCP snooping bindings table, IP source guard is able to leverage it to filter IP packets received by a
netw ork device. If a packet is received w ith a source address that does not match the DHCP snooping bindings table, the packet is dropped.
The implementation of IP source guard w ithin the access layer of a netw ork can effectively eliminate the origination of spoofed IP traffic. How ever, because it requires DHCP to
remain manageable, it is not possible to deploy IP source guard on internal-to-external netw ork boundaries.
The follow ing example illustrates the configuration of IP source guard on interface FastEthernet 0/10 w hich has been assigned to VLAN 100:
!
! Enable DHCP snooping on VLAN 100
!
ip dhcp snooping
ip dhcp snooping vlan 100
!
! Enable IP source guard on FastEthernet 0/10
!
interface FastEthernet 0/10
switchport
switchport mode access
switchport access vlan 100
ip verify source
!
See Configuring DHCP Features and IP Source Guard for more information on IP source guard.
Access Control Lists

Manually configured Access Control Lists (ACLs) can provide static anti-spoofing protection against attacks that utilize unused or untrusted address space. Commonly, these
anti-spoofing ACLs are applied to interfaces in the ingress direction for traffic received at netw ork boundaries as a component of a more comprehensive ACL. Spoofing can be
minimized in traffic originating from the local netw ork by applying ACLs that use Access Control Entries (ACEs) w hich limit the traffic to only valid local addresses.
The example that follow s demonstrates how ACLs can be used in order to limit IP spoofing. The ACL is applied inbound on the desired interface. The ACEs that make up this
ACL are not comprehensive. If you configure these types of ACLs, seek an up-to-date reference that is conclusive.
!
ip access-list extended ACL-ANTISPOOF-IN
deny ip 10.0.0.0 0.255.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
!
interface Ethernet 0/0
ip access-group ACL-ANTISPOOF-IN in
!
Refer to Configuring Commonly Used IP ACLs for more information on how to configure Access Control Lists.
The official list of unallocated Internet addresses is maintained by Team Cymru. Additional information about filtering unused addresses is available at the Bogon Reference
Page.
Detecting and Preventing DNS Attacks using Cisco Products and Features
The ASA, PIX, and FWSM firew all products, Cisco Intrusion Prevention System (IPS) and Cisco IOS NetFlow feature, provide capabilities to aid in identification and mitigation for
DNS related attacks. The follow ing subsections provide an overview of how each device or feature can be utilized.
Cisco ASA and FWSM firew alls

The Cisco ASA, PIX and FWSM Firew alls have several features that can be utilized to minimize attacks against the DNS protocol. The follow ing subsections w ill provide an
overview of these features and the capabilities they can provide.
Attack Mitigation Capabilities:

Query and Response Verification
DNS cache poisoning attacks commonly use multiple responses to each query as the attacker attempts to predict or brute force the transaction ID and the UDP source port to
corrupt the DNS cache. The DNS guard function inspects and tears dow n an existing DNS connection associated w ith a DNS query as soon as the first DNS response
message is received and forw arded by the firew all. The firew all also monitors the message exchange to ensure that the transaction ID of the DNS reply matches the
transaction ID of the initial DNS query. For the firew all to successfully mitigate cache poisoning attacks, both the initial DNS query and the subsequent non-malicious DNS
response w ill need to transit the firew all. In the unlikely occurrence that the malicious DNS response arrives first and w ith the correct transaction ID, then the firew all is unable
to prevent DNS cache poisoning type attacks.
Enabling DNS guard through either the command line DNS Guard function or DNS application inspection provides preventive controls against DNS cache poisoning attacks. This
feature is enabled by default and is available on Cisco ASA, Cisco PIX and Cisco FWSM Firew alls.
Transaction ID random ization
Some DNS implementations use a w eak randomization algorithm to generate DNS transaction IDs for DNS query messages. This makes these implementations prone to cache
poisoning and spoofing attacks. The id-random ization parameters submode command for policy-m ap type inspect dns can be used to randomize the DNS transaction ID
for a DNS query. This function w ill harden DNS implementations w ith w eak randomization algorithms.
This feature is available beginning w ith softw are release 7.2(1) for Cisco ASA and Cisco PIX Firew alls. This function is disabled by default on the ASA and PIX firew alls. This
feature is not supported on the FWSM firew alls.
DNS Header Flag Filtering

DNS cache poisoning attacks use DNS open resolvers w hen attempting to corrupt the DNS cache of vulnerable resolvers. The DNS messages sent to open resolvers set the
recursion desired (RD) flag in the DNS header. Utilizing the DNS application inspection flag filtering feature, these attacks can be minimized by dropping DNS messages w ith the
RD flag present in the DNS header.
This feature is available beginning w ith softw are release 7.2(1) for Cisco ASA and Cisco PIX 500 Firew alls. This function is not available on FWSM Firew alls. This function is
disabled by default.
DNS m essage size lim itations

DNS amplification and reflection attacks are more effective w hen leveraging large DNS messages than small DNS message sizes. The m essage-length parameters submode
command for policy-m ap type inspect dns can be used to ensure that message sizes to not exceed a specified size thus reducing the efficiency of these attacks.
This feature is available beginning w ith softw are release 7.2(1) for Cisco ASA and Cisco PIX Firew alls. This feature is available beginning w ith softw are release 3.1 for FWSM
Firew alls. This function is enabled by default w ith a limit of 512 bytes.
Note: Although use of this command does reduce the possibility of being a victim of a DNS Amplification Denial of Service attack, it is more likely to prevent the DNS server from
used as part of the source of a DNS Amplification attack.
Feature Overview
DNS Guard
Beginning w ith softw are release 7.0(5) for Cisco ASA 5500 Series and Cisco PIX 500 Series, and softw are release 4.0 for the FWSM the DNS guard function can be controlled
through the dns-guard global configuration or the dns-guard parameters submode command for policy-map type inspect dns. For Cisco ASA 5500 and Cisco PIX 500 Firew alls
that are running releases prior to 7.0(5) and for the FWSM Firew all releases prior to 4.0, the DNS guard function is alw ays enabled, and it cannot be configured through this
command. The configuration of this feature, w hen configurable, w ill be detailed later in the feature configuration section.
DNS Application Inspection

Application layer protocol inspection is available beginning in softw are release 7.0 for the Cisco ASA 5500 and Cisco PIX 500 Series Firew alls and in softw are release 3.1 for
the FWSM Firew all. Configuration of DNS application inspection capabilities w ill be detailed later in the feature configuration section of this document.
Caution: Application layer protocol inspection w ill decrease firew all performance. This feature should be tested in a lab environment before deployment in production
environments.
Feature Configuration
DNS Guard Configuration
To determine w hether the DNS guard function is enabled globally, look for the follow ing string in the firew all configuration for softw are releases 7.0(5) and later for Cisco ASA
5500 Series and Cisco PIX 500 Series appliances:
firewall# show running-config dns-guard

dns-guard
firewall#
If the DNS guard function has been disabled globally, it can be re-enabled using the follow ing commands for softw are releases 7.0(5) and later for Cisco ASA 5500 Series and
Cisco PIX 500 Series appliances:
firewall# configure terminal

firewall(config)# dns-guard
firewall(config)# exit
firewall#
In softw are releases 7.2(1) and later for the Cisco ASA 5500 Series and Cisco PIX 500 Series appliances, administrators can enable DNS guard functionality through DNS
application inspection and the Modular Policy Framew ork (MPF). Configuration of DNS Guard through DNS application inspection and MPF w ill be demonstrated in the follow ing
DNS application inspection configuration section.
DNS Application Inspection Configuration
DNS application inspection utilizes the Modular Policy Framew ork (MPF) for configuration. To configure application inspection, administrators may construct an inspection policy
through the configuration of inspect class maps and inspect policy maps, w hich are applied via a global or an interface service policy. The follow ing example demonstrates
configuration of this feature.
Additional information about DNS application inspection and the Modular Policy Framew ork is available in How DNS Application Inspection Works.
Additional information about application layer protocol inspection is available in Configuring Application Layer Protocol Inspection.
!
class-map inspection_default
match default-inspection-traffic
!
policy-map type inspect dns preset_dns_map
parameters
!
!-- Enable dns-guard to verify that DNS query and
!-- response transaction IDs match and only one DNS
!-- response is allowed through the firewall for
!-- each query.
!
dns-guard
!
!-- Enable id-randomization to generate unpredictable
!-- DNS transaction IDs in DNS messages and protect
!-- DNS servers and resolvers with poor randomization
!-- of DNS transaction IDs.
!
id-randomization
!
!-- Enable a maximum message length to help defeat DNS
!-- amplification attacks. Note: This is the default
!-- configuration and value based on RFC 1035.
!
message-length maximum 512
!
!-- Enable id-mismatch to count DNS transaction ID
!-- mismatches within a specified period of time
!-- and generate a syslog when the defined threshold
!-- has been reached.
!
id-mismatch count 10 duration 2 action log
exit
!
!-- Check for DNS query messages with the recursion
!-- desired (RD) flag set in the DNS header and drop
!-- those packets to avoid being used as a recursive
!-- resolver.
match header-flag RD
drop
!
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
-- CLI Output Truncated --
!
service-policy global_policy global
!
DNS Attack Identification

DNS Service Policy Identification
When the DNS guard, DNS ID randomization, DNS ID mismatch, and DNS protocol enforcement functions for the DNS application inspection feature are enabled, the show
service-policy inspect command w ill identify the number of DNS packets inspected or dropped by these functions and this feature. Example output for show service-policy
inspect dns follow s
!-- Output for service-policy applied globally

!
firewall# show service-policy inspect dns
Global policy:
Service-policy: global_policy
Class-map: inspection_default
Inspect: dns preset_dns_map, packet 37841, drop 0, reset-drop 0
message-length maximum 512, drop 0
dns-guard, count 21691
protocol-enforcement, drop 0
nat-rewrite, count 0
id-randomization, count 21856
id-mismatch count 10 duration 2, log 2
firewall#
!-- Output for service-policy applied per interface

!
firewall# show service-policy inspect dns
Interface outside:
dns-guard, count 2147
Interface inside:
dns-guard, count 88
firewall#
Syslog Identification
In the follow ing example, the show logging | grep regex command extracts syslog messages from the logging buffer on the firew all. These messages provide additional
information about denied packets. It is possible to use different regular expressions w ith the grep keyw ord to search for specific data in the logged messages.
Firew all syslog message 410002 w ill be generated w hen the firew all detects a high rate of DNS responses w ith a mismatched DNS transaction ID. The threshold for this
function is set by the id-m ism atch parameters submode command for policy-map type inspect dns. Additional information about this syslog message is available in Cisco
Security Appliance System Log Message - 410002.
Firew all syslog message 106007 w ill be generated w hen the firew all detects that a DNS response message has already been received for a DNS query message and the
connection entry has been torn dow n by the DNS guard function. This syslog message indicates that the DNS response message received has been denied. Additional
information about this syslog message is available in Cisco Security Appliance System Log Message - 106007.
Additional information about regular expression syntax is available in Using the Command Line Interface.
firewall#Ashow logging | grep (106007|410002)

Mar 31 2008 00:29:18: %ASA-2-410002: Dropped 189 DNS responses with
mis-matched id in the past 10 second(s): from outside:192.0.2.2/3917
to inside:192.168.60.1/53
Mar 31 2008 00:29:13: %ASA-2-106007: Deny inbound UDP from 192.0.2.2/2875
to 192.168.60.1/53 due to DNS Response.
firewall#
For additional information about investigating incidents using syslog events, reference the Identifying Incidents Using Firew all and IOS Router Syslog Events Applied Intelligence
w hite paper.
Information about configuring syslog for the Cisco ASA 5500 Series Adaptive Security Appliance or the Cisco PIX 500 Series Security Appliance is available in Configuring
Logging on the Cisco Security Appliance. Information about configuring syslog on the FWSM for Cisco Catalyst 6500 Series sw itches and Cisco 7600 Series routers is available
in Configuring Monitoring and Logging on the Cisco FWSM.
Accelerated Security Path Identification

The show asp drop fram e command can identify the number of DNS packets that the DNS guard function (w ith the counter name inspect-dns-id-not-m atched) has
dropped because the transaction ID in the DNS response message does not match any transaction IDs for DNS queries that have passed across the firew all earlier on the
same connection. As show n in the follow ing example, the counter inspect-dns-id-not-m atched is represented in the command output as DNS Inspect id not matched:
firewall#show asp drop frame

DNS Inspect id not matched 182
Flow is denied by configured rule 855
Expired flow 1
Interface is down 2
firewall#
In the preceding example, the DNS guard function has dropped 182 DNS response message packets due to an incorrect DNS transaction ID or a DNS response message w ith
the correct transaction ID has already been received.
For additional information about debugging accelerated security path (ASP) dropped packets or connections, reference the Cisco Security Appliance Command Reference for
show asp drop.
Cisco IPS
The Cisco IPS provides several signatures to detect application specific vulnerabilities such as buffer overflow vulnerabilities as w ell as informational DNS signatures that may
be indicative of reconnaissance or probing. In addition to these application specific signatures, anomaly-based signatures can provide coverage for vulnerabilities such as
amplification attacks or cache poisoning, w here the rate of DNS transactions are likely to vary significantly.
The follow ing table lists the DNS specific signatures provided on the Cisco IPS appliance w ith signature pack S343.
Table 1. DNS-Specific Signatures Provided on the Cisco IPS Appliance w ith Signature Pack S343
Signature ID/ Default Enabled Severity Fidelity Signature Nam e

Sub Sig Status
6050/0 No Low 100 DNS HINFO

Request
6050/ No Low 100 DNS HINFO

Request
6051/0 No Info 100 DNS Zone

Transfer
6051/1 No Info 100 DNS Zone

Transfer
6052/0 No Med 100 DNS Zone

Transfer from
High Port
6052/1 No Med 100 DNS Zone

Transfer from
High Port
6053/0 Yes Info 100 DNS Request for

all records
6053/1 Yes Info 100 DNS Request for

all records
6054/0 Yes Low 100 DNS version

request
6054/1 Yes Low 100 DNS version

request
6055/0 Yes High 100 DNS inverse

query buffer
overflow

query buffer
overflow

query buffer
overflow
6056/0 Yes High 100 DNS NXT Buffer

Overflow

Overflow

Overflow
6057/0 Yes High 100 DNS SIG Buffer
Overflow

Overflow

Overflow
6058/0 Yes High 100 DNS SRV Dos
6058/1 Yes High 100 DNS SRV Dos
6059/0 Yes High 100 DNS TSIG

Overflow
6059/1 Yes High 100 DNS TSIG

Overflow
6060/0 Yes High 100 DNS Complain

overflow

overflow

overflow
6061/0 Yes Med 100 DNS InfoLeak
6061/1 Yes Med 100 DNS InfoLeak
6062/0 Yes Low 100 DNS Authors

Request
6062/1 Yes Low 100 DNS Authors

Request
6063/0 Yes Info 100 DNS Incremental

Zone Transfer
6063/1 Yes Info 100 DNS Incremental

Zone Transfer
6064/0 Yes Low 100 Bind Large OPT

Record DoS
6065/0 Yes High 100 DNS Query Name
Loop DoS
6066/0 Yes Med 100 DNS Tunneling
6067/0 Yes Low 100 DNS TSIG

BugTraq
Overflow
The follow ing IPS Signatures provide rate based or anomaly detection and are useful in identifying attacks that cause a change in the rate or profile of the DNS traffic (such as
amplification or cache poisoning attacks). In many cases, these signatures may require baselining and tuning to accurately detect attacks. For example, administrators could
choose to use an event action filter to monitor for traffic destined to only the DNS servers, or only port 53. Additionally, once signatures have been enabled, baselined or
tuned, the signatures must be set to a high enough severity to cause incident response personnel to become involved. IPS Signature 4004/0 (Signature Name: DNS Flood
Attack) can be specifically used to detect potential DNS Cache Poisoning, Reflection, or Amplification attacks.
Table 2. Rate-based or Anom oly Detection Signatures
Signature ID/ Default Severity Fidelity Signature

Sub Sig Enabled Status Nam e
4004/0 Yes Medium 85 DNS Flood

Attack
4002/0 No Low 75 UDP Host Flood
13001/0 Yes High 100 AD-Internal UDP

scanner
13001/1 Yes High 100 AD-Internal UDP

scanner
13004/0 Yes High 100 AD-External

UDP Scanner
13004/1 Yes High 100 AD-External

UDP Scanner
Cisco IOS NetFlow

Administrators can configure Cisco IOS NetFlow on Cisco IOS routers and sw itches to aid in the identification of traffic flow s that may be attempts to exploit these DNS
implementation flaw s. In general, the follow ing traffic profiles w ill be associated w ith these types of attacks; how ever it is important to note, that depending on NetFlow
monitoring location, Netw ork or Port address translation (NAT or PAT) and other variables that these are not absolutes. Administrators should consider these as guidelines and
evaluate these events in the context of their netw ork to determine if these events represent malicious activities. The follow ing guidelines assume no Port Address Translation
(PAT).
When NetFlow records are displayed on an IOS device or exported to an offline collection system used for traffic analysis or anomaly detection, the follow ing traffic profiles
can be used to classify potential DNS attacks.
DNS Spoofing Attack: A high rate of DNS traffic w ith a source port of 53 (attacker) destined to an unprivileged port (above 1024) for a DNS resolver (attack target).
DNS Cache Poisoning Attack: A high rate of DNS traffic w ith a source port of 53 (attacker) destined to a DNS server on your netw ork (attack target).
DNS Am plification or Reflection Attack: A high rate of DNS response traffic, from multiple sources, w ith a source port of 53 (attackers) destined to your netw ork (attack
target). These are likely to use large DNS packets to increase their efficiency; how ever large packets are not a requirement.
Note: The source addresses of the DNS servers used in this attack scenario are typically DNS open resolvers.
DNS Am plification or Reflection Attack Source: A high rate of DNS traffic from your DNS server w ith a source port of 53 (attacker) destined to other netw orks (attack
targets). These are likely to use large DNS packets to increase their efficiency; how ever large packets are not a requirement.
Note: This may indicate that your DNS server is configured as a DNS open resolver. Several configuration examples are available in the Prevent DNS Open Resolver
Configurations above to prevent or restrict your server from responding to recursive DNS queries.
router#show ip cache flow

IP packet size distribution (158814397 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .414 .091 .015 .032 .024 .018 .004 .010 .001 .003 .002 .002 .005 .007
512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.015 .001 .206 .066 .073 .000 .000 .000 .000 .000 .000
IP Flow Switching Cache, 4456704 bytes

17 active, 65519 inactive, 8207878 added
157342957 ager polls, 0 flow alloc failures
Active flows timeout in 2 minutes
Inactive flows timeout in 60 seconds
IP Sub Flow Cache, 336520 bytes
0 active, 16384 inactive, 3108972 added, 3108972 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 15898 0.0 28 45 0.1 8.9 30.8
TCP-FTP 792 0.0 9 59 0.0 25.3 21.0
TCP-FTPD 262 0.0 2362 493 0.1 15.1 21.0
TCP-WWW 77625 0.0 14 570 0.2 10.1 38.5
TCP-SMTP 1620 0.0 7 127 0.0 7.0 10.7
TCP-X 4 0.0 1 46 0.0 0.0 60.6
TCP-BGP 1688 0.0 3 44 0.0 13.9 60.6
TCP-NNTP 4 0.0 1 46 0.0 0.0 60.5
TCP-other 6183829 1.4 23 318 33.8 2.3 7.5
UDP-DNS 96765 0.0 5 71 0.1 37.6 43.6
UDP-NTP 486955 0.1 1 76 0.1 5.2 58.4
UDP-TFTP 491 0.0 1 76 0.0 0.5 59.5
UDP-Frag 301039 0.0 6 569 0.4 0.0 15.6
UDP-other 923777 0.2 8 382 1.7 8.9 22.8
ICMP 109260 0.0 3 125 0.0 23.7 52.5
IGMP 10 0.0 2 20 0.0 7.5 60.9
IPINIP 12 0.0 2 20 0.0 1.1 60.8
IPv6INIP 19 0.0 3 75 0.0 0.9 60.9
GRE 4952 0.0 47 52 0.0 119.3 0.9
IP-other 2828 0.0 2 37 0.0 6.7 59.4
Total: 8207830 1.9 19 323 36.9 4.0 13.9
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts

Gi0/0 192.168.2.6 Gi0/1 192.168.150.70 11 80ED 0035 1
Gi0/0 10.89.16.197 Gi0/1 192.168.150.60 06 0538 0016 45
Gi0/0 10.89.16.197 Gi0/1 192.168.150.60 06 0536 0016 1
Gi0/0 10.88.226.1 Gi0/1 192.168.206.40 11 007B 007B 1
Gi0/0 192.168.5.5 Gi0/1 192.168.150.70 11 0035 0403 1
Gi0/0 192.168.208.63 Local 192.168.206.20 06 B117 0016 33
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0401 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0402 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0403 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0404 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0405 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0406 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0407 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0408 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 0409 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 040A 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 040B 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 040C 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 040D 500
Gi0/0 192.168.3.6 Gi0/1 192.168.150.70 11 0035 040E 500
router#
In the preceding example, there are multiple flow s for DNS packets on UDP port 53 (hex value 0035). In this example, the IP address 192.168.150.70 originally sent a DNS query
message (request) to the DNS server at IP address 192.168.5.5 using UDP destination port 53 (hex value 0x0035) and UDP source port 1027 (hex value 0403). The NetFlow
records indicate that IP address 192.168.5.5 responded w ith one legitimate DNS response message, how ever IP address 192.168.3.6 returned multiple DNS response
messages at the same time w ith incrementing UDP destination ports and a UDP source port value of 53 (hex value 0x0035). It is likely, given this example that the IP address
192.168.3.6 w as attempting to return falsified RR information and poison the DNS cache of the server at IP address 192.168.150.70. Administrators should compare these
flow s to baseline utilization for DNS traffic on UDP port 53 and also investigate the flow s to determine w hether they are potential malicious attempts to abuse flaw s in
implementations of the DNS protocol.
To view only the traffic flow s for DNS packets on UDP port 53 (hex value 0035), the command show ip cache flow | include SrcIf|_11_.*0035 w ill display the related
NetFlow records as show n here:
router#show ip cache flow | include SrcIf|_11_.*0035

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Gi0/0 192.0.2.2 Gi0/1 192.168.60.163 11 092A 0035 6
Gi0/0 192.0.2.3 Gi0/1 192.168.60.20 11 0C09 0035 1
Gi0/0 192.0.2.4 Gi0/1 192.168.60.100 11 0B66 0035 18
Gi0/0 192.0.2.1 Null 192.168.60.163 11 072A 0035 87
Gi0/0 192.0.2.5 Gi0/1 192.168.60.162 11 0914 0035 1
Gi0/0 192.0.2.6 Gi0/1 192.168.60.27 11 0B7B 0035 2
DNS Tools and Resources

Tables 3 and 4 list tools and resources that provide more information on DNS.
Table 3. Tools
Tool Nam e Location Description
DNSCAP - DNS traffic capture https://w w w .dns-oarc.net/tools/dnscap A DNS traffic capture utility that provides DNS-specific
utility functionality beyond that of tcpdump.
DSC - DNS Stats Collector https://w w w .dns-oarc.net/tools/dsc A DNS tool that creates statistical information for DNS traffic.
fpdns - DNS fingerprinting tool https://w w w .dns-oarc.net/tools/fpdns A tool used to fingerprint DNS resolvers.
dnstop http://dns.measurement-factory.com/tools/dnstop/ A tool that builds statistics based on DNS traffic seen on the
netw ork.
dnsstat http://w w w .caida.org/tools/utilities/dnsstat/ A DNS-specific tool that builds statistics based on DNS traffic
seen on the netw ork.
dig http://w w w .isc.org A pow erful command line utility for debugging and troubleshooting
DNS.
host http://w w w .isc.org A DNS lookup command line utility.
nslookup http://w w w .isc.org and is included w ith many operating systems A command line DNS lookup utility included in many operating
systems.
dnsdump http://dns.measurement-factory.com/tools/dnsdump/ A tool that w ill monitor and display DNS messages seen on the
netw ork.
dnsmap http://code.google.com/p/dnsmap/ A tool that collections all available information for a sub-domain.
TXDNS http://w w w .txdns.net/ A multithreaded Win32 tool used primarily send many DNS queries
at a time for testing DNS servers.
Open Resolver Test from The http://dns.measurement-factory.com/cgi-bin/openresolvercheck.pl/ A w eb-based tool that w ill check DNS servers to determine if they
Measurement Factory support recursion from the Internet.
dnsenum http://code.google.com/p/dnsenum/ A tool that attempts to collect all possible information available for
a domain.
Table 4. Resources
Location Description
RFC 882, DOMAIN NAMES - CONCEPTS and FACILITIES http://tools.ietf.org/html/rfc882
RFC 883, DOMAIN NAMES - IMPLEMENTATION and http://tools.ietf.org/html/rfc883

SPECIFICATION
RFC 973, Domain System Changes and Observations http://tools.ietf.org/html/rfc973
RFC 1032, DOMAIN ADMINISTRATORS GUIDE http://tools.ietf.org/html/rfc1032
RFC 1033, DOMAIN ADMINISTRATORS OPERATIONS GUIDE http://tools.ietf.org/html/rfc1033
RFC 1034, DOMAIN NAMES - CONCEPTS AND FACILITIES http://tools.ietf.org/html/rfc1034
RFC 1035, DOMAIN NAMES - IMPLEMENTATION AND http://tools.ietf.org/html/rfc1034

SPECIFICATION
Domain Name System Structure and Delegation http://tools.ietf.org/html/rfc1591
Negative Caching of DNS Queries (DNS NCACHE) http://tools.ietf.org/html/rfc2308
IAB Technical Comment on the Unique DNS Root http://tools.ietf.org/html/rfc2826
Domain Name System (DNS) IANA Considerations http://tools.ietf.org/html/rfc2929
Role of the Domain Name System (DNS) http://tools.ietf.org/html/rfc3467
RFC 3833, Threat Analysis of the Domain Name System (DNS) http://tools.ietf.org/html/rfc3833
What's in a Name: False Assumptions about DNS Names http://tools.ietf.org/html/rfc4367
Observed DNS Resolution Misbehavior http://tools.ietf.org/html/rfc4697
Use of Bit 0x20 in DNS Labels to Improve Transaction Identity http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20
Measures for making DNS more resilient against forged http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience

answ ers
Domain Name System Operations Working Group http://tools.ietf.org/w g/dnsop
DNS Extensions Working Group http://tools.ietf.org/w g/dnsext/
BIND 9 Administrator Reference Manual (ARM) http://w w w .isc.org/sw /bind/arm95/
DNS and BIND, Fifth Edition http://w w w .oreilly.com/catalog/9780596100575/
DNS Operations mailing list http://lists.oarci.net/mailman/listinfo/dns-operations
This document is part of Cisco Security Intelligence Operations.
This document is provided on an "as is" basis and does not imply any kind of guarantee or w arranty, including the w arranties of merchantability or fitness for a particular use.
Your use of the information on the document or materials linked from the document is at your ow n risk. Cisco reserves the right to change or update this document at any time.
Back to Top
Cisco Security Intelligence Operations
Information For News & Alerts Support About Cisco
Small Business New sroom Dow nloads Investor Relations
Midsize Business Blogs Documentation Corporate Social Responsibility
Service Provider Field Notices Environmental Sustainability
Communities
Executives Security Advisories Tomorrow Starts Here
Developer Netw ork
Home (Linksys) Career Opportunities
Technology Trends Learning Netw ork
Industries Cloud Support Community Programs
IPv6 Cisco Pow ered
Contacts Video Portal
Mobility Financing Options
Contact Cisco
Open Netw ork Environment
Find a Partner
Trustw orthy Systems
Contacts | Feedback | Help | Site Map | Terms & Conditions | Privacy Statement | Cookie Policy | Trademarks

WWW Cisco Com Web About Security Intelligence DNS BCP HTML

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

WWW Cisco Com Web About Security Intelligence DNS BCP HTML

Hochgeladen von

Copyright:

Verfügbare Formate

Cisco Systems, Inc.

Worldwide [change] Log In Account Register My Cisco

DNS Best Practices, Network Protections, and Attack Identification

How could this information be more

Im portant DNS Term inology

Prim ary Function of DNS

Figure 2. Recursive Query

Maliciously Abusing Implementation Flaws in DNS

DNS Open Resolvers

DNS cache poisoning attacks

Denial of Service (DoS) or Distributed DoS (DDoS)

DNS Cache Poisoning Attacks

DNS Am plification and Reflection Attacks

Resource Utilization Attacks

Prevent DNS Open Resolver Configurations

Berkeley Internet Nam e Dom ain

2. Permit Recursion from Trusted Sources

3. Permit Queries from Trusted Sources

4. Permit and Deny Recursion Using an ACL

// Create an Access List (ACL) defined as 'rfc5735-deny' that

// Apply 'recursive-permit' ACL created above to the options

// The 'blackhole' options configuration can be used to prevent

DNS Server Service

DNS Server service: Disable Recursion using Window s User Interface

1. Open DNS using the follow ing procedure:

DNS Server service: Disable Recursion using Window s Com m and-Line

1. Open a Command Prompt using the follow ing procedure:

DnsCmd ServerName /Config /NoRecursion {1|0}

Random ization for DNS Transaction Identifier

Use /dev/random When Configuring BIND

.....<configuration output truncated>.....

UDP Source Port Random ization in BIND

query-source-v6 address * port *;

// Additional configuration options are available for UDP

Maliciously Abusing Resource Record Tim e To Live

Maximum Cache Length for RRs

Maximum Cache Size

Segregating Authoritative and Recursive Resolvers

Dom ain Nam e System Security Extensions

RFC4033: DNS Security Introduction and Requirements

Protections for Spoofing

Unicast Reverse Path Forw arding

Access Control Lists

Cisco ASA and FWSM firew alls

Attack Mitigation Capabilities:

DNS Header Flag Filtering

DNS m essage size lim itations

DNS Application Inspection

firewall# show running-config dns-guard

firewall# configure terminal

DNS Application Inspection Configuration

DNS Attack Identification

!-- Output for service-policy applied globally

!-- Output for service-policy applied per interface

firewall#Ashow logging | grep (106007|410002)

Accelerated Security Path Identification

firewall#show asp drop frame

Signature ID/ Default Enabled Severity Fidelity Signature Nam e

6050/0 No Low 100 DNS HINFO

6050/ No Low 100 DNS HINFO

6051/0 No Info 100 DNS Zone

6051/1 No Info 100 DNS Zone

6052/0 No Med 100 DNS Zone