RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Reported (4)

RFC 8427, "Representing DNS Messages in JSON", July 2018

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: art

Errata ID: 5437
Status: Reported
Type: Technical

Reported By: Richard Gibson
Date Reported: 2018-07-24

Section 2 says:

2.1.  Message Object Members
   o  compressedQNAME - Object that describes the name with two optional
      values: "isCompressed" (with a value of 0 for no and 1 for yes)
      and "length" (with an integer giving the length in the message)

2.2.  Resource Record Object Members
   o  compressedNAME - Object that describes the name with two optional
      values: "isCompressed" (with a value of 0 for no and 1 for yes)
      and "length" (with an integer giving the length in the message)

It should say:

2.1.  Message Object Members
   o  compressedQNAME - Object that describes the name with two optional
      values: "isCompressed" (with a value of 0 for no and 1 for yes)
      and "length" (an integer giving the count of octets of the name in
      the message, including but not following compression pointers)

2.2.  Resource Record Object Members
   o  compressedNAME - Object that describes the name with two optional
      values: "isCompressed" (with a value of 0 for no and 1 for yes)
      and "length" (an integer giving the count of octets of the name in
      the message, including but not following compression pointers)

Notes:

"length in the message" is ambiguous for compressed names... taking for example a compressed domain name that represents "a.b.example.com." as 0x0161 0x0162 0xC00C (i.e., label "a", then label "b", then a pointer to "example.com." at offset 12), it could mean 1) the count of octets constituting the absolute name, including both compression pointers and labels referenced by them (6+13=19), or 2) the count of octets of the compression pointer plus immediately preceding labels (6), or 3) the count of octets of labels _preceding_ the compression pointer (4), or even 4) the offset in the compression pointer (12).

The above Corrected Text specifies option 3, because that interpretation allows for the most uniform treatment of compressed vs. uncompressed names.

Errata ID: 5438
Status: Reported
Type: Technical

Reported By: Richard Gibson
Date Reported: 2018-07-24

Section 2.3 says:

   o  rdataCNAME - A domain name

   o  rdataDNAME - A domain name

   o  rdataNS - A domain name

   o  rdataPTR - A domain name

   o  rdataTXT - A text value

   In addition, each of the following members has a value that is a
   space-separated string that matches the display format definition in
   the RFC that defines that RDATA type.  It is not expected that every
   receiving application will know how to parse these values.

   rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP,
   rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3,
   rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF,
   rdataSRV, rdataSSHFP, rdataTLSA

It should say:

   o  rdataCNAME - A domain name

   o  rdataDNAME - A domain name

   o  rdataNS - A domain name

   o  rdataPTR - A domain name

   In addition, each of the following members has a value that is a
   space-separated string that matches the presentation format
   definition in the RFC that defines that RDATA type.  It is not
   expected that every receiving application will know how to parse
   these values.

   rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP,
   rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3,
   rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF,
   rdataSRV, rdataSSHFP, rdataTLSA, rdataTXT

Notes:

"A text value" is insufficiently clear to describe the contents of a TXT record, which consists of "One or more <character-string>s". However, the immediately following description relying upon "display format" (corrected to "presentation format" per RFC 4034 and draft-ietf-dnsop-terminology-bis) _does_ cover it, so rdataTXT should move into the undifferentiated list.

Errata ID: 5439
Status: Reported
Type: Technical

Reported By: Richard Gibson
Date Reported: 2018-07-24

Section 2.6 says:

   o  If the member name does not end in "HEX", the value is a domain
      name encoded as DNS labels consisting of UTF-8 codepoints from
      U+0000 to U+007F.  Within a label, codepoints above U+007F and the
      codepoint U+002E (ASCII period) MUST be expressed using JSON's
      escaping rules within this set of codepoints.  Separation between
      labels is indicated with a period (codepoint U+002E).
      Internationalized Domain Name (IDN) labels are always expressed in
      their A-label form, as described in [RFC5890].

It should say:

   o  If the member name does not end in "HEX", the value is a domain
      name encoded in common display format as DNS labels separated by
      U+002E "." characters. Internationalized Domain Name (IDN) labels
      are always expressed in their A-label form, as described in
      [RFC5890]. Label characters with code points equal to U+0022
      QUOTATION MARK or U+005C REVERSE SOLIDUS or less than U+0020 SPACE
      MUST be expressed using the JSON escaping rules of [RFC8259].
      U+002E "." and U+005C "\" characters within labels MUST be
      preceded by a backslash escape as specified by [RFC1035] (and that
      backslash must itself be escaped for use in a JSON string,
      resulting in either the three-character sequence "\\." or the
      four-character sequence "\\\\", respectively).

Notes:

The Original Text appears to specify inclusion of raw characters less than U+0020 in JSON strings, which is disallowed by section 7 of RFC 8259.

Further, as specifically noted in section 8 of RFC 8259, "implementations that compare strings with escaped characters unconverted may incorrectly find that "a\\b" and "a\u005Cb" are not equal", a fact logically deducible from the preceding "when all the strings represented in a JSON text are composed entirely of Unicode characters [UNICODE] (however escaped), then that JSON text is interoperable in the sense that all software implementations that parse it will agree on the contents of names and of string values in objects and arrays" text. Therefore, _correct_ JSON implementations must not distinguish e.g. "a.b.example." from "a\u002Eb.example.", as seems to be required by the Original Text.

Errata ID: 5570
Status: Reported
Type: Technical

Reported By: Stéphane Bortzmeyer
Date Reported: 2018-12-07

Section 5.2 says:

"responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
                         "QDCOUNT": 1, "ANCOUNT": 1, "NSCOUNT": 1,

It should say:

"responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
                         "QDCOUNT": 1, "ANCOUNT": 2, "NSCOUNT": 1,

Notes:

ANCOUNT should, IMHO, be 2 and not 1. There are two resource records in the answer section.

True, the RFC explicitely says (section 8, 1st paragraph) that there can be a discrepancy between ANCOUNT and the actual number of records but I doubt this example was meant to illustrate this point.

Report New Errata