Subject: [DNSOP] DNS-in-JSON draft

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 03 Sep 2016 15:43:34 -0700

Greetings again. I have updated my draft on describing DNS messages in 
JSON. I still don't think that this WG needs to adopt this given that it 
is, as far as I can tell, thinly implemented. I think it's probably 
about baked enough for me to take it to the Independent Submissions 
editor to become an Experimental RFC. If y'all have any comments on it, 
please send them along and I'll incorporate before I move it along to 
RFChood.

--Paul Hoffman

A new version of I-D, draft-hoffman-dns-in-json-07.txt
has been successfully submitted by Paul Hoffman and posted to the
IETF repository.

Name:		draft-hoffman-dns-in-json
Revision:	07
Title:		Representing DNS Messages in JSON
Document date:	2016-09-03
Group:		Individual Submission
Pages:		11
URL:            
https://www.ietf.org/internet-drafts/draft-hoffman-dns-in-json-07.txt
Status:         
https://datatracker.ietf.org/doc/draft-hoffman-dns-in-json/
Htmlized:       https://tools.ietf.org/html/draft-hoffman-dns-in-json-07
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-in-json-07

---

From: Robert Edmonds <[email-masked]>
Date: Sat, 3 Sep 2016 23:20:13 -0400

Paul Hoffman wrote:
> Greetings again. I have updated my draft on describing DNS messages in JSON.
> I still don't think that this WG needs to adopt this given that it is, as
> far as I can tell, thinly implemented. I think it's probably about baked
> enough for me to take it to the Independent Submissions editor to become an
> Experimental RFC. If y'all have any comments on it, please send them along
> and I'll incorporate before I move it along to RFChood.

Hi, Paul:

In section 3:

   A paired DNS query and response is represented as an object.  Two
   optional members of this object are names "queryRecord" and
   "responseRecord", and each has a value that is an message object.
   This design was chosen (as compared to the more obvious array of two
   values) so that a paired DNS query and response could be
   differentiated from a stream of DNS messages whose length happens to
   be two.

Why do you call these fields "queryRecord" and "responseRecord"? It seems
to me that "queryMessage" and "responseMessage" would be more intuitive.

In section 7:

    This document has no effect on IANA registries.

Do you plan to register a media type for this format? There is some
precedent: the "application/dns" media type was registered for the
experimental format defined in RFC 2540 "Detached Domain Name System
(DNS) Information".

Nit: "Questing section" → "Question section"

-- 
Robert Edmonds

---

From: Shane Kerr <[email-masked]>
Date: Mon, 5 Sep 2016 15:47:37 +0800

Paul,

At 2016-09-03 15:43:34 -0700

> please send them along and I'll incorporate before I move it along to 

Thanks for this draft! I would be happy to see DNS in JSON documented,
if not exactly standardized. :)

I apologize if this stuff has been discussed before.

First, it seems like it might be nice to have a way to express RDATA in
DNS presentation format. The document is very clear that no way is
provided for this, but it seems like it would be really, really useful.

Next, is compressedNAME likely to be useful? I'm not arguing strongly
against it, but since it involves pointers and those are not going to
be useful with a JSON object, I don't really see much point.

I don't see any mention of whether things like TYPEname and CLASSname
are case-sensitive and if they are not which case they should be. My
recommendation would be to make them case-insensitive, although not
every field can be so having to tag each might be a bit much?

It occurs to me that maybe we want an option to have arrays of RRset
instead of arrays of RRs?

    "answerRRsets": [ { "NAME": "example.com",
                        "TYPE": 1, "CLASS": 1, "TTL": 3600, 
                        "RR": [ { "RDLENGTH": 4, "RDATA*": "C0000201" },
                                { "RDLENGTH": 4, "RDATA*": "CB007181" } 
                              ]
                      }
                    ]

It's not super important, but it would save me having to build RRset in
my applications. (With the RRs only I have to loop through the entire
section and only when done can I know that I have gotten a complete
RRset.)

Also, I guess it's also not important, but you may want to consider
using the RFC 5737 addresses for the example answer (like I did here).

Finally, I note that the RIPE Atlas system uses a type of DNS JSON
representation when you use their API to query for DNS measurement
results. You can get a sample here:

https://atlas.ripe.net/api/v2/measurements/5009360/results?start=1472860800&stop=1472947199&format=txt

The RIPE Atlas results match your proposal pretty well - you can see
it in the "results" object there - although they use "abuf" instead of
"messageOctets!".

