Technical Articles
F5 SMEs share good practice.
Showing results for 
Search instead for 
Did you mean: 


In this article, we will look at configuring BIG-IP Advanced Firewall Manager's (AFM) DNS NXDOMAIN attack type in the Device Protection and DNS enabled protection profile to mitigate DNS NXDOMAIN response floods. We will review data from a packet capture and BIG-IP DNS' DNS profile statistics to set detection and mitigation thresholds.

This is part one of two of this article series.

Part two is at

What is a NXDOMAIN dns response

The DNS protocol [RFC1035] defines response code 3 as "Name Error",
   or "NXDOMAIN" [RFC2308], which means that the queried domain name
   does not exist in the DNS.  Since domain names are represented as a   tree of labels ([RFC1034], Section 3.1), nonexistence of a node
   implies nonexistence of the entire subtree rooted at this node.


How is NXDOMAIN dns response generated

RCODE           Response code - this 4 bit field is set as part of
                responses.  The values have the following

3               Name Error - Meaningful only for
                                responses from an authoritative name
                                server, this code signifies that the
                                domain name referenced in the query does
                                not exist.

What is a NXDOMAIN (response) flood?

From the F5 Glossary in

The roadmap to every single computer on the Internet is held in DNS servers. The DNS NXDOMAIN flood attack attempts to make servers disappear from the Internet by making it impossible for clients to access the roadmap.

In this attack, the attacker floods the DNS server with requests for invalid or nonexistent records. The DNS server spends its time searching for something that doesn't exist instead of serving legitimate requests. The result is that the cache on the DNS server gets filled with bad requests, and clients can't find the servers they are looking for.

How do threat actors generate random dns queries

There are many tools to generate  a flood of DNS queries . The DNS records in the flood of DNS queries for the most part, should be unique if an attacker wants to poison a DNS servers cache. Otherwise, a DNS administrator can simply blackhole if the same DNS record is queried in DNS flood query.

DNS Blackhole

Here is a devcentral article on DNS Blackhole implemented in an iRule

Domain Generation Algorithms

To generate many random host records for one or many domains, Domain Generation Algorithms are used.

Many examples of DGA as collected in shows how these random records may look like.

In the lab setup we will be using, we have the fop789[.]loc domain, and I borrowed from the github page random host list generated thru the "mydoom (aka Novarg, Mimail.R, Shimgapi)" DGA and appended the host part of the host list to the test lab domain .





Here is a sample query using the one of the hostnames. As expected, a NXDOMAIN response is received because this record does not exist in the sample lab domain fop789.loc.

root@ubuntu-server1:~# dig @ qehspqnmrn.fop789.loc

; <<>> DiG 9.16.1-Ubuntu <<>> @ qehspqnmrn.fop789.loc

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1279

;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; WARNING: recursion requested but not available


; EDNS: version: 0, flags:; udp: 4096


;qehspqnmrn.fop789.loc.         IN      A


fop789.loc.             300     IN      SOA     ns1.fop789.loc. hostmaster.ns1.fop789.loc. 2023041101 10800 3600 604800 86400

;; Query time: 4 msec


;; WHEN: Sun Jun 25 11:10:41 UTC 2023

;; MSG SIZE  rcvd: 101


The most prevalent reason why threat actors would use DGA is in malware and phishing campaigns to avoid detection and resilient to counter measures. The evasion technique used is Fast flux.

Fast flux

Fast flux is a domain name system (DNS) based evasion technique used by cyber criminals to hide phishing and malware delivery websites behind an ever-changing network of compromised hosts acting as reverse proxies to the backend botnet master—a bulletproof autonomous system. It can also refer to the combination of peer-to-peer networking, distributed command and control, web-based load balancing and proxy redirection used to make malware networks more resistant to discovery and counter-measures.

The fundamental idea behind fast-flux is to have numerous IP addresses associated with a single fully qualified domain name, where the IP addresses are swapped in and out with extremely high frequency, through changing DNS resource records, thus the authoritative name servers of the said fast-fluxing domain name is—in most cases—hosted by the criminal actor

Depending on the configuration and complexity of the infrastructure, fast-fluxing is generally classified into single, double, and domain fast-flux networks. Fast-fluxing remains an intricate problem in network security and current countermeasures remain ineffective.

What information can be used in observing NXDOMAIN response spike

There are several sources of information that can be used when NXDOMAIN response spike.

BIG-IP DNS profile statistics

A BIG-IP DNS listener (Virtual Server) will have a DNS profile applied to it. This profile provides access to DNS traffic statistics. In particular, "Question Type" and "Return Code" sections has statistics on DNS record types queried and return code count.

