Since its inception, the Domain Name System (DNS) has been susceptible to spoofing attacks. Despite many advances in DNS security and privacy, Distributed Denial of Service (DDoS) attacks can still use spoofed DNS queries for overwhelming their victim today.
The inseparability of DDoS attacks and the DNS
To perform a DDoS attack, the attacker sends DNS queries to thousands of DNS servers. The key is that each query has been spoofed to look as if they’re from the victim’s IP address. As each DNS server receives a query, it generates a response (often magnitudes larger than the query) and sends it to the victim’s IP. These responses all combine to flood the metaphorical ‘pipe’ that is the victim’s Internet connection. This prevents legitimate traffic from getting in and out, denying the victim access to the Internet. To give an idea of scale, an attack against Spamhaus in 2013 reached over 100 Gbps and used 30,000 DNS servers.
The main reason spoofing attacks are possible with the DNS is because the primary transport protocol, User Datagram Protocol (UDP), lacks identity management. In other words, UDP does not establish a connection nor verify that the client and server are communicating with who they expect. This enables a malicious actor to send a UDP packet of their design, with a spoofed ‘from’ address.
However, the DNS supports several other transport protocols and security mechanisms to combat this. In fact, the DNS has always supported TCP. More recently, specifications for DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) have seen adoption and use. These protocols both inherently provide identity management in addition to encryption. Finally, DNS cookies were created to provide unique identifiers inside of DNS messages, enabling identity management with the speed benefits of UDP.
In reality, none of these mechanisms prevent attacks that spoof a client’s IP address, like the DDoS attack we previously described. A DNS server will always respond to UDP queries because:
- It’s required by the DNS specification.
- Most clients use UDP (or did historically).
- The server has no knowledge of what protocols a client supports.
One might suggest that DNS servers could learn a client’s preferred protocol (for example, DNS cookies) then filter out UDP queries claiming to be from that IP. However, in a DDoS attack, thousands of DNS servers are used, and the victim’s DNS client has almost certainly never communicated with all the servers. Even in cases where previous communication has been established, we found that 99% of DNS servers that supported DNS cookies responded normally when we suddenly stopped including cookies in our queries. See our paper: A peek into the DNS cookie jar.
Our solution: Advertisement records
The solution is to provide a mechanism for DNS servers to independently determine a client’s preferred protocol. Luckily for us, the DNS is a great mechanism for sharing information in a publicly accessible way. We propose having clients publish ‘DNS Protocol Advertisement Records’ in their reverse DNS zone that specifies the transport mechanism they support. Servers can then check for this record when a query is received and only respond if the query conforms.
An advertisement record is of type TXT. Clients can select to advertise a protocol of UDP (the default), cookie, TCP, or none (no queries are sent). The advertised protocol defines the minimum level of security the client will use (for example, if a client selects a cookie, they can also send TCP queries).
Advertisement records must be placed at the /16 subnet level in the reverse DNS zone. As a result, one record covers many IP addresses. To allow for more flexibility, the advertisement can be delegated to any number of /24 subnets. This is done by setting the subnet’s appropriate bit in a hex string.
The format for the record is summarized as follows:
v=dpar1 {udp|cookie|tcp|none}[ delegate=(64-char-hex-field)]
We decided on using /16 and /24 subnets to maximize efficiency for servers (minimal queries) with convenience for clients (a manageable number of records). We performed an analysis of IPs querying the DNS root servers, Autonomous System prefix announcements, and queries to/from Brigham Young University to verify feasibility. Using the same methods, we determined that for IPv6, /40 and /48 subnets should be used.
Future work and open questions
We believe that advertisement records can efficiently and effectively stop DDoS attacks from ever getting past DNS servers. However, our analysis primarily focused on the feasibility of our proposal from the client and record perspective. We still have a considerable amount of work to do in order to prove that servers can enforce advertisement records with a low overhead. As with any Internet proposal, adoption will be difficult, especially if there is a noticeable performance loss.
In the future, we hope to develop a sample implementation for recursive/authoritative DNS servers. This will allow us to fine-tune many aspects of the protocol and determine feasibility from the other perspective.
Jacob Davis recently graduated from Brigham Young University with a Master’s in Computer Science and now works at Sandia National Laboratories. His research interests include network security, the DNS, and Internet measurement.
Casey Deccio contributed to this blog.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
I’m pretty confused about this proposal.
1. If clients advertise as just continuing to use UDP, what has been gained?
2. The subnet compromise seems to mean that client discrimination on a per-IP basis is not possible, yet many clients are behind a single ipv4 assignment from their ISP.
3. Similarly, how does the subnet compromise work for clients behind NATs and CGNATs?
4. How is this proposal superior to DNS Cookies which similarly authenticate src IP addresses of UDP clients? Maybe a better strategy is to encourage auth servers to be much more aggressive about DNS Cookie use by clients?
Hi Mark,
1. That’s correct, it wouldn’t serve any purpose. It’d be similar to an SPF record that’s just “+all”. The idea though is that this is the underlying option servers assign to a subnet without a record (e.g., “this subnet doesn’t have an advertisement, so I’ll treat it as if it’s using UDP or above”)
2. Yes, this does not generally work on a per-IP basis. The design is geared more towards businesses, universities, etc. who will likely have a /24 or more assigned to them. I’d expect they are more likely to be targets of a DDoS attack too, though I have nothing to back that up. Additionally, creating an advertisement record requires the ability to publish a TXT record in the reverse DNS. This isn’t generally something someone with a single IP could do (e.g., in a residential setting).
3. Our design is mostly NAT-agnostic, though it is important to think about. Say you have an advertisement record of “TCP” that applies to an IP with a NAT. If clients behind that NAT used UDP, they would get dropped by enforcing servers. However, there’s a number of ways to avoid this. The easiest method would be to provide clients with a local resolver via DHCP. That resolver can then be configured to forward queries using TCP which would be in compliance with the advertisement record.
4. This proposal is what makes DNS Cookies enforceable. In the current state of things, no server can ignore a UDP query for the reasons stated above. In fact, we tested this with DNS Cookies. We tested servers that support DNS Cookies and found that 99% still responded to us normally if we suddenly stopped including cookies in our client queries. In other words, all of these servers would respond to spoofed queries from an attacker even though our client supported cookies.
Another thing to consider is that in a DDoS attack, hundreds of public DNS servers are used. Chances are, our client would have never queried a majority of those servers. Not knowing any better, those servers would respond to a spoofed UDP query because they have no knowledge of what protocol our client uses.
With our proposal, our client would be able to authoritatively state that it uses Cookies. All servers (regardless of previous contact) could check for the advertisement record stating so, and enforce appropriately.
Hopefully I answered your questions, but feel free to reply with any followup questions. Thanks!
Thanks for the response, Jacob.
Your answers to 2&3 suggest that it’s not something an ISP can deploy as they have no control over their customers DNS clients, nor can they readily enforce any particular behaviour.
If ISPs are unable to participate, isn’t that leaving a huge swathe of the Internet unable to be covered by the proposed Advertisement Records?
Given that many, and perhaps most, DDOS attacks originate from compromised home PCs, I suspect your proposal needs to solve for ISP address space as well.