On 5 Sep 2016, at 0:47, Shane Kerr wrote:
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.
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.
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 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.
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?
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".
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.)
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.
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).
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...)
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!".
There are many ways to do things. :-)
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
