1 Internet Engineering Task Force (IETF)                        P. Hoffman   
    2 Request for Comments: 8427                                         ICANN   
    3 Category: Informational                                        July 2018   
    4 ISSN: 2070-1721                                                            
    5                                                                            
    6                                                                            
    7                    Representing DNS Messages in JSON                       
    8                                                                            
    9 Abstract                                                                   
   10                                                                            
   11    Some applications use DNS messages, or parts of DNS messages, as        
   12    data.  For example, a system that captures DNS queries and responses    
   13    might want to be able to easily search them without having to decode    
   14    the messages each time.  Another example is a system that puts          
   15    together DNS queries and responses from message parts.  This document   
   16    describes a general format for DNS message data in JSON.  Specific      
   17    profiles of the format in this document can be described in other       
   18    documents for specific applications and usage scenarios.                
   19                                                                            
   20 Status of This Memo                                                        
   21                                                                            
   22    This document is not an Internet Standards Track specification; it is   
   23    published for informational purposes.                                   
   24                                                                            
   25    This document is a product of the Internet Engineering Task Force       
   26    (IETF).  It represents the consensus of the IETF community.  It has     
   27    received public review and has been approved for publication by the     
   28    Internet Engineering Steering Group (IESG).  Not all documents          
   29    approved by the IESG are candidates for any level of Internet           
   30    Standard; see Section 2 of RFC 7841.                                    
   31                                                                            
   32    Information about the current status of this document, any errata,      
   33    and how to provide feedback on it may be obtained at                    
   34    https://www.rfc-editor.org/info/rfc8427.                                
   35                                                                            
   36                                                                            
   37                                                                            
   38                                                                            
   39                                                                            
   40                                                                            
   41                                                                            
   42                                                                            
   43                                                                            
   44                                                                            
   45                                                                            
   46                                                                            
   47                                                                            
   48                                                                            
   49                                                                            
   50                                                                            
   51                                                                            
   52 Hoffman                       Informational                     [Page 1]   

   53 RFC 8427                       DNS in JSON                     July 2018   
   54                                                                            
   55                                                                            
   56 Copyright Notice                                                           
   57                                                                            
   58    Copyright (c) 2018 IETF Trust and the persons identified as the         
   59    document authors.  All rights reserved.                                 
   60                                                                            
   61    This document is subject to BCP 78 and the IETF Trust's Legal           
   62    Provisions Relating to IETF Documents                                   
   63    (https://trustee.ietf.org/license-info) in effect on the date of        
   64    publication of this document.  Please review these documents            
   65    carefully, as they describe your rights and restrictions with respect   
   66    to this document.  Code Components extracted from this document must    
   67    include Simplified BSD License text as described in Section 4.e of      
   68    the Trust Legal Provisions and are provided without warranty as         
   69    described in the Simplified BSD License.                                
   70                                                                            
   71 Table of Contents                                                          
   72                                                                            
   73    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   
   74      1.1.  Design of the Format  . . . . . . . . . . . . . . . . . .   3   
   75      1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5   
   76    2.  JSON Format for DNS Messages  . . . . . . . . . . . . . . . .   5   
   77      2.1.  Message Object Members  . . . . . . . . . . . . . . . . .   5   
   78      2.2.  Resource Record Object Members  . . . . . . . . . . . . .   6   
   79      2.3.  Specific RDATA Field Members  . . . . . . . . . . . . . .   7   
   80      2.4.  The Message and Its Parts as Octets . . . . . . . . . . .   8   
   81      2.5.  Additional Message Object Members . . . . . . . . . . . .   8   
   82      2.6.  Name Fields . . . . . . . . . . . . . . . . . . . . . . .   9   
   83    3.  JSON Format for a Paired DNS Query and Response . . . . . . .   9   
   84    4.  Streaming DNS Objects . . . . . . . . . . . . . . . . . . . .   9   
   85    5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10   
   86      5.1.  Example of the Format of a DNS Query  . . . . . . . . . .  10   
   87      5.2.  Example of the Format of a Paired DNS Query and Response   11   
   88    6.  Local Format Policy . . . . . . . . . . . . . . . . . . . . .  12   
   89    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12   
   90      7.1.  Media Type Registration of application/dns+json . . . . .  12   
   91    8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13   
   92    9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  14   
   93    10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14   
   94      10.1.  Normative References . . . . . . . . . . . . . . . . . .  14   
   95      10.2.  Informative References . . . . . . . . . . . . . . . . .  15   
   96    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15   
   97    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15   
   98                                                                            
   99                                                                            
  100                                                                            
  101                                                                            
  102                                                                            
  103                                                                            
  104                                                                            
  105                                                                            
  106                                                                            
  107 Hoffman                       Informational                     [Page 2]   

  108 RFC 8427                       DNS in JSON                     July 2018   
  109                                                                            
  110                                                                            
  111 1.  Introduction                                                           
  112                                                                            
  113    The DNS message format is defined in [RFC1035].  DNS queries and DNS    
  114    responses have exactly the same structure.  Many of the field names     
  115    and data type names given in [RFC1035] are commonly used in             
  116    discussions of DNS.  For example, it is common to hear things like      
  117    "the query had a QNAME of 'example.com'" or "the RDATA has a simple     
  118    structure".                                                             
  119                                                                            
  120    There are hundreds of data-interchange formats for serializing          
  121    structured data.  Currently, JSON [RFC8259] is quite popular for many   
  122    types of data, particularly data that has named subfields and           
  123    optional parts.                                                         
  124                                                                            
  125    This document uses JSON to describe DNS messages.  It also defines      
  126    how to describe a paired DNS query and response and how to stream DNS   
  127    objects.                                                                
  128                                                                            
  129 1.1.  Design of the Format                                                 
  130                                                                            
  131    There are many ways to design a data format.  This document uses a      
  132    specific design methodology based on the DNS format.                    
  133                                                                            
  134    o  The format is based on JSON objects in order to allow a writer to    
  135       include or exclude parts of the format at will.  No object members   
  136       are ever required.                                                   
  137                                                                            
  138    o  This format is purposely overly general.  A protocol or              
  139       application that uses this format is expected to use only a subset   
  140       of the items defined here; it is expected to define its own          
  141       profile from this format.                                            
  142                                                                            
  143    o  The format allows transformation through JSON that would permit      
  144       re-creation of the wire content of the message.                      
  145                                                                            
  146    o  All members whose values are always 16 bits or shorter are           
  147       represented by JSON numbers with no minus sign, no fractional part   
  148       (except in fields that are specifically noted below), and no         
  149       exponent part.  One-bit values are represented as JSON numbers       
  150       whose values are either 0 or 1.  See Section 6 of [RFC8259] for      
  151       more detail on JSON numbers.                                         
  152                                                                            
  153    o  The JSON representation of the objects described in this document    
  154       is limited to the UTF-8 codepoints from U+0000 to U+007F.  This is   
  155       done to prevent an attempt to use a different encoding such as       
  156       UTF-8 for octets in names or data.                                   
  157                                                                            
  158                                                                            
  159                                                                            
  160                                                                            
  161                                                                            
  162 Hoffman                       Informational                     [Page 3]   

  163 RFC 8427                       DNS in JSON                     July 2018   
  164                                                                            
  165                                                                            
  166    o  Items that have string values can have "HEX" appended to their       
  167       names to indicate a non-ASCII encoding of the value.  Names that     
  168       end in "HEX" have values stored in base16 encoding (hex with         
  169       uppercase letters) defined in [RFC4648].  This is particularly       
  170       useful for RDATA that is binary.                                     
  171                                                                            
  172    o  All field names in this format are used as in [RFC1035], including   
  173       their capitalization.  Names not defined in [RFC1035] generally      
  174       use "camel case".                                                    
  175                                                                            
  176    o  The same data may be represented in multiple object members          
  177       multiple times.  For example, there is a member for the octets of    
  178       the DNS message header, and there are members for each named part    
  179       of the header.  A message object can thus inadvertently have         
  180       inconsistent data, such as a header member whose value does not      
  181       match the value of the first bits in the entire message member.      
  182                                                                            
  183    o  It is acceptable that there are multiple ways to represent the       
  184       same data.  This is done so that application designers can choose    
  185       what fields are best for them and even so that they are able to      
  186       allow multiple representations.  That is, there is no "better" way   
  187       to represent DNS data, so this design doesn't prefer specific        
  188       representations.                                                     
  189                                                                            
  190    o  The design explicitly allows for the description of malformed DNS    
  191       messages.  This is important for systems that are logging messages   
  192       seen on the wire, particularly messages that might be used as part   
  193       of an attack.  A few examples of malformed DNS messages include:     
  194                                                                            
  195       *  a resource record (RR) that has an RDLENGTH of 4 but an RDATA     
  196          whose length is longer than 4 (if it is the last RR in a          
  197          message)                                                          
  198                                                                            
  199       *  a DNS message whose QDCOUNT is 0                                  
  200                                                                            
  201       *  a DNS message whose ANCOUNT is large but there are insufficient   
  202          bytes after the header                                            
  203                                                                            
  204       *  a DNS message whose length is less than 12 octets, meaning it     
  205          doesn't even have a full header                                   
  206                                                                            
  207    o  An object in this format can have zero or more of the members        
  208       defined here; that is, no members are required by the format         
  209       itself.  Instead, profiles that use this format might have           
  210       requirements for mandatory members, optional members, and            
  211       prohibited members from the format.  Also, this format does not      
  212       prohibit members that are not defined in this format; profiles of    
  213       the format are free to add new members in the profile.               
  214                                                                            
  215                                                                            
  216                                                                            
  217 Hoffman                       Informational                     [Page 4]   

  218 RFC 8427                       DNS in JSON                     July 2018   
  219                                                                            
  220                                                                            
  221    o  This document defines DNS messages, not the zone files described     
  222       in [RFC1035].  A different specification could be written to         
  223       extend it to represent zone files.  Note that DNS zone files allow   
  224       escaping of octet values using "\DDD" notation, but this             
  225       specification does not allow that; when encoding from a zone file    
  226       to this JSON format, you need to do a conversion for many types of   
  227       values.                                                              
  228                                                                            
  229 1.2.  Terminology                                                          
  230                                                                            
  231    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",     
  232    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and    
  233    "OPTIONAL" in this document are to be interpreted as described in       
  234    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all      
  235    capitals, as shown here.                                                
  236                                                                            
  237 2.  JSON Format for DNS Messages                                           
  238                                                                            
  239    The following gives all of the members defined for a DNS message.  It   
  240    is organized approximately by levels of the DNS message.                
  241                                                                            
  242 2.1.  Message Object Members                                               
  243                                                                            
  244    o  ID - Integer whose value is 0 to 65535                               
  245                                                                            
  246    o  QR - Boolean                                                         
  247                                                                            
  248    o  Opcode - Integer whose value is 0 to 15                              
  249                                                                            
  250    o  AA - Boolean                                                         
  251                                                                            
  252    o  TC - Boolean                                                         
  253                                                                            
  254    o  RD - Boolean                                                         
  255                                                                            
  256    o  RA - Boolean                                                         
  257                                                                            
  258    o  AD - Boolean                                                         
  259                                                                            
  260    o  CD - Boolean                                                         
  261                                                                            
  262    o  RCODE - Integer whose value is 0 to 15                               
  263                                                                            
  264    o  QDCOUNT - Integer whose value is 0 to 65535                          
  265                                                                            
  266    o  ANCOUNT - Integer whose value is 0 to 65535                          
  267                                                                            
  268    o  NSCOUNT - Integer whose value is 0 to 65535                          
  269                                                                            
  270                                                                            
  271                                                                            
  272 Hoffman                       Informational                     [Page 5]   

  273 RFC 8427                       DNS in JSON                     July 2018   
  274                                                                            
  275                                                                            
  276    o  ARCOUNT - Integer whose value is 0 to 65535                          
  277                                                                            
  278    o  QNAME - String of the name of the first Question section of the      
  279       message; see Section 2.6 for a description of the contents           
  280                                                                            

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.

  281    o  compressedQNAME - Object that describes the name with two optional   
  282       values: "isCompressed" (with a value of 0 for no and 1 for yes)      
  283       and "length" (with an integer giving the length in the message)      
  284                                                                            
  285    o  QTYPE - Integer whose value is 0 to 65535, of the QTYPE of the       
  286       first Question section of the message                                
  287                                                                            
  288    o  QTYPEname - String whose value is from the IANA "Resource Record     
  289       (RR) TYPEs" registry or has the format in [RFC3597]; this is case    
  290       sensitive, so "AAAA", not "aaaa"                                     
  291                                                                            
  292    o  QCLASS - Integer whose value is 0 to 65535, of the QCLASS of the     
  293       first Question section of the message                                
  294                                                                            
  295    o  QCLASSname - String whose value is "IN", "CH", or "HS" or that has   
  296       the format in [RFC3597]                                              
  297                                                                            
  298    o  questionRRs - Array of zero or more resource records or rrSet        
  299       objects in the Question section                                      
  300                                                                            
  301    o  answerRRs - Array of zero or more resource records or rrSet          
  302       objects in the Answer section                                        
  303                                                                            
  304    o  authorityRRs - Array of zero or more resource records or rrSet       
  305       objects in the Authority section                                     
  306                                                                            
  307    o  additionalRRs - Array of zero or more resource records or rrSet      
  308       objects in the Additional section                                    
  309                                                                            
  310 2.2.  Resource Record Object Members                                       
  311                                                                            
  312    A resource record is represented as an object with the following        
  313    members.                                                                
  314                                                                            
  315    o  NAME - String of the NAME field of the resource record; see          
  316       Section 2.6 for a description of the contents                        
  317                                                                            
line-281 Richard Gibson(Technical Erratum #5437) [Held for Document Update]
based on outdated version
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)
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" (with an integer giving the length in the message
      an integer giving the count of octets of the name in
      the message, including but not following compression pointers)

