Compact DNSSEC

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 27 August 2025.¶

Copyright Notice

Copyright (c) 2025 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. Background

DNSSEC has low adoption rate on SLD [SadDNSSEC].¶

The operation burden of fullzone DNSSEC deployment is heavy.¶

DNS random subdomain attacks and amplification attacks are commonly used distributed denial-of-service (DDoS) attacks. The DDoS amplification power of the authoritative server of SLD will be larger after deploying DNSSEC [AmpDNSSEC].¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶

Basic terms used in this specification are defined in the documents [RFC1034], [RFC1035], [RFC8499].¶

• Authoritative Server: Described in [RFC8499].¶

• Recursive Resolver: Described in [RFC8499].¶

3. Compact DNSSEC Scheme

To encourge the DNSSEC deployment on resource-limited SLD, it is resonable to give it a compact DNSSEC deployment scheme.¶

    example.com. 345600 IN NS ns1.example.com.
    example.com. 345600 IN NS ns2.example.com.
    ns1.example.com. 345600 IN A 11.22.33.44
    ns1.example.com. 345600 IN AAAA ::11.22.33.44
    ns2.example.com. 345600 IN A 55.66.77.88
    ns2.example.com. 345600 IN AAAA ::55.66.77.88
    _853._tcp.ns1.example.com. 3600 IN TLSA ( 3 1 1
      63cbfcafa3284cc46b1676a99dbc09d8acadf9050cf876de79ac1e5776bbd364 )
    _853._udp.ns1.example.com. 3600 IN TLSA ( 3 1 1
      63cbfcafa3284cc46b1676a99dbc09d8acadf9050cf876de79ac1e5776bbd364 )
    _853._tcp.ns2.example.com. 3600 IN TLSA ( 3 1 1
      63cbfcafa3284cc46b1676a99dbc09d8acadf9050cf876de79ac1e5776bbd364 )
    _853._udp.ns2.example.com. 3600 IN TLSA ( 3 1 1
      63cbfcafa3284cc46b1676a99dbc09d8acadf9050cf876de79ac1e5776bbd364 )

4. The Authoritative Server of Resource-limited SLD Deploys Secure Service

[RFC7858] and [RFC9250] defined the encrypted DoT/DoQ service for client-to-recursive.¶

[RFC9539] discussed the extended deployment of encrypted recursive-to-authoritative DNS.¶

The authoritative server of resource-limited SLD deploys the DoQ/DoT service with self-signed PKI cerificate with TLS connection.¶

• The NS records of the resource-limited SLD should be written into the subjectAltName extension field of the self-signed PKI certificate.¶

• The public key information of the self-signed PKI cerificate is published on associated TLSA records of the NS.¶

• The associated TLSA records are DNSSEC-signed.¶

An alternative secure channel solution is [DNSCurve], embeded the raw public key into the NS records.¶

5. The Recursive Resolver Validates The Compact DNSSEC Records

The recursive resolver validates the DNSSEC trust chain (Root -> TLD -> SLD), and gains the trustworthy A/AAAA records of the NS records of the SLD.¶

The trustworthy A/AAAA records are the IP addresses of the authoritative server of the resource-limited SLD.¶

6. Setup Secure Channel for Recursive-to-Authoritative

The Recursive Resolver setup secure DoQ/DoT channel with the authoritative server of the resource-limited SLD:¶

• The recursive resolver connects to the trustworthy IP addresses of the authoritative server of the resource-limited SLD.¶

• The recursive resolver receives the self-signed certificate from the authoritative server, and extract the public key from the self-signed PKI certificate.¶

• The recursive resolver validates the TLSA RRSIGs of the NS records of the SLD with the DNSSEC trust chain.¶

• The recursive resolver validates the digest of extracted public key match the TLSA record.¶

• The recursive resolver setup secure DoQ/DoT channel with the authoritative server of the resource-limited SLD successfully.¶

• The recursive resolver make DNS query with the authoritative server of the resource-limited SLD on the secure DoQ/DoT channel.¶

7. Security Considerations

The compact DNSSEC scheme does not cover the entire zone and does not deploy NSEC/NSEC3.¶

Author's Address