Cheers,

--
Shane

---

From: Jerry Lundström <[email-masked]>
Date: Mon, 5 Sep 2016 08:42:03 +0000

Hi Paul,

> please send them along and I'll incorporate before I move it along to

Overall looks good, just a few minor concerns with adaptation/
interoperability:

- Non-ASCII octets escaping "\DDD" may lead to broken implementations
and/or encoding problem (oh so many printf()'ed JSON implementations out
there)

- The use of "!" and "*" in object attribute names will make it hard to
use in language that can read JSON and give out native objects such as
JavaScript.

Cheers,
Jerry

---

From: Ray Bellis <[email-masked]>
Date: Mon, 5 Sep 2016 09:52:42 +0100

> use in language that can read JSON and give out native objects such as

Harder, but not "hard", in JS.

You can always use myObject['RDATA*'] syntax if you need to use a key
that's not a legal token.

That said, I'd rather not see those special characters there, either.

Ray

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Sep 2016 11:22:48 +0100

> instead of arrays of RRs?

If you do that, how do you represent the covering signature(s)?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire, East Forties: Southerly 4, increasing 5 or 6. Slight or
moderate. Mainly fair. Good, occasionally poor later.

---

From: "John Levine" <[email-masked]>
Date: 5 Sep 2016 16:38:00 -0000

>provided for this, but it seems like it would be really, really useful.

If you want to do that, you could probably piggyback it on my recently
revived draft-levine-dnsextlang.

R's,
John

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Sep 2016 09:51:17 -0700

> to me that "queryMessage" and "responseMessage" would be more 

Good call, yes. Will fix.

> experimental format defined in RFC 2540 "Detached Domain Name System

<sigh> I guess I should. Prediction: things will rathole on this 
section, not on the meat of the document.

> Nit: "Questing section" → "Question section"

Fixed.

Thanks!

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Sep 2016 10:21:40 -0700

> provided for this, but it seems like it would be really, really 

If it useful for a particular application for particular RDATA, that 
application could easily specify a format in its profile. If that 
catches on, I could update this document with a collection of those. But 
I don't want to start now by specifying the formats I would want myself.

> be useful with a JSON object, I don't really see much point.

I doubt they will be that useful, but a receiver might want to know 
which names in a message were compressed and which were not. I admit 
that it would be clearer for that receiver to just look through the 
message or section binary fields.

> every field can be so having to tag each might be a bit much?

Well, this brought up an ugly problem. The name in the IANA registry for 
class 1 is "Internet (IN)". Chaos and Hesiod are similarly bad. I'm 
going to change the definition of the class names to be 'String whose 
value is "IN", "CH", "HS", or has the format in {{RFC3597}}'. I don't 
think I really need to add to TYPEs that the name is case-sensitive, 
since it says "from the IANA RR TYPEs registry".

> section and only when done can I know that I have gotten a complete

Instead of a new "answerRRsets", how about if I invent an "RRset" object 
and the change the definitions of the various sections to "answerRRs -- 
Array of zero or more resource records or RRset objects in the Answer 
section"? That way you can mix and match records and RRsets.

> using the RFC 5737 addresses for the example answer (like I did here).

Sure, good call. (I know that the RFC Editor checks for this, but I 
wonder if they would know to have undone the hex encoding...)

> it in the "results" object there - although they use "abuf" instead of

There are many ways to do things. :-)

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Sep 2016 10:40:09 -0700