"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.
  318    o  compressedNAME - Object that describes the name with two optional    
  319       values: "isCompressed" (with a value of 0 for no and 1 for yes)      
  320       and "length" (with an integer giving the length in the message)      
  321                                                                            
  322    o  TYPE - Integer whose value is 0 to 65535                             
  323                                                                            
  324                                                                            
  325                                                                            
  326                                                                            
  327 Hoffman                       Informational                     [Page 6]   

  328 RFC 8427                       DNS in JSON                     July 2018   
  329                                                                            
  330                                                                            
  331    o  TYPEname - String whose value is from the IANA "Resource Record      
  332       (RR) TYPEs" registry or has the format in [RFC3597]; this is case    
  333       sensitive, so "AAAA", not "aaaa"                                     
  334                                                                            
  335    o  CLASS - Integer whose value is 0 to 65535                            
  336                                                                            
  337    o  CLASSname - String whose value is "IN", "CH", or "HS" or has the     
  338       format in [RFC3597]                                                  
  339                                                                            
  340    o  TTL - Integer whose value is -2147483648 to 2147483647 (it will      
  341       only be 0 to 2147483647 in normal circumstances)                     
  342                                                                            
  343    o  RDLENGTH - Integer whose value is 0 to 65535.  Applications using    
  344       this format are unlikely to use this value directly, and instead     
  345       calculate the value from the RDATA.                                  
  346                                                                            
  347    o  RDATAHEX - Hex-encoded string (base16 encoding, described in         
  348       [RFC4648]) of the octets of the RDATA field of the resource          
  349       record.  The data in some common RDATA fields are also described     
  350       in their own members; see Section 2.3                                
  351                                                                            
  352    o  rrSet - List of objects that have RDLENGTH and RDATA members         
  353                                                                            
  354    A Question section can be expressed as a resource record.  When doing   
  355    so, the TTL, RDLENGTH, and RDATA members make no sense.                 
  356                                                                            
