DNS resolution is generally the first step in securing access to applications, and a DNS cache is a key asset that can be exposed to a variety of attacks. If a DNS system is compromised, attackers can hijack transactions and impact DNS resources and your network infrastructure.

In this blog post, we’ll look at how Citrix ADC can help you to protect your DNS infrastructure against some well-known DNS vulnerabilities.

Cache Poisoning

To reduce the chances of an attacker successfully spoofing the response, DNS clients are expected to randomize the DNS transaction ID or query ID and the ephemeral source port used to send the DNS request. This requires the attacker to guess correctly a 32-bit integer quickly. But if a DNS client sends multiple DNS requests to the nameserver on the same UDP 4 tuple, the attacker only has to guess a 16-bit query ID (because the UDP source ephemeral port is constant) to succeed in spoofing the response.

Restrict the number of queries on the same UDP 4 tuple. Once the configured threshold is reached, Citrix ADC starts dropping the requests coming to that UDP 4 tuple. You can tune this limit on your Citrix ADC by using this command:

set dns parameter -maxPipeline <positive-integer>

Please note, setting the parameter to zero will imply there is no limit to the number of pipelined requests, so you should set the limit to an appropriate non-zero number.

You can also enable DNSSEC for the zone hosted on the Citrix ADC to mitigate cache poisoning.

Amplification Attacks

In a DNS amplification attack, the attacker uses small DNS requests to exhaust DNS server resources. This uses the DNS server’s compute resources, memory, and bandwidth and denies DNS services for legitimate application access. There are different ways to achieve DNS response amplification.

One way to protect DNS infrastructure against amplifications attacks is to whitelist or blacklist client IPs. If IP-based mitigation isn’t feasible, you can identify the attack pattern, configure the appropriate DNS policies using Citrix ADC’s policy expressions, and force the clients to reinitiate the query over TCP. Additionally, you can configure DNS endpoints on an anycast IP to protect against DDoS attacks.

Root Referral Amplification Attack

DNS authoritative servers are recommended to return root NS records in the authority section as a response to queries requesting information about a domain name that they are not authoritative for. Root NS records’ size, including the glue records, will come close to 512 bytes. This can give at least five times the amplification for an average DNS query. An attacker can use this DNS specification by sending queries to an authoritative nameserver for a domain outside of the zone for which the nameserver is authoritative.

You can mitigate this on Citrix ADC with the command below. When you disable the configuration parameter, Citrix ADC will not respond to queries for domains outside the zones for which the ADC is configured to be authoritative.

set dns parameter -dnsRootReferral DISABLED

ANY Query-Based Amplification Attack

An ANY query type returns all records for a given domain name. That means the response size is huge despite the query size being comparable to other queries. Attackers use ANY queries to perform DDoS attacks on vulnerable network infrastructure. Use the command below in your Citrix ADC to configure a rate-limiting DNS policy, with rate-limiting identifier as the DNS query type, and restrict ANY queries to a threshold the network can handle.

add stream selector dns_anyquery_amplification “dns.req.question.type.eq(ANY)”
add ns limitIdentifierdns_ampl_attack_limitid -threshold 1000 -timeSlice 10000 -selectorName
dns_anyquery_amplification
add dns policy dns_amp_attack_pol “sys.check_limit(\”dns_ampl_attack_limitid\”)”
dns_default_act_Drop
bind dns global dns_amp_attack_pol -priority 10add ns variable dns_tcp_requests -type ulong -scope transaction

NXDOMAIN-Based Amplification Attack

DNS bots can inject malicious queries for non-existent domain names. These domain names are often randomly generated. Crafting an NXDOMAIN response can be more intensive than serving a configured record for authoritative nameservers. NXDOMAIN responses in the case of DNSSEC-enabled zones can be even more resource consuming.

One common approach to mitigating NXDOMAIN-based attacks is to identify the domain pattern and drop such queries or force the client to come over TCP by sending a truncated response. Forcing the client to come over TCP is one way of ascertaining whether DNS clients are genuine. But malicious DNS bots have become more sophisticated with full TCP/IP stacks at their disposal and can respond by reinitiating the query over TCP. Ideally you would identify the pattern in domain names and configure suitable policies to drop such queries.

Citrix ADC can function as an authoritative nameserver for a DNS zone, and you can mitigate NXDOMAIN-based amplification attacks using this configuration option:

set dns parameter -NXDomainRateLimitThreshold <positive_integer>

If your Citrix ADC is configured as a DNS proxy, NXDOMAIN-leading queries will generally result in a cache miss. The back-end server will be swarmed with more queries than it can handle and will deny the service for genuine queries. When the Citrix ADC receives the NXDOMAIN response, it is cached, denying cache resource for legitimate configured records.

You can protect the DNS cache against NXDOMAIN attacks by allocating only a small portion of memory (MBs) for negative record caching and by setting the TTL of negative records to a low value (preferably a maximum 1 or 2 minutes) using this configuration

set dns parameter  -maxNegativeCacheSize 200 -maxnegcacheTTL 120

Please note, in the above sample configuration, maxNegativeCache size is given in megabytes and maxnegcacheTTL is in seconds.

DNS Tunneling

Attackers can use a DNS tunnel for command and control, data exfiltration, or tunneling of any internet protocol (IP) traffic. A DNS tunnel enables overloading of the DNS, denying the DNS resources needed to support legitimate application access.

DNS tunnel detection techniques such as payload analysis and traffic analysis can help. With payload analysis, the DNS payload for one or more requests and responses are analyzed for tunnel indicators. With traffic analysis, the traffic volume and pattern are analyzed over time. Count, frequency, and other request attributes can also be considered. You can implement detection based on payload and traffic using Citrix ADC’s rich DNS policy infrastructure.

If Citrix ADC is front-ending a farm of LDNS servers, you should apply mitigation for DNS tunneling so resources are used for only legitimate DNS use cases. The mitigation below is based on the assumption that the average length of domain names would be less than 200 bytes and DNS query payload size in legitimate use-cases would be less than 256 bytes.

add dns policy dns_tunnel_payload_1 “dns.req.question.domain.length.gt(200)”
dns_default_act_Drop
add dns policy dns_tunnel_payload_2 “dns.length.gt(256)” dns_default_act_Drop
bind dns global dns_tunnel_payload_1 20 -gotoPriorityExpression next -type REQ_DEFAULT
bind dns global dns_tunnel_payload_2 30 -gotoPriorityExpression next -type REQ_DEFAULT

TCP Slowloris Attack

An attacker can send a DNS request in chunks, and the DNS stack would wait for the complete query to come for an idle timeout period of time. However, the attacker may not send the complete data or send chunks of data with a huge delay between each chunk. This could lead to denying service to legitimate queries (by consuming the memory on nameserver to maintain the TCP connection for idle period of time and maintaining multiple query chunks). You can mitigate this attack with Citrix ADC by using the following configuration:

set dns parameter -splitPktQueryProcessing DROP

Learn More

For most well-known attacks, mitigation is available in DNS parameters. For some, you can leverage Citrix ADC’s rich policy infrastructure to inspect DNS requests and responses for anomalies and can take appropriate action to protect your DNS resources and, more generally, your network infrastructure. Citrix ADC’s policy infrastructure is an extensible framework that IT admins can leverage to implement rules for newer vulnerabilities and immediately protect your DNS infrastructure in a security environment that’s constantly changing.

To learn more about DNS policies, check out our documentation on responder policies for DNS and rewrite policies for DNS.