[dnstap] Adding support for DoT and DoH

[Robert Edmonds]

Chris Mikkelson wrote:
> On Mon, Dec 07, 2020 at 09:31:10AM +0100, Vladimír Čunát wrote:
> >    Hello.
> > 
> >    We'd like dnstap to represent the new-ish standardized transports.  In
> >    our use case it will be sufficient to trivially extend the
> >    corresponding enum, so we suggest to do that step now and we can think
> >    of additional related extensions later.  Any comments?
> 
> My main concern here is with extending SocketProtocol.
> While DoT implies TCP, DoH may also be UDP (QUIC) if
> used with HTTP/3. In that case, mixing DoH in with the
> SocketProtocol values would conflate an HTTP/2 and HTTP/3
> DoH service on a single host.
> 
> Thus, I would suggest moving DoT and DoH to a separate
> field, say "tunnel_protocol" with a corresponding enum.
> Better name suggestions are very welcome.
> 
> Does this sound workable and worthwhile?

It sounds like you're proposing to continue setting socket_protocol to
TCP or UDP depending on the underlying IP protocol in use by a DoH/DoT
connection?

Existing code that processes dnstap Message payloads expects the
socket_protocol field to be set. Any currently existing code would be
oblivious to any fields newly added in a future revision of the
dnstap.proto schema, of course.

If the dnstap.proto schema were extended to also set a new field for
DoT, DoH, etc. but the socket_protocol field were to continue to be set
to UDP or TCP (e.g., new dnstap writers set socket_protocol to the TCP
enum and "tunnel_protocol" to a DoT enum) then this leads to an
ambiguity for old readers: they would silently process DoT messages as
if they had been received over an RFC 1035 § 4.2.2 TCP connection.

What I think old dnstap readers that care about the value of the
socket_protocol field and that have not been updated to handle
DoT/DoH/etc. payloads as defined by a dnstap.proto schema update should
do when encountering new kinds of DoT/DoH dnstap payloads is either
discard those messages, throw an exception, or otherwise handle them as
an "unknown" kind of dnstap Message in whatever fashion was selected by
the original developer of the old dnstap reader. They should not
silently be treated as a different kind of dnstap Message just because
the reader hasn't been updated to also process a newly defined field.

I never really meant the SocketProtocol enums to mean the literal IP
protocol numbers (otherwise I would have assigned TCP to be value 6 and
UDP to be value 17). I like Vladimír's suggestion but I think it
requires taking the "socket" and "transport" terms a little less
literally. I.e., by "transport" protocol we don't mean the OSI Layer 4
transport protocol, but rather the "DNS transport protocol", which is a
little less clearly defined. Something like:

// SocketProtocol: the protocol of the socket or connection used to
// transport a DNS message. This specifies how to interpret "transport
// port" fields or other fields occurring in "Message" payloads.
enum SocketProtocol {
    // RFC 1035 section 4.2.1 DNS over UDP transport.
    UDP = 1;

    // RFC 1035 section 4.2.2 DNS over TCP transport.
    TCP = 2;

    // RFC 7858 DNS over TLS.
    DOT = 3;

    // RFC 8484 DNS over HTTPS.
    DOH = 4;
}

If you need additional instrumentation (such as in the HTTP/2 [TCP] vs
HTTP/3 [UDP] on the same host corner case) to be able to distinguish the
IP protocol I suspect it would make sense to define new submessages that
can optionally be included in dnstap Message payloads, e.g. "dot_info"
and "doh_info", should a dnstap writer want to log additional
information about the underlying connection like TLS or HTTP version
numbers or other fields (e.g. it's somewhat common to log the TLS cipher
suite used).

-- 
Robert Edmonds