Private Use Q and Meta-types for DNS

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 10 May 2026.¶

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. Introduction

As described in DNS IANA Considerations [RFC6895], the DNS protocol supports three subcategories of Resource Record Types (RRTYPE): data types, QTYPES, and Meta-TYPES. There is a dedicated subrange of the RRTYPE space for Q and Meta-TYPES (128-155). The DNS protocol also defines a subrange of the RRTYPE space dedicated to private use (65280-65534), however this subrange has no corresponding subdivision into data versus Q and Meta-TYPES. This document proposes such a subdivision.¶

Informational: There are currently four Meta-TYPEs assigned: OPT [RFC6891], TSIG, TKEY, and NXNAME. There are currently five QTYPEs assigned: * (ALL/ANY), MAILA, MAILB, AXFR, and IXFR. Notably the OPT meta-type is not assigned from the Q and Meta-Type space (presumably because it predated the current RR type space classification).¶

Many resolvers implementations treat queries for Q and Meta-types specially. If the query is for an unknown Q or Meta-type or for a Meta-type with undefined (or forbidden) query behavior, the resolver will treat it like an invalid query. It will not attempt to perform iterative resolution for it, and return an error back to the querier, typically format error (FORMERR). This kind of behavior is not possible with private types, since the private RR type space has no differentiation of data types versus Q and Meta-TYPES. This makes it difficult to experiment with new Q or Meta-TYPES utilizing private RR types. Notably, this posed challenges when the NXNAME Meta-type [RFC9824] was deployed in the field using a private RR type code, prior to standardization.¶

2. Private Q and Meta-Types Range

The definition of new Q and Meta-types is expected to be quite infrequent, so only a small subrange should be sufficient, e.g. 16 code points. We present two options, and should choose one.¶

Option 1: Subset of "Reserved for Private Use" Range:¶

        65280-65295     Private Use Q amd Meta-types             (16)
        65296-65534     Private Use Data-types                  (239)

Option 2: Subset of "Reserved for Future Use" Range, immediately before and adjacent to the current Private Use Range:¶

        61440-65263     Reserved for future use (IETF review)
        65264-65279     Private Use Q and Meta-types

3. Handling Unknown Q and Meta-Types

DNS servers MUST return an error when receiving a query for an unknown Q or Meta-Type. This applies generally to both private and non-private Q and Meta-Types. The recommended response code is Format Error (FORMERR). In particular, resolvers should not attempt to perform iterative resolution for such queries.¶

4. Updates to RFCs

Update the RR type ranges described in RFC 6895 with the information from Section 2.¶

5. Open Questions

Is this proposal best described in a separate RFC, or should it instead be part of an update to the DNS IANA Considerations RFC [RFC6895]?¶

6. Security Considerations

None.¶

7. IANA Considerations

See Section 2.¶

Authors' Addresses