Implementation Guidelines for Authoritative DNS Proxies

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 19 April 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Discussion Venues

This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/NLnetLabs/draft-homburg-dnsop-igadp.git .¶

2. Introduction

In some situations it can be attractive to have an authoritative DNS server that does not have a local copy of the zone or zones that it serves. In particular in anycast operations, it is sensible to have a great geographical and topological diversity. Benefits of an extra site can be: reduced latency, DDoS protection by serving a zone locally and thus be protected from a DDoS that originates in other parts of the network, and DDoS mitigation by attracting local DDoS traffic.¶

However, sometimes the expected use of a particular site does not warrant the cost of keeping local copies of the zones up-to-date. This can be the case if a zone is very large or if the anycast cluster serves many zones and only a few of them are expected to receive significant traffic.¶

In these cases it can be useful to have a proxy serve some or all of the zones. Instead of having a local copy of the zones, such a proxy forwards requests to another server that is authoritative for the zone. The proxy may have a cache.¶

A proxy can operate with or without cache. Without a cache, the proxy forwards each incoming request to a name server that is authoritative for the domain. This is straight forward, but also provides limited benefits.¶

Because we need the proxy to behave like an authoritative server and provide similar behavior with respect to TTLs and data consistency, proxy behavior with a cache is more involved.¶

Another issue that may complicate caching of responses is the EDNS Client Subnet option.¶

3. Basic Requirements

The proxy sends requests upstream with RD bit clear.¶

The proxy sends replies to clients with the original TTL. Caching is not controlled by TTL but by the parameters in the SOA record.¶

4. Cache replacement

The goal of the cache replacement strategy described here is to mimic the behavior of a standard secondary as much as possible.¶

The proxy fetches SOA records just like a secondary would do based on the parameters in the SOA record in response to a NOTIFY, and takes the contents of the EXPIRE option [RFC7314].¶

Cache entries are tagged with the zone serial number from the most recent SOA record. A cache entry is valid only when the serial number in the cache entry matches the serial number of the current SOA record.¶

When a new SOA record arrives with a higher serial number, there are two options. The first option is to take this as the new current SOA record. This has the effect of immediately invalidating the cache.¶

The second option is to delay accepting this SOA and load new copies of hot cache items first.¶

Note that DNS replies may contain SOA records. If a DNS replies contains a SOA record with a higher than the most recently seen serial number (taking into account Serial Number Arithmetic [RFC1982]), then the proxy updates its copy of the SOA records using one of the two techniques described above.¶

5. Aggressive negative caching

A caching proxy is allowed to generate negative responses (NODATA or NXDOMAIN) [RFC8198][RFC9077] based on information in NSEC or NSEC3 records. Obviously this can be done only for DNSSEC signed zones, and NXDOMAIN only for NSEC or NSEC3 without opt-out.¶

6. ENDS Client Subnet Option

A proxy MAY support [RFC7871] (Client Subnet in DNS Queries).¶

If the proxy supports ECS, it SHOULD be disabled by default. The reason is that ECS sends privacy sensitive data over the internet.¶

A proxy that does not support ECS or where ECS support is disabled MUST not send queries upstream that contain the ECS option. In addition, the proxy MUST NOT send replies that contain an ECS option.¶

7. Acknowledgements

Many thanks to Willem Toorop for his feedback.¶

Author's Address