Internet DRAFT - draft-homburg-dnsop-igadp
draft-homburg-dnsop-igadp
DNSOP P.C. Homburg
Internet-Draft 17 October 2023
Intended status: Standards Track
Expires: 19 April 2024
Implementation Guidelines for Authoritative DNS Proxies
draft-homburg-dnsop-igadp-00
Abstract
In some situations it be can 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. However, sometimes
the expected use of a particular site does not warrant the cost of
keeping local copies of the zones. This can be the case if a zone is
very large or if the anycast cluster serves many zones from which
only a few are expected to receive significant traffic. In these
cases it can be useful to have a proxy serve some or all of the
zones. The proxy would not have a local copy of the zones it serves,
instead it forwards request to another server that is authoritative
for the zone. The proxy may have a cache. This document describes
the details of such 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.
Homburg Expires 19 April 2024 [Page 1]
Internet-Draft igadp October 2023
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 . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 3
4. Cache replacement . . . . . . . . . . . . . . . . . . . . . . 3
5. Aggressive negative caching . . . . . . . . . . . . . . . . . 4
6. ENDS Client Subnet Option . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . 4
9. Informative References . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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
(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.
Homburg Expires 19 April 2024 [Page 2]
Internet-Draft igadp October 2023
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.
Homburg Expires 19 April 2024 [Page 3]
Internet-Draft igadp October 2023
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.
8. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>.
[RFC7314] Andrews, M., "Extension Mechanisms for DNS (EDNS) EXPIRE
Option", RFC 7314, DOI 10.17487/RFC7314, July 2014,
<https://www.rfc-editor.org/info/rfc7314>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<https://www.rfc-editor.org/info/rfc7871>.
[RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
July 2017, <https://www.rfc-editor.org/info/rfc8198>.
9. Informative References
Homburg Expires 19 April 2024 [Page 4]
Internet-Draft igadp October 2023
[RFC9077] van Dijk, P., "NSEC and NSEC3: TTLs and Aggressive Use",
RFC 9077, DOI 10.17487/RFC9077, July 2021,
<https://www.rfc-editor.org/info/rfc9077>.
Author's Address
Philip Homburg
Email: philip@nlnetlabs.nl
Homburg Expires 19 April 2024 [Page 5]