line-318 Richard Gibson(Technical Erratum #5437) [Held for Document Update]
based on outdated version
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.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
      an integer giving the count of octets of the name in
      the message, including but not following compression pointers)

"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.
  357 2.3.  Specific RDATA Field Members                                         
  358                                                                            
  359    The following are common RDATA types and how to specify them as JSON    
  360    members.  The name of the member contains the name of the RDATA type.   
  361    The data type for each of these members is a string.  Each name is      
  362    prefaced with "rdata" to prevent a name collision with fields that      
  363    might later be defined that have the same name as the raw type name.    
  364                                                                            
  365    o  rdataA - IPv4 address, such as "192.168.33.44"                       
  366                                                                            
  367    o  rdataAAAA - IPv6 address, such as "fe80::a65e:60ff:fed6:8aaf", as    
  368       defined in [RFC5952]                                                 
  369                                                                            
  370    o  rdataCNAME - A domain name                                           
  371                                                                            
  372    o  rdataDNAME - A domain name                                           
  373                                                                            
  374    o  rdataNS - A domain name                                              
  375                                                                            
  376    o  rdataPTR - A domain name                                             
  377                                                                            
  378    o  rdataTXT - A text value                                              
  379                                                                            
  380                                                                            
  381                                                                            
  382 Hoffman                       Informational                     [Page 7]   

  383 RFC 8427                       DNS in JSON                     July 2018   
  384                                                                            
  385                                                                            
  386    In addition, each of the following members has a value that is a        
  387    space-separated string that matches the display format definition in    
  388    the RFC that defines that RDATA type.  It is not expected that every    
  389    receiving application will know how to parse these values.              
  390                                                                            
  391    rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP,              
  392    rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3,                
  393    rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF,    
  394    rdataSRV, rdataSSHFP, rdataTLSA                                         
  395                                                                            
  396 2.4.  The Message and Its Parts as Octets                                  
  397                                                                            
  398    The following can be members of a message object.  These members are    
  399    all encoded in base16 encoding, described in [RFC4648].  All these      
  400    items are strings.                                                      
  401                                                                            
  402    o  messageOctetsHEX - The octets of the message                         
  403                                                                            
  404    o  headerOctetsHEX - The first 12 octets of the message (or fewer, if   
  405       the message is truncated)                                            
  406                                                                            
  407    o  questionOctetsHEX - The octets of the Question section               
  408                                                                            
  409    o  answerOctetsHEX - The octets of the Answer section                   
  410                                                                            
  411    o  authorityOctetsHEX - The octets of the Authority section             
  412                                                                            
  413    o  additionalOctetsHEX - The octets of the Additional section           
  414                                                                            
  415    The following can be a member of a resource record object.              
  416                                                                            
  417    o  rrOctetsHEX - The octets of a particular resource record             
  418                                                                            
  419    The items in this section are useful in applications to canonically     
  420    reproduce what appeared on the wire.  For example, an application       
  421    that is converting wire-format requests and responses might do          
  422    decompression of names, but the system reading the converted data may   
  423    want to be sure the decompression was done correctly.  Such a system    
  424    would need to see the part of the message where the decompressed        
  425    labels resided, such as in one of the items in this section.            
  426                                                                            
  427 2.5.  Additional Message Object Members                                    
  428                                                                            
  429    The following are members that might appear in a message object:        
  430                                                                            
  431    o  dateString - The date that the message was sent or received, given   
  432       as a string in the standard format described in [RFC3339] and        
  433       refined by Section 3.3 of [RFC4287].                                 
  434                                                                            
  435                                                                            
  436                                                                            
  437 Hoffman                       Informational                     [Page 8]   

  438 RFC 8427                       DNS in JSON                     July 2018   
  439                                                                            
  440                                                                            
  441    o  dateSeconds - The date that the message was sent or received,        
  442       given as a JSON number that is the number of seconds since           
  443       1970-01-01T00:00Z in UTC time; this number can be fractional.        
  444       This number must have no minus sign, can have an optional            
  445       fractional part, and can have no exponent part.                      
  446                                                                            
  447    o  comment - An unstructured comment as a string.                       
  448                                                                            
  449 2.6.  Name Fields                                                          
  450                                                                            
  451    Names are represented by JSON strings.  The rules for how names are     
  452    encoded are described in Section 1.1.  (To recap: it is limited to      
  453    the UTF-8 codepoints from U+0000 to U+007F.)  The contents of these     
  454    fields are always uncompressed; that is, after [RFC1035], name          
  455    compression has been removed.                                           
  456                                                                            
  457    There are two encodings for names:                                      
  458                                                                            