Here is a sample output from a script that periodically captured DNS profile statistics - stats were taken 20 seconds apart. These were taken during a lab test where NXDOMAIN response flood is being simulated.

Here is the sample script:

while true; do date >> /var/tmp/dns_stat.txt; tmsh show ltm profile dns dns-prof-1 >> /var/tmp/dns_stat.txt; echo "###################" >> /var/tmp/dns_stat.txt; sleep 20; done

Notice that the "Question Type" has only "A" records queried and in the "Return Code (RCODE)" , only " No Name (NXDOMAIN)" were the responses.

Date: Sun Jun 25 11:15:59 PDT 2023
Ltm::DNS Profile: dns-prof-1    
Virtual Server Name                      N/A
Query Message                   

  Recursion Desired (RD)               18847  100.0

  DNSSEC Checking Disabled (CD)            0    0.0

  EDNS0                                18847  100.0

   Client Subnet                           0    0.0

   Client Subnet Inserted                  0    0.0

  Operation Code (OpCode)       

   Query                               18847  100.0

   Notify                                  0    0.0

   Update                                  0    0.0

   Other                                   0    0.0

  Question Type                 

   A                                   18847  100.0

   AAAA                                    0    0.0

   ANY                                     0    0.0

   CNAME                                   0    0.0

   MX                                      0    0.0


   Other                                   0    0.0

Response Message                

  Authoritative Answer (AA)            18843   99.9

  Recursion Available (RA)                 0    0.0

  Authenticated Data (AD)                  0    0.0

  Truncated (TC)                           0    0.0

  Return Code (RCODE)           

   No Error                                1    0.0

   No Name (NXDOMAIN)                  18842   99.9

   Server Failed                           0    0.0

   Refused                                 1    0.0

   Bad EDNS Version                        0    0.0

   Name Error (NXDOMAIN) Override          0    0.0

  EDNS0 client subnet                      0    0.0

Date: Sun Jun 25 11:16:19 PDT 2023
Query Message                   

  Recursion Desired (RD)               18993  100.0

  DNSSEC Checking Disabled (CD)            0    0.0

  EDNS0                                18993  100.0

   Client Subnet                           0    0.0

   Client Subnet Inserted                  0    0.0

  Operation Code (OpCode)       

   Query                               18993  100.0

   Notify                                  0    0.0

   Update                                  0    0.0

   Other                                   0    0.0

  Question Type                 

   A                                   18993  100.0

   AAAA                                    0    0.0

   ANY                                     0    0.0

   CNAME                                   0    0.0


   Other                                   0    0.0
Response Message                

  Authoritative Answer (AA)            18989   99.9

  Recursion Available (RA)                 0    0.0

  Authenticated Data (AD)                  0    0.0

  Truncated (TC)                           0    0.0

  Return Code (RCODE)           

   No Error                                1    0.0

   No Name (NXDOMAIN)                  18988   99.9

   Server Failed                           0    0.0

   Refused                                 1    0.0

   Bad EDNS Version                        0    0.0

   Name Error (NXDOMAIN) Override          0    0.0

  EDNS0 client subnet                      0    0.0

Sample packet capture during a NXDOMAIN response spike

Earlier, we reviewed what is Domain Generation Algorithm (DGA) and that its used to generate random DNS names which are used by threat actors in fast flux technique to evade detection and mitigations for their phishing and malware campaigns.

The sample packet capture was taken while using the sample random DNS names generated thru a DGA to simulate a NXDOMAIN response flood.

Using the capinfos command, we can observe various details about the packet capture. First and last packet time tells us how long this pcap was running, in this case it has been around 13 mins. Also average packet rate per second, 76 packets/sec, can be useful if we are looking to find a baseline on packets per second value. And other packet capture details which may be useful depending on your purpose.

Since we are looking at DNS traffic, remember its query and response packets, so 76 packets per second, presumably may contain both type of packets, thus, estimation of 38 packets per second for dns queries. 

[root@bigip:TimeLimitedModules::Active:Standalone] tmp # capinfos nx-4.pcap

File name:           nx-4.pcap

File type:           Wireshark/tcpdump/... - pcap

File encapsulation:  Ethernet

File timestamp precision:  microseconds (6)

Packet size limit:   file hdr: 65535 bytes

Number of packets:   60 k

File size:           16 MB

Data size:           15 MB

Capture duration:    786.961838 seconds

First packet time:   2023-06-25 11:05:48.352417

Last packet time:    2023-06-25 11:18:55.314255

Data byte rate:      19 kBps

Data bit rate:       159 kbps

Average packet size: 260.57 bytes

Average packet rate: 76 packets/s