> and/or encoding problem (oh so many printf()'ed JSON implementations 

Sure, but I'm not sure what to do about this. It's not really a security 
consideration, and it's not really even about this format: that's true 
for any application that gets a host name in return to a PTR query, yes?

> use in language that can read JSON and give out native objects such as

Yeah, I thought about that: it sucks for most programming languages. 
Would people be happier if I used "B64" and "HEX" for trailers of names 
instead of "!" and "*"? I guess I'm in control of the naming and can be 
sure those don't appear at the end of object names.

--Paul Hoffman

---

From: Shane Kerr <[email-masked]>
Date: Tue, 6 Sep 2016 12:36:10 +0800

John,

At 2016-09-05 16:38:00 -0000

> revived draft-levine-dnsextlang.

Interesting. I vaguely remember someone (Olafur?) also had a similar
approach to dynamically describing RTYPE in the DNS itself. Or maybe
it was actually this draft that I am thinking of?

I think it's a reasonable idea. Have you done the work of going through
the existing RR types and describing them in this language? (I seem to
recall a previous attempt was mostly successful, with some issues with
the LOC type.)

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Tue, 6 Sep 2016 12:38:41 +0800

Tony,

At 2016-09-05 11:22:48 +0100

> If you do that, how do you represent the covering signature(s)?

I'm not sure I understand the question? An RRSIG is for an entire
RRset, so either one could add the signature to the RRset object or
leave them as separate RR.

Probably it makes sense to include an example though.

Cheers,

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Tue, 6 Sep 2016 12:44:48 +0800

Paul,

At 2016-09-05 10:21:40 -0700

> I don't want to start now by specifying the formats I would want myself.

Hm... I guess I don't see why the DNS-in-JSON draft can't simply say
that the formats are those documented in the RFC for any particular
RTYPE? Each RTYPE has a defined format, right?

> message or section binary fields.

Maybe it could be a value that describes something like this:

"compressedNAME": { "isCompressed": "yes", "length": 7 }

The "length" would be the compressed length. The uncompressed length
can be found by looking at the name.
 
> since it says "from the IANA RR TYPEs registry".

Makes sense. Stupid DNS classes. :)

Can you explicitly say that TYPEs are case-INsensitive then? It might
save some poor coder at some point, since programming languages
generally default to case-sensitive comparisons...

> section"? That way you can mix and match records and RRsets.

Sounds good!

--
Shane

---

From: Jerry Lundström <[email-masked]>
Date: Tue, 6 Sep 2016 06:26:58 +0000

Hi Paul,

> for any application that gets a host name in return to a PTR query, yes?

I was more commenting on the fact that it is escaping in a format that
already support escaping. The JSON output would be double escaped and
implementations would need to unescape it themselves rather then let
JSON handle it.

> sure those don't appear at the end of object names.

That would be better yes but it also got me thinking, why two different
ways of encoding it?

Could be simplified by just using base64url (or base64).

Cheers,
Jerry

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Sep 2016 09:34:53 +0200

In your letter dated Tue, 6 Sep 2016 06:26:58 +0000 you wrote:
> I was more commenting on the fact that it is escaping in a format
> that already support escaping. The JSON output would be double
> escaped and implementations would need to unescape it themselves
> rather then let JSON handle it.

JSON strings are defined to be UTF-8. You get all kinds of weird problems
if you try to store 8-bit binary data directly in JSON strings.
(I.e. using the \uXXXX escape sequence)

An encoding that only requires US-ASCII to be stored in JSON strings is
a lot safer.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 06 Sep 2016 09:37:15 +0200

In your letter dated Mon, 5 Sep 2016 15:47:37 +0800 you wrote:
>https://atlas.ripe.net/api/v2/measurements/5009360/results?start=3D14728608=
>00&stop=3D1472947199&format=3Dtxt
>

What you are referring is sort of the unofficial Atlas format. This what Atlas probes
provide. The real format is the 'abuf decoder' in Sagan. 

Here's an example of the output of the abuf decoder, when converted to JSON (by
itself the abuf decoder results in python objects):

{"HEADER": {"AA": true, "QR": true, "AD": false, "NSCOUNT": 1, "QDCOUNT": 1, "ANCOUNT": 0, "TC": false, "RD": false, "ARCOUNT": 1, "CD": false, "ReturnCode": "NXDOMAIN", "OpCode": "QUERY", "RA": false, "Z": 0, "ID": 36316}, "AuthoritySection": [{"Retry": 900, "Name": ".", "NegativeTtl": 86400, "Refresh": 1800, "MasterServerName": "www.yeti-dns.org.", "Expire": 604800, "MaintainerName": "hostmaster.yeti-dns.org.", "TTL": 86400, "Serial": 2016050801, "Type": "SOA", "Class": "IN", "RDlength": 51}], "QuestionSection": [{"Qclass": "IN", "Qtype": "SOA", "Qname": "yetiroot."}], "EDNS0": {"ExtendedReturnCode": 0, "Option": [{"OptionCode": 3, "OptionName": "NSID", "NSID": "dahu1.yeti.eu.org", "OptionLength": 17}], "UDPsize": 4096, "Version": 0, "Z": 0, "Type": "OPT", "Name": "."}}

Two obvious differences are the use of 'true' and 'false' for boolean bit fields and
the use of names ("Class": "IN") instead of a number of a name.

I'd like to point out the DNSSEC tends to use base64. So we also use that, for example:

