Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt

P Vix <> Tue, 11 July 2017 07:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9EECE1319BB for <>; Tue, 11 Jul 2017 00:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CPBD6ExVavq1 for <>; Tue, 11 Jul 2017 00:34:16 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFCBD124D37 for <>; Tue, 11 Jul 2017 00:34:16 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 2EFBC61FF3; Tue, 11 Jul 2017 07:34:14 +0000 (UTC)
Date: Tue, 11 Jul 2017 07:34:12 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----HPOXWAIERH5PWOXF9I1SKCYU4X06LC"
Content-Transfer-Encoding: 7bit
To:,=?UTF-8?Q?Petr_=C5=A0pa=C4=8Dek?= <>
CC: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= <>
From: P Vix <>
Message-ID: <>
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-03.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jul 2017 07:34:20 -0000


On July 11, 2017 3:17:57 PM GMT+08:00, "Petr Špaček" <> wrote:
>Hello dnsop,
>reading throught the latest version, I object to the proposed TLV
>I feel that implications from switch to non-RR format are
>and following e-mail attempts to explain why I believe it is a bad
>Please accept my apology for such long e-mail.
>1. Parsing the new format itself is not the hard because it is similar
>to other rdata, even though not very same (see below).
>2. The hard part is integration into rest of the program and "wider
>ecosystem" including all the bells and whistles.
>This includes:
>- from_wire/to_wire conversion
>- from_string/to_string conversion
>- ability to log and process those logs
>- support in traffic analysis tools
>- support in data formats used for storing DNS messages
>It is *very important* to consider that there is plenty of software
>which do not need to understand DNS semantics but just DNS message
>format (message collectors, statistic tools etc.).
>3. We need to keep in mind that introducing very new format (instead of
>using <owner,class,TTL,rrtype,rdata> structure) change affects not only
>servers and resolvers but everything in DNS ecosystem, *including data
>formats* used to store messages.
>Can we represent messages with the new format in dnstap, C-DNS, and all
>the DNS_in_JSON flavors? If not, how should we handle this problem?
>Why it is harder to implement it everywhere that it seems
>The main reason is that every DNS software already has its own set of
>utility functions for operating on RR format. Switching over to a TLV
>format gets more complicated when we start speaking about
>logging/filtering and other integration aspects because will have to
>include new conditions in all code paths as well.
>Why is this so different from adding new RR type? New RR type and new
>TLV format surely need new code for en/decoding, but again, this is the
>easy part.
>The main problem integration with everything else. Normal RR processing
>already has all the abstraction and APIs ready, including all sorts of
>utility functions.
>I.e. existing message matching code will have to be extended with
>if (opcode == SESSION_SIGNALING) {
>    // comparison function for SS
>} else {
>    // comparison function for normal data
>Similarly when it comes to logging, it is not just calling log_rr()
>anymore. It is now
>if (opcode == SESSION_SIGNALING) {
>    // log function for SS
>} else {
>    // log function for normal data
>I will try to describe an example with python-dns library (because it
>small and easy to read, it would be the very same for e.g. Knot
>If we used normal RR format, it is just matter of dropping one file
>(e.g. rdtypes/class/ with methods for en/decoding. The existing
>infrastructure of the library would take care of all the message
>(incl. handling of malformed/truncated messages etc.), printing,
>comparison, logging etc. and all this "integration" is "for free"
>because the libraries already have it for everything in RR format.
>[In fact, when we talk about normal RR format, we might not even need
>write the en/decoders! Right now we are working on an prototype
>implementation of
>which generates en/decoders "for free".]
>By diverting from RR format we will lose all this.
>For example in CZ.NIC we are maintaining several tools which do not
>to "understand" semantics of DNS messages but have to parse them. All
>these would have to be modified. RR-based format will "just work" with
>these because support for uknown RR types is already there.
>Of course, there needs to be code to do the actual session logic, but
>re-use of existing infrastructure allows developers to focus on the
>session logic and not on re-inventing the integration.
>Why TLV format is not effective as fool-proof measure
>DNS servers should already be returning NOTIMP for unknown opcodes
>already so it should be sufficient counter-measure to avoid getting
>records into caches etc.
>In any case, the new TLV format does not prevent people from doing
>mistakes (or attacks) and sending SS data along with non-SS data, i.e.
>there has to be code to handle these error cases regardless of format.
>If we can agree on the previous point, i.e. necessity to handle bad
>messages anyway, we are left with problems related to caching/AXFR.
>gets us to the very same situation as with OPT RR which has similar
>semantics and definitelly should not get into cache/AXFR, etc. I.e.
>similar measures can be re-used insted of inventing new ones.
>If we consider that there is plenty of software reading DNS traffic,
>e.g. for doing statistics, testing software which read/generate DNS
>messages etc., the new TLV format is unnecessairly hard to implement in
>rest of the DNS ecosystem. Sticking to standard
><owner,class,TTL,rrtype,rdata> format would solve this particular
>Thank you for your time and attention.
>Petr Špaček  @  CZ.NIC
>On 4.7.2017 01:40, wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> This draft is a work item of the Domain Name System Operations of the
>>         Title           : DNS Session Signaling
>>         Authors         : Ray Bellis
>>                           Stuart Cheshire
>>                           John Dickinson
>>                           Sara Dickinson
>>                           Allison Mankin
>>                           Tom Pusateri
>> 	Filename        : draft-ietf-dnsop-session-signal-03.txt
>> 	Pages           : 27
>> 	Date            : 2017-07-03
>> Abstract:
>>    This document defines a new Session Signaling OPCODE used to
>>    communicate persistent "per-session" operations, expressed using
>>    type-length-value (TLV) syntax, and defines an initial set of TLVs
>>    used to manage session timeouts and termination.  This mechanism
>>    intended to reduce the overhead of existing "per-packet" signaling
>>    mechanisms with "per-message" semantics as well as defining new
>>    signaling operations not defined in EDNS(0).
>> The IETF datatracker status page for this draft is:
>> There are also htmlized versions available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at:
>DNSOP mailing list

Sent from my Android device with K-9 Mail. Please excuse my brevity.