SHA1:                10d3652ce3b97d68d16f324ee6eaac918b8f34d9

RIPEMD160:           7c766e4e5819fb9f5c90cee133f0e1f61e9b5801

MD5:                 51cd10815de35802460ae0b26e156d66

Strict time order:   False

Number of interfaces in file: 1

Interface #0 info:

                     Encapsulation = Ethernet (1 - ether)

                     Capture length = 65535

                     Time precision = microseconds (6)

                     Time ticks per second = 1000000

                     Number of stat entries = 0

                     Number of packets = 60063

Next up, use tshark to get more information from the packet capture. Specifically, we are interested in the dns related information, such as the DNS records queried and the DNS response.

Extract all dns names from the packet capture - queries or response

[root@bigip:TimeLimitedModules::Active:Standalone] tmp # tshark -r nx-4.pcap -n -T fields -e > nx-4-pcap-records.txt
Running as user "root" and group "root". This could be dangerous.

Reviewing the number of dns names extracted, it matches the output from capinfos - 60063.

[root@bigip:TimeLimitedModules::Active:Standalone] tmp # cat nx-4-pcap-records.txt | wc -l

Sort the dns names extracted from the pcap - notice the randomness of these dns names. Could be fast flux technique or  an attempt to drown a DNS server of random records that it needs to search and eventually cause service disruption - a classic DNS water torture attack.

The sample DNS names taken from the pcap are still not so random and are short. There are longer and more random hostnames that can be generated by DGAs and this can really take a lot of memory and cpu resource from a DNS server.

[root@bigip:TimeLimitedModules::Active:Standalone] tmp # cat nx-4-pcap-records.txt | sort | uniq -c | sort -nrk 1

   3514 mmahaesqar.fop789.loc

   3512 arphansaqh.fop789.loc

   3509 hwepmerswa.fop789.loc

   3508 qrqnswerqs.fop789.loc

   3506 seenwrqrps.fop789.loc

   3506 pwprhhnqqn.fop789.loc

   3506 hrhspsrenn.fop789.loc

   3506 arwrseqssh.fop789.loc

   3505 eqqhnpswmh.fop789.loc

   3504 fop789.locaehwmnms.fop789.loc

   3503 qehspqnmrn.fop789.loc

   3503 psrhaaeqqa.fop789.loc

   3503 paepnpamea.fop789.loc

   3503 ewamspqwha.fop789.loc

   3501 aepaaemrmn.fop789.loc

   3500 mrspmramrn.fop789.loc

   3499 rnqhapapwn.fop789.loc


 DNS Water Torture Denial-of-Service Attacks

Customers reported pseudo-random subdomain or “DNS water torture attacks” hitting their networks with half a million connections per second. Outages were occurring even if a network wasn’t the direct target of the attack. For example, service providers still felt the effects as the DNS water torture traffic passed through their networks and saturated their pipes.

To pull off a DNS water torture attack, an attacker leverages a botnet (or thingbot) to make thousands of DNS requests for fake subdomains against an Authoritative Name Server.1 Because the requests are for non-existent subdomains or hosts, the requests consume the memory and processing resources on the main resolver. If there are intermediary DNS resolvers inline, they too get clogged up with these fake requests. For legitimate end users, all this resource consumption means everything runs slow or even stops, resulting in a denial of service.

Filtering further, we can extract the DNS response packets only

[root@bigip:TimeLimitedModules::Active:Standalone]  tmp # tshark -r nx-4.pcap -n -Y "dns.flags.response == 1" -T fields -e > nx-4-pcap-records-response.txt
Running as user "root" and group "root". This could be dangerous.

DNS response packets only count shows 29994, approx half of the previous output of 60063

[root@bigip:TimeLimitedModules::Active:Standalone] tmp # cat nx-4-pcap-records-response.txt | wc -l

We can then sort DNS response packets only and find the number of times each DNS name was responded to. We know that the response to these queries are NXDOMAIN because we don’t have these records in the lab DNS server records list. We can also observe which DNS names were responded the most. In the example output, each of the records were responded almost equally.

[root@bigip:TimeLimitedModules::Active:Standalone] tmp # cat nx-4-pcap-records-response.txt | sort | uniq -c | sort -nrk 1

   1748 qehspqnmrn.fop789.loc

   1748 mmahaesqar.fop789.loc

   1746 seenwrqrps.fop789.loc


   1746 aepaaemrmn.fop789.loc

   1744 paepnpamea.fop789.loc

   1744 arphansaqh.fop789.loc

   1742 eqqhnpswmh.fop789.loc

Version history
Last update:
‎07-Jul-2023 08:05
Updated by: