+1
On July 11, 2017 3:17:57 PM GMT+08:00, "Petr Špaček" <[email protected]> wrote:
>Hello dnsop,
>
>reading throught the latest version, I object to the proposed TLV
>format.
>
>I feel that implications from switch to non-RR format are
>underestimated
>and following e-mail attempts to explain why I believe it is a bad
>idea.
>Please accept my apology for such long e-mail.
>
>
>Overview
>--------
>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
>is
>small and easy to read, it would be the very same for e.g. Knot
>resolver):
>
>If we used normal RR format, it is just matter of dropping one file
>(e.g. rdtypes/class/SS.py) with methods for en/decoding. The existing
>infrastructure of the library would take care of all the message
>parsing
>(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
>to
>write the en/decoders! Right now we are working on an prototype
>implementation of
>https://tools.ietf.org/html/draft-levine-dnsextlang-07
>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
>need
>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.
>This
>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.
>
>
>Conclusion
>----------
>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
>problem.
>
>
>Thank you for your time and attention.
>
>Petr Špaček @ CZ.NIC
>
>On 4.7.2017 01:40, [email protected] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>> This draft is a work item of the Domain Name System Operations of the
>IETF.
>>
>> 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
>is
>> 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:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-03
>>
>https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-session-signal-03
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-03
>>
>>
>> Please note that it may take a couple of minutes from the time of
>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>DNSOP mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/dnsop
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
