Avoid Large Records with a Wildcard Owner Name

Abstract

As DNS hosting becomes increasingly centralized, with multiple zones hosted on shared authoritative name servers, the risk of DNS amplification attacks has grown. By crafting large DNS records with wildcard owner names, attackers can exploit these shared servers to launch high-volume DDoS amplification attacks.¶

This document provides operational guidance for DNS hosting providers to mitigate DDoS risks arising from amplification of responses derived from wildcard owner names.¶

1. Introduction

The DNS system exhibits a small-query, large-response characteristic, which can lead to high amplification towards targeted victims. Both recursive and authoritative DNS servers can be abused as amplifiers. Previous work [RFC5358] recommends restricting recursive lookup services to intended clients to prevent unintended amplification. Additionally, [RFC8482] recommends returning minimal-sized responses for queries with QTYPE=ANY.¶

However, the risk of DNS amplification remains critical. The centralization of DNS hosting and the increasing number of open recursive resolvers worldwide have heightened the potential for DDoS amplification attacks. On one hand ，exploitation of a single hosted zone may affect all zones on the same name server.On the other hand, the large and globally distributed population of open resolvers provides attackers with an extensive amplification surface.¶

This document provides guidance for DNS hosting providers to mitigate DDoS risks arising from maliciously crafted DNS records.¶

2. Problem Description

A DNS amplification attack typically requires the following conditions:¶

1. Very large responses to DNS queries.¶
2. Queries that consistently bypass recursive DNS caches.¶
3. Low operational cost or effort for the attacker.¶

These conditions can be easily satisfied by configuring oversized DNS records such as large TXT records with wildcard owner names on shared DNS hosting platforms. An attacker can then issue small queries with randomized labels, discard the replies, and trigger excessive traffic between recursive resolvers and authoritative servers. Because wildcard expansion forces each random name to bypass resolver caches, the queries are repeatedly forwarded upstream to authoritative DNS servers. The attack is highly efficient because an originating stub resolver using UDP without EDNS(0) will trigger a truncated response from the open resolver, which prevents large authoritative answers from reaching the originating host. As a result, bandwidth consumption is confined to the path between open resolvers and authoritative servers. The lack of EDNS(0) also provides only a weak signal, making it difficult to develop effective mitigations based solely on this behavior.¶

The following illustrates a scenario where an attacker could exhaust the outbound capacity of a victim authoritative server:¶

1. Identify the authoritative name server for the victim domain.¶

2. Register a domain controlled by the attacker on the same name server.¶

3. Create oversized records with a wildcard owner name, such as TXT records.¶

4. Identify open recursive resolvers by scanning the IP space.¶

5. Use automated tools to send DNS queries for random subdomains (e.g., {random}.attack TXT) to open recursive resolvers.¶

6. The outbound capacity from the authoritative server hosting the victim domain will be exhausted.¶

Attackers can also leverage compromised hosts, for example systems within a botnet that rely on their configured recursive resolvers, to initiate the attack. In this case, DNS queries can be triggered indirectly by other application protocols. Examples include a web advertisement that embeds a URL containing the target domain and a randomized sublabel, or a minor compromise of a popular web page that inserts an equivalent invisible reference. These mechanisms allow large volumes of queries to be generated without requiring direct control of the DNS client software.¶

3. Recommendations

This section provides best practices for maintaining DNS data at reasonable sizes and reducing the risk that a shared authoritative server may be abused. Recommendations primarily target DNS hosting providers.¶

Operators should enforce size limits for large records, particularly those with wildcard owner names, and apply restrictive controls when records have very short TTLs. Thresholds should be determined based on the operational environment and risk tolerance.¶

Recommended practices:¶

1. Apply size limits to records with wildcard owner names.¶

   Enforce maximum size thresholds for DNS records defined under wildcard owner names to prevent amplification through oversized responses.¶

2. Apply size limits to records with very small TTLs.¶

   Short TTL values increase cache-miss frequency, which amplifies the number of forwarded queries.¶

3. Monitor for abnormal traffic patterns.¶

   Implement logging and real-time alerting to detect unusually high query volumes or other indicators of potential attack activity.¶

4. Rate-limit queries that generate large responses.¶

   Apply per-source, per-prefix, or query-type-aware rate limiting to reduce amplification effects and prevent overload on authoritative servers.¶

5. Restrict and periodically review wildcard usage.¶

   Require justification and periodic review for wildcard records with large RDATA to avoid unintended amplification exposure.¶

6. Test mitigation controls.¶

   Regularly test monitoring, rate-limiting, and record-size enforcement mechanisms under realistic conditions, adjusting thresholds to maintain protection without disrupting legitimate traffic.¶

These measures reduce the attack surface for DNS amplification attacks while enabling operators to balance availability and security for their users.¶

4. Implementation Experience

Tests have shown that some DNS hosting providers allow users to configure oversized records with wildcard owner names. Responses exceeding the standard UDP packet size trigger TCP fallback, allowing responses up to approximately 64 KB, yielding amplification factors exceeding 1000x.¶

Observations from providers include:¶

1. GoDaddy imposes no limit for jumbo TXT records.¶
2. Cloudflare imposes a limit of 8192 bytes for jumbo TXT records.¶
3. Microsoft DNS service imposes a limit of 4096 bytes.¶
4. Alibaba Cloud and DNSPod set limits following disclosure of these risks.¶

5. Normative References

[RFC5358]

Damas, J. and F. Neves, "Preventing Use of Recursive Nameservers in Reflector Attacks", BCP 140, RFC 5358, DOI 10.17487/RFC5358, October 2008, <https://www.rfc-editor.org/info/rfc5358>.

[RFC8482]

Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, "Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 2019, <https://www.rfc-editor.org/info/rfc8482>.