A Concise Binary Object Representation (CBOR) of DNS Messages
draft-lenders-dns-cbor-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Martine Sophie Lenders , Thomas C. Schmidt , Matthias Wählisch | ||
| Last updated | 2022-10-24 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lenders-dns-cbor-01
CBOR M. S. Lenders
Internet-Draft FU Berlin
Intended status: Standards Track T. C. Schmidt
Expires: 27 April 2023 HAW Hamburg
M. Wählisch
FU Berlin
24 October 2022
A Concise Binary Object Representation (CBOR) of DNS Messages
draft-lenders-dns-cbor-01
Abstract
This document specifies a compressed data format of DNS messages
using the Concise Binary Object Representation [RFC7049]. The
primary purpose is to keep DNS messages small in constrained
networks.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://anr-bmbf-
pivot.github.io/draft-lenders-dns-cbor/draft-lenders-dns-cbor.html.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/.
Discussion of this document takes place on the CBOR Working Group
mailing list (mailto:cbor@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/cbor/. Subscribe at
https://www.ietf.org/mailman/listinfo/cbor/.
Source for this draft and an issue tracker can be found at
https://github.com/anr-bmbf-pivot/draft-lenders-dns-cbor.
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/.
Lenders, et al. Expires 27 April 2023 [Page 1]
Internet-Draft dns+cbor October 2022
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 April 2023.
Copyright Notice
Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. CBOR Representations (application/dns+cbor) . . . . . . . . . 4
3.1. Domain Name Representation . . . . . . . . . . . . . . . 4
3.2. DNS Queries . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Standard DNS Resource Records (RRs) . . . . . . . . . . . 5
3.4. DNS Responses . . . . . . . . . . . . . . . . . . . . . . 6
3.5. EDNS(0) . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Name and Address Compression with Packed CBOR . . . . . . 7
3.6.1. Table Setup . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. Media Type Registration . . . . . . . . . . . . . . . . . 10
5.1.1. "application/dns+cbor" . . . . . . . . . . . . . . . 10
5.1.2. "application/dns+cbor-packed" . . . . . . . . . . . . 11
5.2. CoAP Content-Format Registration . . . . . . . . . . . . 12
5.2.1. "application/dns-cbor" . . . . . . . . . . . . . . . 12
5.2.2. "application/dns+cbor-packed" . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
A.1. DNS Queries . . . . . . . . . . . . . . . . . . . . . . . 14
A.2. DNS Responses . . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Lenders, et al. Expires 27 April 2023 [Page 2]
Internet-Draft dns+cbor October 2022
B.1. Since draft-lenders-dns-cbor-00 . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
In constrained networks [RFC7228], the link layer may restrict the
payload sizes to only a few hundreds bytes. Encrypted DNS
resolution, such as DNS over HTTPS (DoH) [RFC8484] or DNS over CoAP
(DoC) [I-D.ietf-core-dns-over-coap], may lead to DNS message sizes
that exceed this limit, even when implementing header compression
such as 6LoWPAN IPHC [RFC6282] or SCHC [RFC8724], [RFC8824].
Although adoption layers such as 6LoWPAN [RFC4944] or SCHC [RFC8724]
offer fragmentation to comply with small MTUs, fragmentation should
be avoided in constrained networks, because fragmentation combined
with high packet loss multiplies the loss. As such, a compression
format for DNS messages is needed.
This document specifies a compressed data format for DNS messages.
DNS messages are encoded in Concise Binary Object Representation
(CBOR) [RFC7049] and, additionally, unnecessary or redundant
information is removed. To use the outcome of this specification in
DoH and DoC, this document also specifies a Media Type header for DoH
and a Content-Format option for DoC.
2. Terminology
CBOR types (unsigned integer, byte string, text string, arrays, etc.)
are used as defined in [RFC7049].
TBD DNS server and client.
A DNS query is a message that queries DNS information from an
upstream DNS resolver.
The term "constrained networks" is used as defined in [RFC7228].
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.
Lenders, et al. Expires 27 April 2023 [Page 3]
Internet-Draft dns+cbor October 2022
3. CBOR Representations (application/dns+cbor)
To keep overhead minimal, a DNS message is represented as CBOR
arrays. All CBOR items used in this specification are of definite
length. CBOR arrays that do not follow the length definitions of
this or follow-up specifications, MUST be silently ignored. It is
assumed that DNS query and DNS response are distinguished message
types and that the query can be mapped to the response by the
transport protocol of choice. To define the representation of binary
objects we use the Concise Data Definition Language (CDDL) [RFC8610].
3.1. Domain Name Representation
Domain names are represented in their commonly known string format
(e.g., "example.org", see Section 2.3.1 in [RFC1035]) and in IDNA
encoding [RFC5890] as a text string. For the purpose of this
document, domain names remain case-insensitive as specified in
[RFC1035].
The representation of a domain name is defined in Figure 1.
domain-name = tstr .regexp "([^.]+\.)*[^.]+"
Figure 1: Domain Name Definition
3.2. DNS Queries
DNS queries are encoded as CBOR arrays containing up to 3 entries in
the following order: An optional transaction ID (as unsigned
integer), the name (as text string, see Section 3.1), an optional
record type (as unsigned integer), and an optional record class (as
unsigned integer).
If the transaction ID is elided, the value 0 is assumed. It MUST be
included and set to an unpredictable value less than $2^{32}$, if the
DNS transport can not ensure the prevention of DNS response spoofing.
An example for such a transport is unencrypted DoC (see
[I-D.ietf-core-dns-over-coap], Section 6).
If the record type is elided, record type AAAA as specified in
[RFC3596] is assumed. If the record class is elided, record class IN
as specified in [RFC1035] is assumed. If a record class is required,
the record type MUST also be provided.
The representation of a DNS query is defined in Figure 2.
Lenders, et al. Expires 27 April 2023 [Page 4]
Internet-Draft dns+cbor October 2022
type-spec = (
record-type: uint,
? record-class: uint,
)
dns-question = (
? id: uint,
name: domain-name,
? type-spec,
)
dns-query = [dns-question]
Figure 2: DNS Query Definition
3.3. Standard DNS Resource Records (RRs)
DNS resource records are encoded as CBOR arrays containing 2 to 5
entries in the following order: An optional name (as text string, see
Section 3.1), a TTL (as unsigned integer), an optional record type
(as unsigned integer), an optional record class (as unsigned
integer), and lastly a record data entry (as byte string or text
string).
If the first element of the resource record is a string, the first
element is a name. If the name is elided, the name from the query,
either derived from transport context or the provided question
section, see Section 3.4, is assumed. If the record type is elided,
the record type from the question is assumed. If record class is
elided, the record class from the question is assumed. If a record
class is required, the record type MUST also be provided.
The byte format of the record data follows the wire format as
specified in Section 3.3 [RFC1035] (or other specifications of the
respective record type). Note that this format does not include the
RDLENGTH field from [RFC1035] as this value is encoded in the length
field of the CBOR byte string.
If and only if the record data represents a domain name (e.g., for
CNAME or PTR records), the record data MAY be represented as a text
string as specified in Section 3.1. This can save 1 bytes of data,
because the byte representation of DNS names requires both an
additional byte to define the length of the first name component as
well as a 0 byte at the end of the name. With CBOR on the other hand
only 1 byte is required to define type and length of the text string.
The representation of a DNS resource records is defined in Figure 3.
Lenders, et al. Expires 27 April 2023 [Page 5]
Internet-Draft dns+cbor October 2022
rr = (
? name: domain-name,
ttl: uint,
? type-spec,
rdata: bstr / domain-name,
)
dns-rr = [rr]
Figure 3: DNS Resource Record Definition
3.4. DNS Responses
DNS responses are encoded as a CBOR array containing up to 5 entries.
The first entry MAY be an unsigned integer, representing the
transaction ID of the response. If CBOR array is a response to a
query that contains a transaction ID, it MUST be included and set to
the corresponding value present in the query. If it is not included,
the transaction ID is implied to be 0. The remaining 4 entries are
arrays:
If only 1 array is included, then this is the DNS answer section
represented as an array of one or more DNS Resource Records (see
Section 3.3).
If 2 arrays are included, then the first entry is a question section
and the second entry is an answer section. The question section is
encoded like a DNS query as specified in Section 3.2, the answer
section is represented as an array of one or more DNS Resource
Records (see Section 3.3).
If 3 arrays are included, then the first section is a question
section, the second an answer section, and the third an additional
section (TBD: back choice to favor additional section by empirical
data). Again, the question section is encoded like a DNS query as
specified in Section 3.2 and both answer and additional sections are
represented each as an array of one or more DNS Resource Records (see
Section 3.3).
If 4 arrays are included, then the first section is a question
section, the second an answer section, the third an authority
section, and the fourth an additional section (TBD: back by empirical
data). They follow the specification of 3 arrays in the answer. The
authority section is also represented as an array of one or more DNS
Resource Records (see Section 3.3).
Lenders, et al. Expires 27 April 2023 [Page 6]
Internet-Draft dns+cbor October 2022
extra-sections = (
? authority: [+ dns-rr],
additional: [+ dns-rr],
)
sections = ((
? id: uint,
answer: [+ dns-rr],
) // (
? id: uint,
question: dns-query,
answer: [+ dns-rr],
? extra-sections,
))
dns-response = [sections]
Figure 4: DNS Response Definition
3.5. EDNS(0)
TBD, do we need special formatting here?
3.6. Name and Address Compression with Packed CBOR
If both DNS server and client support packed CBOR
[I-D.ietf-cbor-packed], it MAY be used for name and address
compression in DNS responses.
A DNS client uses media type "application/dns+cbor-packed" to
negotiate (see, e.g., [RFC9110] or [RFC7252], Section 5.5.4) with the
DNS server if the server supports packed CBOR. If it does, it MAY
request the response to be in packed CBOR (media type "applicaton/
dns+cbor-packed"). The server then SHOULD reply with the response in
packed CBOR.
The representation of DNS responses in packed CBOR differs, in that
responses are now represented as a CBOR array of two arrays. The
first array is a packing table that is used both as shared item table
and argument table (see [I-D.ietf-cbor-packed], Section 2.1), the
second is the compressed response.
The representation of a packed DNS response is defined in Figure 5.
compr-dns-response = any /TBD; how to express packed CBOR in CDDL?/
packed-dns-response = [[pack-table], compr-dns-response]
pack-table = any
Figure 5: Definition of DNS messages in packed CBOR
Lenders, et al. Expires 27 April 2023 [Page 7]
Internet-Draft dns+cbor October 2022
If an index in the packing table is referenced with shared item
reference ([I-D.ietf-cbor-packed], Section 2.2) a decoder uses the
packing table as a shared item table. If an index in the packing
table is referenced as an argument ([I-D.ietf-cbor-packed], Sections
2.3 and 4), a decoder uses the packing table as an argument table.
Discussion TBD:
* For queries, as they are only one question, i.e. at most one value
of each at most, compression is not necessary.
* Address and name compression are mostly about affix compression
(i.e. straight/inverse referencing) \ ==> For occasions were value
is the affix (e.g., "example.org" in ANY example in Appendix A.2)
use shared item referencing to argument table to safe bytes (no
extra shared item table, no, e.g., 216(""), just simple(0))
- *Example:* Using Basic Packed CBOR ([I-D.ietf-cbor-packed],
section 3.1):
o 131 bytes (Basic Packed CBOR)
o 200 bytes (plain CBOR, see Appendix A.2)
o 194 bytes (wire-format)
113(
[
["_coap._udp.local", "example.org", 3600, 28, 2],
[h'20010db800000000000000000000', simple(1)],
[
[simple(1), 12, 1],
[[simple(1), simple(0)]],
[
[simple(1), simple(4), 217("ns1.")],
[simple(1), simple(4), 217("ns2.")]
],
[
[simple(0), simple(1), simple(3), 6(h'0001')],
[simple(0), simple(1), simple(3), 6(h'0002')],
[217("ns1."), simple(1), simple(3), 6(h'0035')],
[217("ns2."), simple(1), simple(3), 6(h'3535')]
]
]
]
)
Lenders, et al. Expires 27 April 2023 [Page 8]
Internet-Draft dns+cbor October 2022
vs. application/dns+cbor-packed (shared and argument table as
one) 126 bytes:
[
[
h'20010db800000000000000000000',
"_coap._udp.local" "example.org", 3600, 28, 2
],
[
[simple(1), 12, 1],
[[simple(3), simple(1)]],
[
[simple(2), simple(5), 218("ns1.")],
[simple(2), simple(5), 218("ns2.")]
],
[
[simple(1), simple(3), simple(4), 6(h'0001')],
[simple(1), simple(3), simple(4), 6(h'0002')],
[218("ns1."), simple(3), simple(4), 6(h'0035')],
[218("ns2."), simple(3), simple(4), 6(h'3535')]
]
]
]
3.6.1. Table Setup
TBD How to construct the packing table, here's a sketch:
* Find most often used prefix and values
- Probably some threshold needed, to prevent, e.g., 1 byte
prefixes filling valuable table space
* Sort descending by number of occurrences and length
- Long prefixes should take precedence for index 0 for Tag 6
usage
4. Security Considerations
TODO Security
5. IANA Considerations
Lenders, et al. Expires 27 April 2023 [Page 9]
Internet-Draft dns+cbor October 2022
5.1. Media Type Registration
This document registers two media type for the serialization format
of DNS messages in CBOR. They follow the procedures specified in
[RFC6838].
5.1.1. "application/dns+cbor"
Type name: application
Subtype name: dns+cbor
Required parameters: None
Optional parameters: None
Encoding considerations: Must be encoded as using [RFC7049]. See
[TBD-this-spec] for details.
Security considerations: See Section 4 of this draft
Interoperability considerations: TBD
Published specification: [TBD-this-spec]
Applications that use this media type: TBD DNS over X systems
Fragment Identifier Considerations: TBD
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): dnsc
Macintosh file type code(s): none
Person & email address to contact for further information: Martine S.
Lenders m.lenders@fu-berlin.de (mailto:m.lenders@fu-berlin.de)
Intended usage: COMMON
Restrictions on Usage: None?
Author: Martine S. Lenders m.lenders@fu-berlin.de
(mailto:m.lenders@fu-berlin.de)
Lenders, et al. Expires 27 April 2023 [Page 10]
Internet-Draft dns+cbor October 2022
Change controller: Martine S. Lenders m.lenders@fu-berlin.de
(mailto:m.lenders@fu-berlin.de)
Provisional registrations? No
5.1.2. "application/dns+cbor-packed"
Type name: application
Subtype name: dns+cbor-packed
Required parameters: None
Optional parameters: None
Encoding considerations: Must be encoded as using [RFC7049]. See
[TBD-this-spec] for details.
Security considerations: See Section 4 of this draft
Interoperability considerations: TBD
Published specification: [TBD-this-spec]
Applications that use this media type: TBD DNS over X systems
Fragment Identifier Considerations: TBD
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): dnsc
Macintosh file type code(s): none
Person & email address to contact for further information: Martine S.
Lenders m.lenders@fu-berlin.de (mailto:m.lenders@fu-berlin.de)
Intended usage: COMMON
Restrictions on Usage: None?
Author: Martine S. Lenders m.lenders@fu-berlin.de
(mailto:m.lenders@fu-berlin.de)
Lenders, et al. Expires 27 April 2023 [Page 11]
Internet-Draft dns+cbor October 2022
Change controller: Martine S. Lenders m.lenders@fu-berlin.de
(mailto:m.lenders@fu-berlin.de)
Provisional registrations? No
5.2. CoAP Content-Format Registration
IANA is requested to assign CoAP Content-Format ID for the new DNS
message media types in the "CoAP Content-Formats" sub-registry,
within the "CoRE Parameters" registry [RFC7252], corresponding the
"application/dns+cbor" media types "application/dns+cbor" and
"application/dns+cbor-packed"" specified in Section 5.1:
5.2.1. "application/dns-cbor"
Media-Type: application/dns+cbor
Encoding: -
Id: TBD
Reference: [TBD-this-spec]
5.2.2. "application/dns+cbor-packed"
Media-Type: application/dns+cbor-packed
Encoding: -
Id: TBD
Reference: [TBD-this-spec]
6. References
6.1. Normative References
[I-D.ietf-cbor-packed]
Bormann, C., "Packed CBOR", Work in Progress, Internet-
Draft, draft-ietf-cbor-packed-07, 24 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-cbor-
packed-07>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
Lenders, et al. Expires 27 April 2023 [Page 12]
Internet-Draft dns+cbor October 2022
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/rfc/rfc3596>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<https://www.rfc-editor.org/rfc/rfc5890>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/rfc/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
6.2. Informative References
[I-D.ietf-core-dns-over-coap]
Lenders, M. S., Amsüss, C., Gündoğan, C., Schmidt, T. C.,
and M. Wählisch, "DNS over CoAP (DoC)", Work in Progress,
Internet-Draft, draft-ietf-core-dns-over-coap-01, 24
October 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-dns-over-coap-01>.
Lenders, et al. Expires 27 April 2023 [Page 13]
Internet-Draft dns+cbor October 2022
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/rfc/rfc4944>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/rfc/rfc6282>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/rfc/rfc7228>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/rfc/rfc8484>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", RFC 8724,
DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/rfc/rfc8724>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/rfc/rfc8824>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
Appendix A. Examples
A.1. DNS Queries
A DNS query of the record AAAA in class IN for name "example.org" is
represented in CBOR extended diagnostic notation (EDN) (see Section 8
in [RFC7049] and Appendix G in [RFC8610]) as follows:
["example.org"]
A query of an A record for the same name is represented as
Lenders, et al. Expires 27 April 2023 [Page 14]
Internet-Draft dns+cbor October 2022
["example.org", 1]
A query of ANY record for that name is represented as
["example.org", 255, 255]
A.2. DNS Responses
The responses to the examples provided in Appendix A.1 are shown
below. We use the CBOR extended diagnostic notation (EDN) (see
Section 8 in [RFC7049] and Appendix G in [RFC8610]).
To represent an AAAA record with TTL 300 seconds for the IPv6 address
2001:db8::1, a minimal response to ["example.org"] could be
[[[300, h'20010db8000000000000000000000001']]]
In this case, the name is derived from the query.
If the name or the context is required, the following response would
also be valid:
[[["example.org", 300, h'20010db8000000000000000000000001']]]
If the query can not be mapped to the response for some reason, a
response would look like:
[["example.org"], [[300, h'20010db8000000000000000000000001']]]
To represent a minimal response of an A record with TTL 3600 seconds
for the IPv4 address 192.0.2.1, a minimal response to ["example.org",
1] could be
[[300, h'c0000201']]
Note that here also the 1 of record type A can be elided, as this
record type is specified in the question section.
Lastly, a response to ["example.org", 255, 255] could be
Lenders, et al. Expires 27 April 2023 [Page 15]
Internet-Draft dns+cbor October 2022
[
["example.org", 12, 1],
[[3600, "_coap._udp.local"]],
[
[3600, 2, "ns1.example.org"],
[3600, 2, "ns2.example.org"]
],
[
[
"_coap._udp.local", 3600, 28,
h'20010db8000000000000000000000001'
],
[
"_coap._udp.local", 3600, 28,
h'20010db8000000000000000000000002'
],
[
"ns1.example.org", 3600, 28,
h'20010db8000000000000000000000035'
],
[
"ns2.example.org", 3600, 28,
h'20010db8000000000000000000003535'
]
]
]
This one advertises two local CoAP servers (identified by service
name _coap._udp.local) at 2001:db8::1 and 2001:db8::2 and two
nameservers for the example.org domain, ns1.example.org at
2001:db8::35 and ns2.example.org at 2001.db8::3535. Each of the
transmitted records has a TTL of 3600 seconds.
Appendix B. Change Log
B.1. Since draft-lenders-dns-cbor-00
(https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-00)
* Add support for DNS transaction IDs
* Name and Address compression utilizing CBOR-packed
* Minor fixes to CBOR EDN and CDDL
Acknowledgments
TODO acknowledge.
Lenders, et al. Expires 27 April 2023 [Page 16]
Internet-Draft dns+cbor October 2022
* Carsten Bormann
Authors' Addresses
Martine Sophie Lenders
Freie Universität Berlin
Email: m.lenders@fu-berlin.de
Thomas C. Schmidt
HAW Hamburg
Email: t.schmidt@haw-hamburg.de
Matthias Wählisch
Freie Universität Berlin
Email: m.waehlisch@fu-berlin.de
Lenders, et al. Expires 27 April 2023 [Page 17]