Internet-Draft TLD Zone Pipeline Requirements May 2024
Stenstam & Schlyter Expires 3 November 2024 [Page]
Workgroup:
DNSOP Working Group
Internet-Draft:
draft-johani-tld-zone-pipeline-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Stenstam
The Swedish Internet Foundation
J. Schlyter
Kirei AB

TLD Zone Pipeline: Requirements And Design Principles

Abstract

Today most TLD registries publish DNSSEC signed zones. The sequence of steps from generating the unsigned zone, via DNSSEC signing and various types of verification is referred to as the "zone pipeline".

The robustness and correctness of the zone pipeline is of crucial importance and the zone pipeline is one of the most critical parts of the operations of a TLD registry.

The goal of this document is to describe the requirements that the .SE Registry choose in preparation for the implementation of a new zone pipeline. The document also describes some of the design consequences that follow from the requirements. Hence this document is intended to work as a guide for understanding the actual implementation, which is planned to be released as open source.

TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/johanix/draft-johani-tld-zone-pipeline. The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests.

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 3 November 2024.

Table of Contents

1. Introduction

Today most TLD registries publish DNSSEC signed zones. This typically leads to a zone production "pipeline" that consists of several steps, including generation of the unsigned zone, signing of the zone and various types of verifications that the zone is correct before publication on the Internet.

In some cases, including the .SE Registry, the zone pipeline was not the result of a clear requirements process, nor was it the result of a concious design and implementation. Rather, it was the result of combining various tools in a mostly ad-hoc way that achieved the goal of moving the zone via signing and verifications towards publication.

When a critical part of the operation of a TLD registry is the result of an ad-hoc process there are likely to be hidden risks. That was the case for the .SE registry, which had a serious incident in February 2022. Because of that incident, .SE decided to re-evaluate the requirements on the zone pipeline and then create a more robust implementation from scratch.

This document aims to describe the requirements for zone production (also known as "zone pipeline") that the .SE Registry choose in preparation for the implementation of the new zone pipeline. It is developed for the needs of the .SE and .NU TLD Registries, but the conclusions are intended to be generally applicable.

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Purpose

A TLD Registry has a total responsibility towards society and the Internet community to ensure, at any given time, public access to correct versions of the DNS zones under their management. In order to meet this commitment, three components are essentially required:

The first step is handled by the Registry System. The third step is handled by a combination of external providers of authoritative DNS service and in-house DNS service. Both of these steps are out-of-scope for this document

The sole purpose of this document is to provide a correct set of requirements for the second step, between zone generation in the Registry System and zone publication on the public Internet.

3. Terminology

Upstream: : Further up in the zone pipeline, i.e. in the direction of the Registry System.

Downstream: : Further down the zone pipeline, i.e. towards the public Internet.

4. Basic Design Principles

A number of fundamental principles are defined for the design of the system. The intention of these principles is to minimize the risk that the zone data (as generated by the Registry System) can somehow change at any stage through the zone pipeline.

5. Interface to the Registry

Interface to the Registry System must be done according to standardized protocols. This requirement has the following consequences:

6. Local Updates

During normal operation, no changes to the zone data retrieved from the Registry may take place. However, there may be situations where the Registry is not reachable (nor is it expected to be reachable within a reasonable time) and where local updates of zone data must be able to be carried out. This can for example, be redirection of socially important infrastructure.

In a crisis situation (emergency operation), zone updates must be able to take place locally. Updates that take place in this way are introduced into regular systems as soon as possible. Return to normal operation may only take place after all changes made during emergency operation have been introduced into the regular system.

Local updates must be applied using a strict and traceable method. It must be clear at all times whether local updates have been applied, what these are and who requested them.

In cases where local updates have taken place, ZONEMD MUST be updated.

N.B. Local updates are an extraordinary measure and must not be used except in emergency situations. Procedures for who may request these are decided by the Internet Foundation's crisis management.

7. Ingress Verification

Before signing, a number of checks must be performed on the zone contents. The reason why checking must take place before signing is to ensure that the zone being signed is always correct and can thus continue to be re-signed in the event of problems upstream. The exact checks to be carried out are set out in a separate specification and are subject to local policy.

7.1. Requirements on ingress verification

  • The ingress verification MUST prevent an updated incorrect zone from being signed. An already approved previous version of the zone MUST continue to be signed until a new zone is approved.

  • New zone controls MUST be able to be added without the component for ingress verification of zone data needing to be redesigned

  • The interface from the zone pipeline to the ingress verification function MUST be DNS AXFR. This means that all controls must logically sit to the side and not be part of the critical path. I.e. the verification code is not part of the zone pipeline.

  • All zone controls, self-developed or imported, must have local ownership within the organization.

7.2. Examples of ingress verification checks

  • Check that the zone data is complete.

  • Check that the ZONEMD, which has been generated by the registry system, is correct

  • Check that delegation information for the zone itself is correct.

  • Check that the delta (i.e. the difference) between the current zone and the previous version is within approved limits.

  • Check that certain crucial records are present and correct (the zone's SOA record is one example).

8. Signing

The task of the signing step is to keep an approved and received zone signed for an arbitrary length of time until a new zone is received from upstream (i.e. from Registry via Ingress Verification).

8.1. Key management

The following requirements apply to the management of cryptographic keys for signing zone data:

  • The key material must be stored and used in an HSM that meets the security requirements set by the CISO.

  • The interface for accessing the key material SHALL be PKCS#11.

  • All keys must, to facilitate replication between different signing entities, be generated in advance.In order to facilitate replication between different signing entities, all keys must be generated in advance.

  • Exchange of KSK can be initiated automatically or manually, and is automatically terminated when the DS record in the parent zone is updated (after according to an appropriate safety margin).

  • Changing the KSK may only be completed if the DS record in the parent zone is updated.

  • Replacement of ZSK MUST be done automatically.

8.2. Zone signing

The following requirements apply to signing zone data:

  • Signing MUST be done using key material via PKCS#11.

  • The signing function MUST support algorithm rollover, e.g,. from RSA/SHA-256 to ECC/P-256/SHA-256.

  • Signing MUST be done with either NSEC or NSEC3 semantics.

  • If NSEC3 salt is used, the salt MUST be periodically changed automatically.

  • Change of DNSSEC signing semantics from NSEC to NSEC3 and vice versa MUST be possible automatically.

  • Previous signatures that are valid within a configurable time window SHALL be reused when re-signing, in order to reduce the rate of change on the zone.

  • The signing function SHALL recreate the ZONEMD RR per [RFC8976] after the zone has been signed.

9. Egress Verification

After signing, several checks must be performed on the zone contents. Apart from the obvious validation of generated DNSSEC signatures it is also important to ensure that the signing step only added DNSSEC- information without in any way modifying the unsigned data.

9.1. Requirements on egress verification

  • All generated DNSSEC signatures (RRSIG records) MUST be validated.

  • The NSEC (or NSEC3) chain MUST be verified to be complete.

  • The non-DNSSEC content of the signed zone MUST be provably identical to the corresponding unsigned zone that entered the signing step.

9.2. Examples of egress verification checks

  • Verify the zone with other software than was used for signing.

  • Remove all data added by the signing step and check the ZONEMD value over that data with the ZONEMD from before the signing.

10. Distribution

The following requirements apply to distribution of the signed zone:

11. Resulting Design Consequences

12. Security Considerations

The correct generation and DNSSEC signing of a TLD zone is a matter of significant importance. As such requirements and methods for verification of correctness is an important matter that has previously not been much publically discussed.

As a requirements specification this document aims to make this topic more public and visible with the intent of improving the correctness of the requirements via public review.

13. IANA Considerations

None

14. Acknowledgements

We appreciate suggestions and helpful comments from a number of people, including but not limited to:

15. Normative References

[RFC1995]
Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, , <https://www.rfc-editor.org/info/rfc1995>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5936]
Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, , <https://www.rfc-editor.org/info/rfc5936>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8976]
Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. Hardaker, "Message Digest for DNS Zones", RFC 8976, DOI 10.17487/RFC8976, , <https://www.rfc-editor.org/info/rfc8976>.

Appendix A. Change History (to be removed before publication)

Authors' Addresses

Johan Stenstam
The Swedish Internet Foundation
Sweden
Jakob Schlyter
Kirei AB