DNS-Level Filtering

Where does DNS-level filtering act?

In the Cybersecurity and Infrastructure Security Agency's protective DNS example, queries pass through protective resolvers that compare requested names with threat intelligence before destination traffic proceeds.

The protective resolver sits in the DNS resolution path. In the agency's example, it compares a DNS request with a threat-intelligence indicator. When it finds a match, the service can block, redirect, or sinkhole the query response and emit an alert.

The resolver acts on the DNS query response: it can block, redirect, or sinkhole that response. The Cybersecurity and Infrastructure Security Agency example describes one protective resolver flow; other resolvers may behave differently.

1. A DNS query passes through a protective resolver in the documented example.
2. The resolver compares the requested name with threat intelligence.
3. A match can lead the service to block, redirect, or sinkhole the response and emit an alert.

What can be observed in a DNS request?

A DNS request includes a queried name, or QNAME, and source IP address among its fields; the QNAME is the full name sent by the user and can reveal activity or communication relationships.

The QNAME and source IP address are two request fields that matter for privacy on the resolver path. The QNAME carries the full name the user asks DNS to resolve. The source IP address supplies source-address information with the request.

A queried name can reveal information about what the user is doing and can be revealing about communication relationships. This section concerns the QNAME and source IP address as fields in a DNS request.

• QNAME: the full name sent by the user in the DNS request.
• Source IP address: source-address information included with the request.
• Privacy significance: the queried name can reveal activity or communication relationships.

What changes when DNS transport uses HTTPS?

Filtering or inspection that depends on unsecured DNS transport does not function when the client uses DNS over HTTPS, because TLS provides confidentiality and integrity protection for the query channel.

The limit applies to a specific dependency: a filtering or inspection system that relies on unsecured transport of DNS. In a DNS-over-HTTPS environment, TLS protects the query channel, so that unsecured-transport-dependent system no longer has the plaintext visibility on which it relies.

A DNS-level control applies on the resolver path actually used. This documented behavior establishes a path boundary: changing the DNS query channel can remove the plaintext visibility required by this kind of filtering.

The quoted standards statement concerns filtering or inspection that relies on unsecured DNS transport in a DNS-over-HTTPS environment. It does not describe other encrypted-DNS protocols or other traffic layers.

• Affected control: filtering or inspection that relies on unsecured DNS transport.
• Protected channel: DNS over HTTPS uses TLS confidentiality and integrity protection for the DNS exchange.
• Path limit: a DNS-level control applies only on the resolver path actually used.

What retention limits are recommended for DNS privacy services?

Internet Engineering Task Force recommendations say DNS privacy services should minimize or completely avoid data retention if possible and protect any retained data with encryption and, whenever possible, aggregation, pseudonymization, or anonymization.

The guidance is recommendation-level, not a report of what a particular resolver does. For DNS privacy services, it says retention should be minimized or completely avoided if possible. If data is retained, it should be encrypted and, whenever possible, aggregated, pseudonymized, or anonymized.

The recommendations also distinguish transient data from DNS traffic logs. Transient data should be kept for the shortest period deemed operationally feasible. DNS traffic logs should be retained only as long as required to sustain operation of the service and meet regulatory requirements, to the extent those requirements exist.

These are recommendations for DNS privacy services rather than a report of any named resolver's actual practices.

• General recommendation: minimize or completely avoid retention if possible for DNS privacy services.
• If retained: encrypt the data and, whenever possible, aggregate, pseudonymize, or anonymize it.
• Transient data: keep it for the shortest period deemed operationally feasible.
• DNS traffic logs: retain them only as long as required to sustain the service and meet regulatory requirements, to the extent those requirements exist.
• Scope limit: recommendations are not evidence of any named resolver's actual policy.