{"AuthoritySection": [{"Target": "sec3.apnic.net.", "TTL": 2941, "Type": "NS", "Class": "IN", "RDlength": 13, "Name": "ripe.net."}, {"Target": "pri.authdns.ripe.net.", "TTL": 2941, "Type": "NS", "Class": "IN", "RDlength": 14, "Name": "ripe.net."}, {"Target": "tinnie.arin.net.", "TTL": 2941, "Type": "NS", "Class": "IN", "RDlength": 14, "Name": "ripe.net."}, {"Target": "sns-pb.isc.org.", "TTL": 2941, "Type": "NS", "Class": "IN", "RDlength": 16, "Name": "ripe.net."}, {"Target": "sec1.apnic.net.", "TTL": 2941, "Type": "NS", "Class": "IN", "RDlength": 7, "Name": "ripe.net."}, {"Target": "ns3.nic.fr.", "TTL": 2941, "Type": "NS", "Class": "IN", "RDlength": 12, "Name": "ripe.net."}, {"KeyTag": 11587, "Name": "ripe.net.", "Algorithm": 5, "SignerName": "ripe.net.", "Labels": 2, "Signature": "C4WMH46cBWT/hhWvVrStIdXrqHA2fwfphGkx9+6wbss+mHg8mbfKvaFfcg43/MZh/PwdyAQkRN8I+v/OZ1JA3Gt3KvDc00PebtQZBYlXxssZVNtcx45DG5a3M/RGzhqjM5hfuigLmghIEhuvMhtrhmC4WS/7B3KrYOenFQUJmxk=", "Class": "IN", "TTL": 2941, "O
 riginalTTL": 3600, "SignatureInception": 1403074827, "SignatureExpiration": 1405670427, "Type": "RRSIG", "TypeCovered": "NS", "RDlength": 156}], "QuestionSection": [{"Qclass": "IN", "Qtype": "A", "Qname": "www.ripe.net."}], "AdditionalSection": [{"Name": "pri.authdns.ripe.net.", "TTL": 1688, "Address": "193.0.9.5", "Type": "A", "Class": "IN", "RDlength": 4}, {"Name": "pri.authdns.ripe.net.", "TTL": 1688, "Address": "2001:67c:e0:0:0:0:0:5", "Type": "AAAA", "Class": "IN", "RDlength": 16}], "HEADER": {"AA": false, "QR": true, "AD": true, "NSCOUNT": 7, "QDCOUNT": 1, "ANCOUNT": 2, "TC": false, "RD": true, "ARCOUNT": 5, "CD": false, "ReturnCode": "NOERROR", "OpCode": "QUERY", "RA": true, "Z": 0, "ID": 22575}, "ERROR": [["_do_rr", 576, "offset out of range: buf size = 576"], ["additional", 574, "_do_rr failed, additional record 2"]], "AnswerSection": [{"Name": "www.ripe.net.", "TTL": 20941, "Address": "193.0.6.139", "Type": "A", "Class": "IN", "RDlength": 4}, {"KeyTag": 11587, "Name": "www
 .ripe.net.", "Algorithm": 5, "SignerName": "ripe.net.", "Labels": 3, "Signature": "I7lQZF9ia3X83KTY01/orh3qRqAS0BYeozB7SZ/juSk0RfeTngWoIIkLzvbBV11ORrmr93FkH5xPrPtT9Wf4c0QAqZRN+RyyP8K5JaMI4TGT9cc2mAS5Gf8elg2c/fI2LvIMjVXKpkxMcEh/bSrbpBiS8tjR8z2p60CWOir0sE0=", "Class": "IN", "TTL": 20941, "OriginalTTL": 21600, "SignatureInception": 1403074827, "SignatureExpiration": 1405670427, "Type": "RRSIG", "TypeCovered": "A", "RDlength": 156}]}

Another thing worth pointing out is that getdns has its own set of field names for
representing DNS. So it may be worth aligning this document as much as possible
with getdns.

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Sep 2016 14:29:24 +0100

> leave them as separate RR.

Well, yes, that's the question :-) And if you make them part of the RRset
object, how do you do so? and if they aren't part of the RRset object then
you have to have a special way to separate RRSIGs based on their
type-covered field. etc.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Plymouth, North Biscay: Variable 3 or 4, becoming easterly or southeasterly 4
or 5 later. Moderate, occasionally slight. Fog patches. Moderate, occasionally
very poor.

---

From: "John R Levine" <[email-masked]>
Date: 6 Sep 2016 12:20:07 -0400

> it was actually this draft that I am thinking of?

This is it.  See https://datatracker.ietf.org/doc/draft-levine-dnsextlang/

> recall a previous attempt was mostly successful, with some issues with

That's the eventual plan, although there is a long tail of funky field 
types found only in RRs that nobody uses any more.

I have some funding to implement it, so I'm doing the useful parts first 
to see if I run into unexpected problems.  It took about 15 minutes to 
realize that it needs to let you name the fields as well as describe them, 
if you want to refer to the fields from other code.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Sep 2016 20:12:53 +0100

John R Levine <[email-masked]> wrote:
>
> That's the eventual plan, although there is a long tail of funky field types
> found only in RRs that nobody uses any more.

When I looked at this in 2012 I concluded that the best approach would be
to keep the generic language REALLY simple, and that RDATA with special
needs would have to have a custom-coded parser/serializer.

There were three memorable problems:

(1) RDATA where the field order was not consistent between wire format and
presentation format, e.g. LOC

(2) RDATA with variable format, e.g. IPSECKEY

(3) RDATA with variable number of fields, e.g. APL, NSEC

It's MUCH easier to define an abstract syntax if the RDATA has a fixed
number of fields in a fixed order, which is consistent in all formats.

> I have some funding to implement it, so I'm doing the useful parts first to
> see if I run into unexpected problems.  It took about 15 minutes to realize
> that it needs to let you name the fields as well as describe them, if you want
> to refer to the fields from other code.

Yes! And field names are really crucial if you want to be able to
auto-generate user interfaces from the abstract syntax, because you can
use the field names as a key for localization and for help text.

Very sketchy dump of old ideas after the break....

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames, Dover, Wight: Variable 3 or 4. Smooth or slight. Fog patches.
Moderate, occasionally very poor.

The following includes a failed attempt to incorporate enumerations into
the abstract syntax, which makes it more complicated than I would like,
but I think enums are vital for autogenerated user interfaces.

; types
;
; name
; text
; uint8
; uint16
; uint32
; time (uint32 with variant presentation format)
; ipv4
; ipv6
; flags16
; base64 (whitespace allowed)
; hex (no whitespace allowed)
; unknown
; rrtype
; bitlist

; qualifiers
;
; name
;  host
;  mail
;  compressed
;  decompress
;  additional
; uint32
;  interval (BIND extension)
; bitlist
;  port
;  rrtype
; text
;  multiple

define uint8 algo [http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml]
 1   RSAMD5            -
 2   DH                -
 3   DSA               -
 5   RSASHA1           -
 6   DSA-NSEC3-SHA1    -
 7  RSASHA1-NSEC3-SHA1 -
 8   RSASHA256         -
 10  RSASHA512         -
 12  ECC-GOST          -
 13  ECDSAP256SHA256   -
 14  ECDSAP384SHA384   -
 252 INDIRECT          -
 252 PRIVATEDNS        -
 253 PRIVATEOID        -

TYPE1 A IPv4 address [RFC1035]
 ipv4 ADDRESS -

TYPE2 NS Name server [RFC1035]
 name NSDNAME Host name
  host additional compressed

TYPE3 MD Mail destination (OBSOLETE - use MX) [RFC1035]
 name MADNAME Mail agent host name
  host additional compressed

TYPE4 MF Mail forwarder (OBSOLETE - use MX) [RFC1035]
 name MADNAME Mail agent host name
  host additional compressed

TYPE5 CNAME Alias [RFC1035]
 name CNAME Canonical name
  compressed

TYPE6 SOA Start of zone of authority [RFC1035]
 name   MNAME   Master name server
  host compressed
 name   RNAME   Hostmaster email address
  mail compressed
 uint32 SERIAL  Zone serial number
 uint32 REFRESH Refresh interval
  interval
 uint32 RETRY   Retry interval
  interval
 uint32 EXPIRE  Slave copy lifetime
  interval
 uint32 MINIMUM Negative response TTL
  interval

TYPE7 MB Mailbox (OBSOLETE - use MX) [RFC1035]
 name MADNAME Mail agent host name
  host additional compressed

TYPE8 MG Mail group (OBSOLETE - use MX) [RFC1035]
 name MGNAME Group member email address
  mail compressed

TYPE9 MR Mail rename (OBSOLETE - use MX) [RFC1035]
 name NEWNAME Replacement email address
  mail compressed

TYPE10 NULL Meaningless data [RFC1035]

TYPE11 WKS Well known service (OBSOLETE) [RFC1035]
 ipv4   ADDRESS  Host address
 uint16 PROTOCOL Protocol
  6  TCP -
  17 UDP -
 bitlist - Bit map of open ports

TYPE12 PTR Pointer from reverse DNS [RFC1035]
 name PTRDNAME Forward DNS name
  host compressed
; is host flag correct?

TYPE13 HINFO Host information [RFC1035]
 text CPU -
 text OS  -

TYPE14 MINFO Mail information (OBSOLETE - use MX) [RFC1035]
 name RMAILBX Responsible person email address
  mail compressed
 name EMAILBX Error email address
  mail compressed

TYPE15 MX Mail exchanger [RFC1035]
 uint16 PREFERENCE Preference (lower values tried first)
 name   EXCHANGE   Mail exchange host name
  host additional compressed

TYPE16 TXT Text [RFC1035]
 text TXT-DATA -
  multiple

TYPE17 RP Responsible person [RFC1183]
 name MBOX-DNAME Email address
  mail decompress
 name TXT-DNAME  Pointer to TXT records
  decompress

TYPE18 AFSDB AFS database location [RFC1183]
 uint16 SUBTYPE -
  1 - AFSv3 volume location server
  2 - cell root directory node
 name HOSTNAME -
  host additional decompress

TYPE19 X25 X.25 PSDN address (OBSOLETE) [RFC1183]
 text PSDN-ADDRESS -

TYPE20 ISDN ISDN address (OBSOLETE) [RFC1183]
 text ISDN-ADDRESS Telephone number
 text SA           Subaddress
  optional

TYPE21 RT Route through [RFC1183]
 uint16 PREFERENCE        Preference (lower values tried first)
 name   INTERMEDIATE-HOST Intermediate host name
  host additional decompress

TYPE22 NSAP ISO NSAP address (OBSOLETE) [RFC1706]
; hex NSAP-ADDRESS -
;  with 0x prefix and optional dots

TYPE23 NSAP-PTR ISO NSAP reverse pointer (OBSOLETE - use PTR) [RFC1348]
 name OWNER -
  decompress

TYPE24 SIG Cryptographic signature (OBSOLETE) [RFC2535]
 rrtype TYPE-COVERED Type covered
 algo   ALGORITHM    Signature algorithm
 uint8  LABELS       Non-wildcard label count
 uint32 ORIG-TTL     Original TTL
  interval
 time   EXPIRATION   Expiration time
 time   INCEPTION    Inception time
 uint16 KEY-TAG      Key tag
 name   SIGNER       Key name
  decompress
 base64 SIGNATURE    Signature data

TYPE25 KEY Cryptographic key [RFC2535]
 flags16 FLAGS Flags
  49152 A-C    Key restrictions
   49152 NOKEY  No key present
   32769 NOAUTH Not for authentication
   16384 NOCONF Not for encryption
  4096  EXTEND Extended flags
  768   NAMTYP Owner type
   768   OTHER  -
   512   HOST   -
   256   ZONE   -
   0     USER   -
  15    SIG    Signatory [RFC2137]
  8     ZONE    Zone control
  4     STRONG  Strong update
  2     UNIQUE  Unique name update
  1     GENERAL General update
 uint8 PROTOCOL Protocol
  1 TLS    -
  2 EMAIL  -
  3 DNSSEC -
  4 IPSEC  -
  255 ALL  -
 algo   ALGORITHM  Algorithm
 base64 PUBLIC-KEY Public key data

TYPE26 PX X.400 mail gateway [RFC2163]
 uint16 PREFERENCE Preference (lower values tried first)
 name   MAP822  -
  decompress
 name   MAPX400 -
  decompress

TYPE27 GPOS Geographical Position [RFC1712]
 text LONGITUDE -
 text LATITUDE  -
 text ALTITUDE  -

TYPE28 AAAA IPv6 address [RFC3596]
 ipv6 ADDRESS -

TYPE29 LOC Location [RFC1876]
; uint8  VERSION   Must be 0
; float8 SIZE      Diameter
; float8 HORIZ-PRE Horizontal precision
; float8 VERT-PRE  Vertical precision
; angle  LATITUDE  Latitude
;  N,S
; angle  LONGITURE Longitude
;  E,W
; altitude ALTITUDE Altitude
;
; angle is uint32 thousandths of a second of arc plus 2^31
; presented as degrees, minutes, seconds
; altitude is uint32 centimetres plus 10,000,000
; presented as metres
;
; presentation order is
; latitude
; longitude
; altitude
; size      (default 1m)
; horiz-pre (default 10000m)
; vert-pre  (default 10m)

TYPE30 NXT Next domain (OBSOLETE) [RFC2535]
 name NEXT Next domain name
  decompress
 bitlist
  rrtype

TYPE31 EID Endpoint Identifier

TYPE32 NIMLOC Nimrod Locator

TYPE33 SRV      Service location [RFC2782]
 uint16 PRIORITY Preference (lower values tried first)
 uint16 WEIGHT   -
 uint16 PORT     -
 name   TARGET   -
  host additional decompress

TYPE34 ATMA ATM address

TYPE35 NAPTR Naming authority pointer [RFC3403]
 uint16 ORDER      Order (lower values processed first)
 uint16 PREFERENCE Preference (lower values tried first)
 text  FLAGS       -
 text  SERVICES    -
 text  REGEXP      Regular expression
 name  REPLACEMENT -
  decompress

TYPE36 KX Key exchanger [RFC2230]
 uint16 PREFERENCE Preference (lower values tried first)
 name   EXCHANGER  Host name
  host additional

TYPE37 CERT Cryptographic certificate [RFC4398]
 uint16 TYPE      -
    1    PKIX      X.509 as per PKIX
    2    SPKI      SPKI certificate
    3    PGP       OpenPGP packet
    4    IPKIX     The URL of an X.509 data object
    5    ISPKI     The URL of an SPKI certificate
    6    IPGP      The fingerprint and URL of an OpenPGP packet
    7    ACPKIX    Attribute Certificate
    8    IACPKIX   The URL of an Attribute Certificate
    253  URI       Type described by URI
    254  OID       Type described by OID
 uint16 KEY-TAG   Key tag
 algo   ALGORITHM Algorithm
 base64 -         Certificate or CRL data

TYPE38 A6 Partial IPv6 address (OBSOLETE - use AAAA) [RFC2874]
 a6   ADDRESS     Prefix length and address suffix
 name PREFIX-NAME Prefix name
  optional

TYPE39 DNAME Subdomain redirect [RFC2672]
 name DNAME Target domain

TYPE40 SINK Kitchen sink
 uint16 CODING    -
 uint16 SUBCODING -
 base64 DATA      -

TYPE41 OPT Extension pseudo-record [RFC2671]

TYPE42 APL Address prefix list [RFC3123]
; Complicated syntax
; repeat
;  uint16 ADDRESSFAMILY
;   1 - IPv4
;   2 - IPv6
;  flags16 - -
;   65280  PREFIX    -
;   128    N         -
;   12 7   AFDLENGTH -
;  ipv4/ipv6 AFDPART -

TYPE43 DS Delegation signer [RFC4034]
 uint16 KEY-TAG     Key tag
 algo   ALGORITHM   Algorithm
 uint8  DIGEST-TYPE Digest type
  1 SHA-1   -
  2 SHA-256 -
  3 GOST    -
  4 SHA-384 -
 base64 DIGEST      Key digest

TYPE44 SSHFP Secure shell key fingerprint [RFC4255]
 uint8 ALGORITHM Algorithm
  1 RSA   -
  2 DSS   -
 uint8 FP-TYPE   Fingerprint type
  1 SHA-1 -
 hex FINGERPRINT Fingerprint

TYPE45 IPSECKEY IPSEC public key [RFC4025]
; uint8 PRECEDENCE   Preference (lower values tried first)
; uint8 GATEWAY-TYPE -
;  1 - IPv4 address
;  2 - IPv6 address
;  3 - Domain name
; uint8 ALGORITHM -
;  1 DSA - [RFC2536]
;  2 RSA - [RFC3110]
; ipv4/ipv6/name GATEWAY -
; base64 PUBLIC-KEY -

TYPE46 RRSIG DNSSEC resource record signature [RFC4034]
 rrtype TYPE-COVERED Type covered
 algo   ALGORITHM    Signature algorithm
 uint8  LABELS       Non-wildcard label count
 uint32 ORIG-TTL     Original TTL
  interval
 time   EXPIRATION   Expiration time
 time   INCEPTION    Inception time
 uint16 KEY-TAG      Key tag
 name   SIGNER       Key name
 base64 SIGNATURE    Signature data

TYPE47 NSEC DNSSEC next resource record [RFC4034]
 name NEXT  Next domain name
 nsec TYPES Resource record types present

TYPE48 DNSKEY DNSSEC public key [RFC4034]
 flags16 FLAGS Flags
  256 - Zone key
  128 - Revoked
  1   - Secure entry point (KSK)
 uint8 PROTOCOL Protocol
  3 - DNSSEC
 algo   ALGORITHM  Algorithm
 base64 PUBLIC-KEY Public key data

TYPE49 DHCID DHCP client identifier [RFC4701]
 base64 - -

TYPE50 NSEC3 DNSSEC hashed resource record existence [RFC5155]
; uint8  - Hash algorithm
;  1 - SHA-1
; flags8 - Flags
; uint16 - Iterations
; uint8  - Salt length
; hex    - Salt
; uint8  - Hash length
; base32 - Next hashed owner name
; nsec   - Resource record types present

TYPE51 NSEC3PARAM NSEC3 parameters [RFC5155]
; uint8  - Hash algorithm
;  1 - SHA-1
; flags8 - Flags
; uint16 - Iterations
; uint8  - Salt length
; hex    - Salt

TYPE55 HIP Host Identity Protocol [RFC5205]
; uint8  HIT-LEN HIT length (missing in presentation format)
; uint8  PK-ALGO Public key algorithm
; uint16 PK-LEN  Public key length (missing in presentation format)
; hex    HIT     -
; base64 PK      Public key (no whitespace allowed)
; name   -       Rendezvous servers
;  multiple

TYPE99 SPF Mail sender policy framework [RFC4408]
 text TXT-DATA -
  multiple

---

From: "John R Levine" <[email-masked]>
Date: 6 Sep 2016 15:40:06 -0400

> needs would have to have a custom-coded parser/serializer.

I'm close to that.  If a field is odd but it's a minor variant of 
something else, such as the hex fields with optional hyphens or dots, it's 
easy enough to include.  Or if it seems like it might be useful in the 
future, like a trailing list of domain names which could show up in 
something like CLONE, might as well.

Beyond that, I don't think anyone will ever reuse the odd arithmetic in 
LOC or the data-dependent formats in IPSECKEY, so if I do anything for 
them, it'll be something like Z[LOC] or Z[IPSECKEY] meaning do the 
appropriate special hackery for that record type.

Not sure what to do with the type bit maps in NSEC.  They're reused in 
NSEC3, and both records are certainly in active use.

> use the field names as a key for localization and for help text.

That's the main change in -08.

R's,
John

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Sep 2016 21:48:28 +0100

John R Levine <[email-masked]> wrote:
>
> I'm close to that.  If a field is odd but it's a minor variant of something
> else, such as the hex fields with optional hyphens or dots, it's easy enough
> to include.  Or if it seems like it might be useful in the future, like a
> trailing list of domain names which could show up in something like CLONE,
> might as well.

Yep.

> Beyond that, I don't think anyone will ever reuse the odd arithmetic in LOC or
> the data-dependent formats in IPSECKEY, so if I do anything for them, it'll be
> something like Z[LOC] or Z[IPSECKEY] meaning do the appropriate special
> hackery for that record type.

Yep. My model was to treat special cases like these as a single field
which just happens to have a particularly complicated implementation -
multiple subfields etc.

> NSEC3, and both records are certainly in active use.

It's worth treating widely used and re-used RDATA fields as reusable
field types :-)

I'll have a look at your latest draft.

Tony.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 21 Sep 2016 11:29:15 -0700

> RTYPE? Each RTYPE has a defined format, right?

Sure, but some of those types don't have definitions of names for the 
presentation format, and some of the early ones have less-than-clear 
names. Also, for RTYPEs that have multiple parts to the RDATA, what 
would it mean to get an answer that had only some of them?

> can be found by looking at the name.

Good suggestion!

> generally default to case-sensitive comparisons...

No, but I will say the opposite, which is more deterministic for 
receivers.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 21 Sep 2016 11:39:36 -0700

> implementations would need to unescape it themselves rather then let

Got it. I'l add a new bit to the Security Considerations about 
double-escaping.

> Could be simplified by just using base64url (or base64).

I think I'll go with B64 and HEX. The reason for two encodings is that 
hand-editing
HEX is definitely easier than Base64, but DNSSEC keys are often 
expressed as
Base64.

--Paul Hoffman