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

Stephane Bortzmeyer <bortzmeyer@nic.fr> Sun, 16 July 2017 13:51 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 186241200FC for <dnsop@ietfa.amsl.com>; Sun, 16 Jul 2017 06:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9NiHTIyGDs0W for <dnsop@ietfa.amsl.com>; Sun, 16 Jul 2017 06:51:01 -0700 (PDT)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE973129B35 for <dnsop@ietf.org>; Sun, 16 Jul 2017 06:51:01 -0700 (PDT)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id B5DB231CE6; Sun, 16 Jul 2017 15:50:58 +0200 (CEST)
Received: by godin (Postfix, from userid 1000) id 63F23EC0BB8; Sun, 16 Jul 2017 15:44:53 +0200 (CEST)
Date: Sun, 16 Jul 2017 15:44:53 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: dnsop@ietf.org
Message-ID: <20170716134453.GA5654@laperouse.bortzmeyer.org>
References: <149907291397.4998.8059630450980375262@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <149907291397.4998.8059630450980375262@ietfa.amsl.com>
X-Transport: UUCP rules
X-Operating-System: Ubuntu 16.04 (xenial)
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0NQZx6oMitWkzj87CWHS4srSeSs>
Subject: [DNSOP] C-DNS at the Hackathon (Was: I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jul 2017 13:51:04 -0000

On Mon, Jul 03, 2017 at 02:08:34AM -0700,
 internet-drafts@ietf.org <internet-drafts@ietf.org>; 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

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

As already mentioned in
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