DNS Object Exchange
draft-durand-object-exchange-00

Abstract

Abstract

This document defines an RR type to implement an architecture for the exchange of digitial objects using identifiers stored within the 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 June 22, 2018.

Copyright Notice

Copyright (c) 2017 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. The OX Resource Record
• 3.1. Description
• 3.1.1. Enterprise and Type fields
• 3.1.2. Location field
• 3.1.3. Media Type
• 3.1.4. Data
• 3.2. OX RDATA Wire Format
• 3.3. OX RDATA Presentation Format
• 4. Security Considerations
• 5. Privacy Considerations
• 6. Operational consideration
• 7. IANA Considerations
• 7.1. OX Type Registry
• 7.2. OX Location Type Registry
• 8. Acknowledgments
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

This document defines an RR type (“OX”) to implement an architecture for the exchange of digital objects using identifiers stored within the DNS. DNS. Each OX RR contains an object type that might be opaque and private to the producer and the consumer of the data and either the data (if small enough to fit in the RR) or a pointer on how to retrieve the actual data.

2. Terminology

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.

3. The OX Resource Record

3.1. Description

The Type value for the OX RR is TBD. The OX RR is class independent. No special processing is required within DNS servers or libraries.

The RDATA of the resource record comprises of five fields: OX-ENTERPRISE, OX-TYPE, OX-MEDIA-TYPE, OX-LOCATION and OX-DATA.

3.1.1. Enterprise and Type fields

The OX-ENTERPRISE and OX-TYPE fields are combined to indicate the semantic type of the OX record being represented by the RR. That semantic is private to the producer of data hosted on an authoritative DNS server and the application software using a DNS stub resolver to retrieve it.

The OX-ENTERPRISE field uses values as specified in the IANA SMI Network Management Private Enterprise Codes Registry [IANA-ENTERPRISE]. An exception to that is that the reserved value of zero (0) is used to indicate that the the OX-ENTERPRISE is not set.

Some commonly used values of OX-TYPE are registered in the IANA OX Type Registry Section 7.1, others are privately defined. As those private types might be used in cross-organization systems, use of the OX-ENTERPRISE field is RECOMMENDED to disambiguate types.

3.1.2. Location field

The OX-LOCATION signals how the OX-DATA field should be interpreted using the values specified in the OX Location Type Registry Section 7.2.

The value 0 is reserved.

For the value 1 (“Local”), the OX-DATA contains the actual OX object.

For the value 2 (“URI”) the OX-DATA contains a UTF-8 encoded string representing the URI from which the OX object can be obtained.

For the value 3 (“HDL”) the OX-DATA contains a UTF-8 encoded string representing the handle from the Handle System [RFC3650] from which the OX object can be obtained.

Other values might be defined in the future, for example for NFS, LDAP, etc…

DNS software implementing the OX RR type MUST NOT drop or otherwise refuse to handle the OX RRs containing an unknown or unsupported OX-LOCATION and MUST treat the OX-DATA portion of the RR as an abstract opaque field.

3.1.3. Media Type

The OX-MEDIA-TYPE field contains the Internet media type [RFC6838] for the OX object represented by this record.

If a non-Local object is retrieved over a protocol that supports inclusion of a media type value (e.g. an HTTP Content-Type header) then the client MUST use that value (if supplied) in preference to any value specified inside this resource record. In such case, the OX-MEDIA-TYPE MAY be set to NULL, length 0.

3.1.4. Data

The OX-DATA field contains either the object’s data, or some form of reference specifying from where the data can be obtained, per the OX-LOCATION field above.

3.2. OX RDATA Wire Format

    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 0: |                                                               |
    |                         OX-ENTERPRISE                         |
    |                                                               |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 4: |                                                               |
    |                            OX-TYPE                            |
    |                                                               |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
 8: |          OX-LOCATION          |          OX-MEDIA-TYPE        /
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
10: /                                                               /
    /                   OX-MEDIA-TYPE (continued)                   /
    /                                                               /
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    /                                                               /
    /                            OX-DATA                            /
    /                                                               /
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

OX-ENTERPRISE: a 32-bit unsigned integer in network order.

OX-TYPE: a 32-bit unsigned integer in network order.

OX-LOCATION: an 8-bit unsigned integer.

OX-MEDIA-TYPE: A <character-string> (see [RFC1035]). The first octet of the <character-string> contains the number of characters to follow.

OX-DATA: A variable length blob of binary data. The length of the OX-DATA is not contained within the wire format of the RR and has to be computed from the RDLENGTH of the entire RR once other fields have been taken into account.

3.3. OX RDATA Presentation Format

The OX-ENTERPRISE field is presented as an unsigned 32-bit decimal integer with range 0 - 4,294,967,295.

The OX-TYPE field is presented as an unsigned 32-bit decimal integer with range 0 - 4,294,967,295.

The OX-LOCATION field is presented as an unsigned 8-bit decimal integer with range 0 - 255.

The OX-MEDIA-TYPE field is presented as a single <character-string>.

The OX-DATA is presented as Base64 encoded data [RFC4648] unless the OX-DATA is empty in which case it is presented as a single dash character (“-“, ASCII 45). White space is permitted within Base64 data.

4. Security Considerations

The use of DNSSEC is encouraged to protect the integrity of the data contained in the OX RR type.

5. Privacy Considerations

Personally identifiable information (PII) data appearing in the OX-DATA field SHOULD be encrypted.

6. Operational consideration

Some OX records might contain large data that is only of interest to a single party, as such, caching those records does not provide much benefits and could be considered a denial of service attack on the caching resolver infrastructure. It is thus RECOMMENDED that the TTL associated with large OX RRs be set as small as possible to avoid caching.

7. IANA Considerations

7.1. OX Type Registry

IANA are requested to create the OX Type Registry with initial contents as follows:

Assignments in the 1-99,999 range in this registry require Expert Review.

7.2. OX Location Type Registry

IANA are requested to create the OX Location Type Registry with initial contents as follows:

Assignments in the 4-199 range in this registry require Expert Review.

8. Acknowledgments

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses