Subject: [Taps] ENDS0

From: Ted Hardie <[email-masked]>
Date: Fri, 29 Mar 2019 12:30:05 +0100

Howdy,

At the mic I was pointing out that there were cases like EDNS0 options that
resulted in fairly significant changes to the operations of a protocol, and
that these can be combined in ways to produce a number of different
combinations.  My concern is that creating a general purpose framer for all
of these combinations may be difficult or ossifying, as new options
continue to be introduced.  I can see it as a potential implementation
choice, depending on the generality required, but I can also see
implementations where allowing the DNS  application to manage this results
in both simpler and more correct behavior.

Among EDNS0 options to consider here are things like the TCP-specific
options ( ends-tcp-keepalive <https://tools.ietf.org/html/rfc7828>), the
addition of padding <https://tools.ietf.org/html/rfc7830>, or the use DNS
cookies <https://tools.ietf.org/html/rfc7873> in different transports.
There are also potential odd cases like CHAIN
<https://tools.ietf.org/html/rfc7901> or EXPIRE
<https://tools.ietf.org/html/rfc7314>which are intended to be used only in
specific relations.

I remain pretty convinced that DNS is a good customer for TAPS, but it is
my personal impression that more discussion is needed to understand whether
this layering helps or hinders that going forward.  I'm glad to know that
it will be a topic for the interim, and I'll try to attend.

Ted