section-2.3 Richard Gibson(Technical Erratum #5438) [Rejected]
based on outdated version
   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

"A text value" is insufficiently clear to describe the contents of a TXT
record, which consists of "One or more 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.
--VERIFIER NOTES--
This is a request for a technical change, and is outside the scope of
errata reports.

The change from "matches the display format" to "matches the
presentation format" is a reasonable change in an errata report.
section-2.3 Felipe Gasper(Technical Erratum #6340) [Rejected]
based on outdated version
   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
It should say:
   o  rdataCNAME - A domain name

   o  rdataDNAME - A domain name

   o  rdataNS - A domain name

   o  rdataPTR - A domain name

   o  rdataTXT - An array of text values

Errata 5438 (https://www.rfc-editor.org/errata/eid5438) correctly notes
that “A text value” is an improper definition of TXT records’ data;
however, that errata incorrectly states that TXT record values are
space-separated. While the individual character-strings in a TXT record
may be represented as space-separated in an RFC-1035-style zone file,
that’s not germane to the RDATA itself.
--VERIFIER NOTES--
As this report is based on errata report 5438 and that report has
been Rejected, this one is also.  They are both discussing a technical
change to the document, outside the scope of an errata report.
  459    o  If the member name does not end in "HEX", the value is a domain      
  460       name encoded as DNS labels consisting of UTF-8 codepoints from       
  461       U+0000 to U+007F.  Within a label, codepoints above U+007F and the   
  462       codepoint U+002E (ASCII period) MUST be expressed using JSON's       
  463       escaping rules within this set of codepoints.  Separation between    
  464       labels is indicated with a period (codepoint U+002E).                
  465       Internationalized Domain Name (IDN) labels are always expressed in   
  466       their A-label form, as described in [RFC5890].                       
  467                                                                            
  468    o  If the member name ends in "HEX", the value is the wire format for   
  469       an entire domain name stored in base16 encoding, which is            
  470       described in [RFC4648].                                              
  471                                                                            
  472 3.  JSON Format for a Paired DNS Query and Response                        
  473                                                                            
  474    A paired DNS query and response is represented as an object.  Two       
  475    optional members of this object are named "queryMessage" and            
  476    "responseMessage", and each has a value that is a message object.       
  477    This design was chosen (as compared to the more obvious array of two    
  478    values) so that a paired DNS query and response could be                
  479    differentiated from a stream of DNS messages whose length happens to    
  480    be two.                                                                 
  481                                                                            
  482 4.  Streaming DNS Objects                                                  
  483                                                                            
  484    Streaming of DNS objects is performed using JSON text sequences         
  485    [RFC7464].                                                              
  486                                                                            
  487                                                                            
  488                                                                            
  489                                                                            
  490                                                                            
  491                                                                            
  492 Hoffman                       Informational                     [Page 9]   

  493 RFC 8427                       DNS in JSON                     July 2018   
  494                                                                            
  495                                                                            
  496 5.  Examples                                                               
  497                                                                            
  498 5.1.  Example of the Format of a DNS Query                                 
  499                                                                            
  500    The following is an example of a query for the A record of              
  501    example.com.                                                            
  502                                                                            
  503    { "ID": 19678, "QR": 0, "Opcode": 0,                                    
  504      "AA": 0, "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0, "RCODE": 0,     
  505      "QDCOUNT": 1, "ANCOUNT": 0, "NSCOUNT": 0, "ARCOUNT": 0,               
  506      "QNAME": "example.com", "QTYPE": 1, "QCLASS": 1                       
  507    }                                                                       
  508                                                                            
  509    As stated earlier, all members of an object are optional.  This         
  510    example object could have one or more of the following members as       
  511    well:                                                                   
  512                                                                            
  513    "answerRRs": []                                                         
  514    "authorityOctetsHEX": ""                                                
  515    "comment": "Something pithy goes here"                                  
  516    "dateSeconds": 1408504748.657783                                        
  517    "headerOctetsHEX": "4CDE00000001000000000000"                           
  518    "QNAMEHEX": "076578616D706C6503636F6D00",                               
  519    "compressedQNAME": { "isCompressed": 0 },                               
  520    "messageOctetsHEX":                                                     
  521         "4CDE00000001000000000000076578616D706C6503636F6D0000010001"       
  522    "questionOctetsHEX": "076578616D706C6503636F6D0000010001"               
  523    "questionRRs": [ { "NAMEHEX": "076578616D706C6503636F6D00",             
  524                   "TYPE": 1, "CLASS": 1, "hostNAME" : "example.com." } ]   
  525    "questionRRs": [ { "NAME": "example.com.", "TYPE": 1,                   
  526                   "CLASS": 1, } ]                                          
  527                                                                            
  528    (Note that this is an incomplete list of what else could be in the      
  529    object.)                                                                
  530                                                                            
  531                                                                            
  532                                                                            
  533                                                                            
  534                                                                            
  535                                                                            
  536                                                                            
  537                                                                            
  538                                                                            
  539                                                                            
  540                                                                            
  541                                                                            
  542                                                                            
  543                                                                            
  544                                                                            
  545                                                                            
  546                                                                            
  547 Hoffman                       Informational                    [Page 10]   

  548 RFC 8427                       DNS in JSON                     July 2018   
  549                                                                            
  550                                                                            
  551 5.2.  Example of the Format of a Paired DNS Query and Response             
  552                                                                            
  553    The following is a paired DNS query and response for a query for the    
  554    A record of example.com.                                                
  555                                                                            
  556    {                                                                       
line-459 Richard Gibson(Technical Erratum #5439) [Verified]
based on outdated version
   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).

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.
  557      "queryMessage": { "ID": 32784, "QR": 0, "Opcode": 0, "AA": 0,         
  558                       "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0,         
  559                       "RCODE": 0, "QDCOUNT": 1, "ANCOUNT": 0,              
  560                       "NSCOUNT": 0, "ARCOUNT": 0,                          
  561                       "QNAME": "example.com.",                             
  562                       "QTYPE": 1, "QCLASS": 1 },                           
  563      "responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,       
  564                          "QDCOUNT": 1, "ANCOUNT": 1, "NSCOUNT": 1,         
  565                          "ARCOUNT": 0,                                     
  566                          "answerRRs": [ { "NAME": "example.com.",          
  567                                           "TYPE": 1, "CLASS": 1,           
  568                                           "TTL": 3600,                     
  569                                           "RDATAHEX": "C0000201" },        
  570                                         { "NAME": "example.com.",          
  571                                           "TYPE": 1, "CLASS": 1,           
  572                                           "TTL": 3600,                     
  573                                           "RDATAHEX": "C000AA01" } ],      
  574                           "authorityRRs": [ { "NAME": "ns.example.com.",   
  575                                               "TYPE": 1, "CLASS": 1,       
  576                                               "TTL": 28800,                
  577                                               "RDATAHEX": "CB007181" } ]   
  578                        }                                                   
  579    }                                                                       
  580                                                                            
  581    The Answer section could instead be given with an rrSet:                
  582                                                                            
  583    "answerRRs": [ { "NAME": "example.com.",                                
  584                     "TYPE": 1, "CLASS": 1,                                 
  585                     "TTL": 3600,                                           
  586                     "rrSet": [ { "RDATAHEX": "C0000201" },                 
  587                                { "RDATAHEX": "C000AA01" } ] } ],           
  588                                                                            
  589    (Note that this is an incomplete list of what else could be in the      
  590    Answer section.)                                                        
  591                                                                            
  592                                                                            
  593                                                                            
  594                                                                            
  595                                                                            
  596                                                                            
  597                                                                            
  598                                                                            
  599                                                                            
  600                                                                            
  601                                                                            
  602 Hoffman                       Informational                    [Page 11]   

  603 RFC 8427                       DNS in JSON                     July 2018   
  604                                                                            
  605                                                                            
  606 6.  Local Format Policy                                                    
  607                                                                            
  608    Systems using the format in this document will likely have policy       
  609    about what must be in the objects.  Those policies are outside the      
  610    scope of this document.                                                 
  611                                                                            
  612    For example, passive DNS systems such as those described in             
  613    [PASSIVE-DNS] cover just DNS responses.  Such a system might have a     
  614    policy that makes QNAME, QTYPE, and answerRRs mandatory.  That          
  615    document also describes two mandatory times that are not in this        
  616    format, so the policy would possibly also define those members and      
  617    make them mandatory.  The policy could also define additional members   
  618    that might appear in a record.                                          
  619                                                                            
  620    As another example, a program that uses this format for configuring     
  621    what a test client sends on the wire might have a policy of "each       
  622    record object can have as few members as it wants; all unstated         
  623    members are filled in from previous records".                           
  624                                                                            
  625 7.  IANA Considerations                                                    
  626                                                                            
  627 7.1.  Media Type Registration of application/dns+json                      
  628                                                                            
  629    Type name: application                                                  
  630                                                                            
  631    Subtype name: dns+json                                                  
  632                                                                            
  633    Required parameters: N/A                                                
  634                                                                            
  635    Optional parameters: N/A                                                
  636                                                                            
  637    Encoding considerations:  Encoding considerations are identical to      
  638    those specified for the "application/json" media type.                  
  639                                                                            
  640    Security considerations:  This document specifies the security          
  641    considerations for the format.                                          
  642                                                                            
  643    Interoperability considerations:  This document specifies format of     
  644    conforming messages and the interpretation thereof.                     
  645                                                                            
  646    Published specification:  This document                                 
  647                                                                            
  648    Applications that use this media type:  Systems that want to exchange   
  649    DNS messages                                                            
  650                                                                            
  651    Fragment identifier considerations:  None                               
  652                                                                            
  653                                                                            
  654                                                                            
  655                                                                            
  656                                                                            
  657 Hoffman                       Informational                    [Page 12]   

  658 RFC 8427                       DNS in JSON                     July 2018   
  659                                                                            
  660                                                                            
  661    Additional information:                                                 
  662                                                                            
  663      Deprecated alias names for this type: N/A                             
  664                                                                            
  665      Magic number(s):  N/A                                                 
  666                                                                            
  667      File extension(s):  This document uses the media type to refer to     
  668      protocol messages and thus does not require a file extension.         
  669                                                                            
  670      Macintosh file type code(s):  N/A                                     
  671                                                                            
  672    Person & email address to contact for further information:              
  673    Paul Hoffman, paul.hoffman@icann.org                                    
  674                                                                            
  675    Intended usage:  COMMON                                                 
  676                                                                            
  677    Restrictions on usage:  N/A                                             
  678                                                                            
  679    Author:  Paul Hoffman, paul.hoffman@icann.org                           
  680                                                                            
  681    Change controller:  Paul Hoffman, paul.hoffman@icann.org                
  682                                                                            
  683 8.  Security Considerations                                                
  684                                                                            
  685    As described in Section 1.1, a message object can have inconsistent     
  686    data, such as a message with an ANCOUNT of 1 but that has either an     
  687    empty answerRRs array or an answerRRs array that has two or more RRs.   
  688    Other examples of inconsistent data would be resource records whose     
  689    RDLENGTH does not match the length of the decoded value in the          
  690    RDATAHEX member, a record whose various header fields do not match      
  691    the value in headerOctetsHEX, and so on.  A reader of this format       
  692    must never assume that all of the data in an object are all             
  693    consistent with each other.                                             
  694                                                                            
  695    This document describes a format, not a profile of that format.  Lack   
  696    of profile can lead to security issues.  For example, if a system has   
  697    a filter for JSON representations of DNS packets, that filter needs     
  698    to have the same semantics for the output JSON as the consumer has.     
  699    Unless the profile is quite tight, this can lead to the producer        
  700    being able to create fields with different contents (using the HEX      
  701    and regular formats), fields with malformed lengths, and so on.         
  702                                                                            
  703    Numbers in JSON do not have any bounds checking.  Thus, integer         
  704    values in a record might have invalid values, such as an ID field       
  705    whose value is greater than or equal to 2^16, a QR field that has a     
  706    value of 2, and so on.                                                  
  707                                                                            
  708                                                                            
  709                                                                            
  710                                                                            
  711                                                                            
  712 Hoffman                       Informational                    [Page 13]   

  713 RFC 8427                       DNS in JSON                     July 2018   
  714                                                                            
  715                                                                            
  716 9.  Privacy Considerations                                                 
  717                                                                            
  718    The values that can be contained in this format may contain privacy-    
  719    sensitive information.  For example, a profile of this format that is   
  720    used for logging queries sent to recursive resolvers might have         
  721    source IP addresses that could identify the location of the person      
  722    who sent the DNS query.                                                 
  723                                                                            
  724 10.  References                                                            
  725                                                                            
  726 10.1.  Normative References                                                
  727                                                                            
  728    [RFC1035]  Mockapetris, P., "Domain names - implementation and          
  729               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,      
  730               November 1987, <https://www.rfc-editor.org/info/rfc1035>.    
  731                                                                            
  732    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          
  733               Requirement Levels", BCP 14, RFC 2119,                       
  734               DOI 10.17487/RFC2119, March 1997,                            
  735               <https://www.rfc-editor.org/info/rfc2119>.                   
  736                                                                            
  737    [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:     
  738               Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,      
  739               <https://www.rfc-editor.org/info/rfc3339>.                   
  740                                                                            
  741    [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record     
  742               (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September       
  743               2003, <https://www.rfc-editor.org/info/rfc3597>.             
  744                                                                            
  745    [RFC4287]  Nottingham, M., Ed. and R. Sayre, Ed., "The Atom             
  746               Syndication Format", RFC 4287, DOI 10.17487/RFC4287,         
  747               December 2005, <https://www.rfc-editor.org/info/rfc4287>.    
  748                                                                            
  749    [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data          
  750               Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,    
  751               <https://www.rfc-editor.org/info/rfc4648>.                   
  752                                                                            
  753    [RFC5890]  Klensin, J., "Internationalized Domain Names for             
  754               Applications (IDNA): Definitions and Document Framework",    
  755               RFC 5890, DOI 10.17487/RFC5890, August 2010,                 
  756               <https://www.rfc-editor.org/info/rfc5890>.                   
  757                                                                            
  758    [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6    
  759               Address Text Representation", RFC 5952,                      
  760               DOI 10.17487/RFC5952, August 2010,                           
  761               <https://www.rfc-editor.org/info/rfc5952>.                   
  762                                                                            
  763                                                                            
  764                                                                            
  765                                                                            
  766                                                                            
  767 Hoffman                       Informational                    [Page 14]   

  768 RFC 8427                       DNS in JSON                     July 2018   
  769                                                                            
  770                                                                            
  771    [RFC7464]  Williams, N., "JavaScript Object Notation (JSON) Text        
  772               Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,   
  773               <https://www.rfc-editor.org/info/rfc7464>.                   
  774                                                                            
  775    [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC       
  776               2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,     
  777               May 2017, <https://www.rfc-editor.org/info/rfc8174>.         
  778                                                                            
  779    [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data   
  780               Interchange Format", STD 90, RFC 8259,                       
  781               DOI 10.17487/RFC8259, December 2017,                         
  782               <https://www.rfc-editor.org/info/rfc8259>.                   
  783                                                                            
  784 10.2.  Informative References                                              
  785                                                                            
  786    [DNS-QUERY]                                                             
  787               Parthasarathy, M. and P. Vixie, "Representing DNS messages   
  788               using XML", Work in Progress,                                
  789               draft-mohan-dns-query-xml-00, September 2011.                
  790                                                                            
  791    [DNSXML]   Daley, J., Morris, S., and J. Dickinson, "dnsxml - A         
  792               standard XML representation of DNS data", Work in            
  793               Progress, draft-daley-dnsxml-00, July 2013.                  
  794                                                                            
  795    [PASSIVE-DNS]                                                           
  796               Dulaunoy, A., Kaplan, A., Vixie, P., and H. Stern,           
  797               "Passive DNS - Common Output Format", Work in Progress,      
  798               draft-dulaunoy-dnsop-passive-dns-cof-04, June 2018.          
  799                                                                            
  800 Acknowledgements                                                           
  801                                                                            
  802    Some of the ideas in this document were inspired by earlier,            
  803    abandoned work such as [DNSXML], [DNS-QUERY], and [PASSIVE-DNS].  The   
  804    document was also inspired by early ideas from Stephane Bortzmeyer.     
  805    Many people in the Domain Name System Operations (DNSOP) and DNS Over   
  806    HTTPS (DOH) working groups contributed very useful ideas (even though   
  807    this was not a WG work item).                                           
  808                                                                            
  809 Author's Address                                                           
  810                                                                            
  811    Paul Hoffman                                                            
  812    ICANN                                                                   
  813                                                                            
  814    Email: paul.hoffman@icann.org                                           
  815                                                                            
  816                                                                            
  817                                                                            
  818                                                                            
  819                                                                            
  820                                                                            
  821                                                                            
  822 Hoffman                       Informational                    [Page 15]   
  823                                                                            
line-557 Stéphane Bortzmeyer(Technical Erratum #5570) [Held for Document Update]
based on outdated version
"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": 12, "NSCOUNT": 1,

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.