[DNSOP] C-DNS at the Hackathon (Was: I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

[Stephane Bortzmeyer <[e-mail]>]

On Mon, Jul 03, 2017 at 02:08:34AM -0700,
 [e-mail] <[e-mail]> wrote 
 a message of 45 lines which said:

>         Title           : C-DNS: A DNS Packet Capture Format
> 	Filename        : draft-ietf-dnsop-dns-capture-format-03.txt

Jim Hague and myself worked at the IETF 99 hackathon on C-DNS,
producing a proof-of-concept DNSTAP-to-C-DNS translator
<https://github.com/bortzmeyer/golang-dnstap/tree/c-dns> This raised
some issues.

There is a semantic mismatch between dnstap and C-DNS. C-DNS makes
most information mandatory, dnstap accepts that you omit almost
everything. (The current dnstap-to-C-DNS converter solves the problem
by generating dummy values, such as all-zeroes for IP addresses.)
Should C-DNS be more lax? Some people would prefer the security of
konwing everything is there, some may have the problem that the
information is unknown on the beginning. May be having two profiles of
C-DNS, a "Full" where almost everything is mandatory, a "Partial"
where a lot of things are optional? (Tools could refuse to convert
"Partial" C-DNS files to pcap.)

Many arrays in the spec syntactically allow empty arrays
(Block.queries, BlockTables.ip-address, etc). When the field is
optional (BlockTables.qrr), it means there are two ways to omit the
array: not having the field at all, and having the field going to an
empty array. Is it a good thing to have both?

When the field is mandatory (BlockTables.classtype), what is the use
of an empty array? Note that we cannot refer to an empty array: the
draft says 'An index value of 0 is reserved to mean "not present".'
but it is not accepted by the current tools (Compactor). Is the tool
wrong?

I find no way to indicate in C-DNS the bailiwick of the response, or
the fact that it was a cache hit or miss in the resolvers. These are
two important information in dnstap, that you cannot get by sniffing
the traffic. May be related to the "private extensions" discussion
<https://mailarchive.ietf.org/arch/msg/dnsop/K7ZnFFa3tW0QDZnJXgef0-1WzOA>?

As already mentioned in
<https://mailarchive.ietf.org/arch/msg/dnsop/WBdp12r1NFOPeUW6H60SdohRI6o>,
the fact that keys are always integers and not the strings used in the
description is not obvious. A warning would be welcome.

There is no mention of the CBOR encoding of the maps and arrays. Can a
C-DNS producer use at will indefinite or definite lengths? Should it
be explicit in the draft or do we think that "Read RFC 7049, you CBOR
n00b" is enough?

Should we have an "advice to implementers" section? For instance, if a
C-DNS producer runs for a long time and then crashes, losing the
opportunity to add a CBOR break at the end of an array, the file
becomes corrupted (pcap does not have this problem). Is it worth a
warning?