QNAME Minimization and Spamhaus DNSBLs

On October 4th the Internet Systems Consortium (ISC) issued an article highlighting a problem with Spamhaus’ RBLDNS servers incorrectly answering partial queries that are sent due to QNAME minimization. Our technical team has deployed an initial patch for this issue, and we are in open dialogue with the ISC as we continue our investigations. We would like to thank the ISC for bringing this issue to our attention and reinforce our support for this recent enhancement to the DNS protocol.

At Spamhaus, we are privacy advocates, and we recognize the importance of QNAME minimization in enhancing online security and user privacy. Creating the impression that we are opposed to its benefits or reducing privacy is the last thing we want to do. There is no question that QNAME minimization is a good thing for the community at large. There is, however, an unresolved issue that is directly impacting DNS Blocklist (DNSBL) providers and users.

QNAME Minimization and DNSBLs

As outlined on the ISC’s website, “QNAME minimization changes the DNS queries from the recursive resolver to include only as much detail in each query as is required for that step in the resolution process.” In most cases this is helpful, as the majority of queries do not require all the information provided and it offers a layer of privacy minimizing exposure to unnecessary detail.

However, for DNSBL queries a fully executed QNAME minimization query can become problematic. This is due to the number of labels in the RBL lookups. Here is an example of a Spamhaus Blocklist (SBL) lookup using an IPv4 and an IPv6 address:

DNSBL lookup with an IPv4 address: If the resource to be queried is an IPv4 address, to query the Spamhaus Blocklist (SBL) about the listing status of 203.0.11.79 you would need to perform a query for 79.113.0.203.[key].sbl.dq.spamhaus.net. In practice, the nameserver for sbl.dq.spamhaus.net will most often be cached already, resulting in five queries.

DNSBL lookup with an IPv6 address: If the IP address to be queried is IPv6, to query SBL about the listing status of 2002:db8:7ca6:22::45 you would need to perform a query for 5.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.2.0.0.6.a.c.7.8.b.d.0.1.0.0.2.[key].sbl.dq.spamhaus.net. This is regardless of how much has been cached already. Assuming - as above - the delegation records for sbl.dq.spamhaus.net are already in your cache, the number of queries to identify the listing status of the IPv6 address could reach 33!

There are some partial mitigations to this explosion in the number of queries, as RFC9156 recommends, in section 2.3, that the limit for the number of these recursions should be 10. However, this is just a recommendation and as such not mandatory.

What is the problem?

The first part of the query .sbl.dq.spamhaus.net is controlled by standard authoritative resolvers. However, the second part of the query takes place within the DNSBL zones, which is served by the RBLDNSD name servers dedicated only to these zones.

Complying with QNAME minimization the recursive resolver queries item by item left of the DQS key ensuring not to expose too much information. And here lies the problem. For an IPv6 address the recursive resolver has to ask a total of 33 questions before an answer is reached, turning one query into 33. This is, however, the worst-case scenario, and based on RFC9156 recommendations a maximum of 10 queries would be expected.

The situation is a bit better for IPv4 addresses, as they "only" bring a 5x increase in the number of queries necessary to get to the actual question being asked. Nonetheless, this is still an issue for multiple reasons: on the one hand, it puts additional strain on an infrastructure that is already extremely loaded (to give some context, Spamhaus' DNSBL infrastructure processes, on average, hundreds of thousands of queries per second).

But - more importantly - it seriously affects the email ecosystemas a whole. Each query is sequential, meaning that the latency of obtaining data for a single IPv6 increases from 50 to 500 milliseconds (based on RFC9156 recommendations) - or in the scenario of all 33 queries, 1,650 milliseconds! Proper analysis of an average email transaction involves tens of similar resolutions for the most various items (IPv4, IPv6, hostnames, URLs, email addresses, etc.) leading to an issue for all DNSBL users.

As a provider of DNSBLs for over 25 years, this is presenting a problem.

Disabling QNAME Minimization for DNSBLs

Despite the associated challenges, we remain without a doubt that QNAME minimization on the whole is a positive feature. And our technical team is working to identify ways of reducing the overhead for DNSBL look-ups while preserving QNAME minimization functionality. In the meantime, for DQS customers or those accessing Spamhaus Project Public Mirrors we recommend using a dedicated DNS server that has QNAME Minimization disabled for queries to Spamhaus’ DNSBLs. Here you can find technical documentation detailing the configuration for disabling QNAME minimization for Spamhaus DNSBLs.

Proposed changes to protocol

Investigations by our technical team have identified that all open source and public DNS resolvers use what is called a “relaxed” form of QNAME minimization by default. This means that if we return an NXDOMAIN answer to an incomplete query, the DNS resolver reacts by returning the entire query. Although this solution would allow us to turn off QNAME Minimization, it is not compliant with current RFC’s.

Therefore, we recommend there should be a standardised option to request that QNAME minimization is turned off for queries to Spamhaus’ DNSBLs. And we have a logical explanation for this request.

Spamhaus’ RBLDNSD is a small DNS daemon made specifically to serve DNS zones for querying DNS-based IP-listings. The RBLDNSD is intended to provide the full answer to the query as quickly as practical. This means when querying an RBLDNSD, producing an unminimized answer is exactly what it should do. By turning off QNAME minimization for zones served by RBLDNSD, it will reduce overall queries and significantly improve performance. More importantly, there is no loss of privacy - DNS servers see the full query regardless as there are no delegated sub-zones in an RBL.

Let’s not stop the conversation here

As we work through the investigation and solution process with the ISC, we do not consider this the end of the conversation. We would like to work collaboratively with the community to agree on a resolution to meet email security objectives while preserving internet privacy.