enhancement: add a new socket protocol for DNS over HTTP/3 ?

[dmachard]

Hello,

What is planned regarding the DNS over HTTP/3 support in the protobuf dnstap schemas ?

DNS over HTTPS (DoH) is commonly used with HTTP/2 or, more recently, with HTTP/3 over QUIC.

I asked that because it involves different transports (HTTP/2 over TCP for DoH and HTTP/3 over QUIC over UDP for DoH3)
We risk losing valuable information if we use the same SocketProtocol DoH=4

What the preferred way is ?

Denis

[edmonds]

The "DOH" dnstap SocketProtocol value is defined as meaning the RFC 8484 transport was used:

dnstap.pb/dnstap.proto

Line 64 in 1061e3e

DOH = 4; // DNS over HTTPS (RFC 8484)

RFC 8484 recommends HTTP/2 or better, meaning it can be used with HTTP/2 or HTTP/3 (and I guess HTTP/1 if you want performance to be bad):

5.2.  HTTP/2

   HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use
   with DoH.

   The messages in classic UDP-based DNS [RFC1035] are inherently
   unordered and have low overhead.  A competitive HTTP transport needs
   to support reordering, parallelism, priority, and header compression
   to achieve similar performance.  Those features were introduced to
   HTTP in HTTP/2 [RFC7540].  Earlier versions of HTTP are capable of
   conveying the semantic requirements of DoH but may result in very
   poor performance.

So I think it would be misleading to introduce a new SocketProtocol value "DOH3" that means specifically DoH when used with HTTP/3, because it would retroactively make the existing "DOH" value ambiguous. And it probably makes it prospectively ambiguous too, since there would be a genuine question of whether an implementation had been updated to distinguish between the DOH and the hypothetical new DOH3 value. And if you're consuming dnstap payloads for analysis purposes you would need to specifically test .socket_protocol against multiple values if you were interested in knowing whether a message was carried over DOH (any HTTP version).

Right now if you set SocketProtocol in a dnstap payload to DOH it means the RFC 8484 DNS over HTTPS transport, HTTP version unspecified, and that meaning should be carried forward.

I think the right thing to do would be to introduce a new optional HttpProtocol field for the Message type which means, for SocketProtocol values that indicate the message was carried over HTTP, which HTTP version was used. Right now I think that would only apply to DOH but it's not inconceivable that there might be a future HTTP-based DNS protocol that is not the RFC 8484 DOH protocol.

So something like:

enum HttpProtocol {
    HTTP1 = 1; // HTTP/1.1
    HTTP2 = 2; // HTTP/2
    HTTP3 = 3; // HTTP/3
}

[…]

message Message {
    […]
    optional HttpProtocol http_protocol = […];
    […]
}

And then if you capture a DOH message with dnstap you would set .socket_protocol = DOH and if you also happen to know which HTTP version was used you could also set (but would not be required to set) e.g. .http_protocol = HTTP2 or .http_protocol = HTTP3.

[rgacogne]

Hi! PowerDNS DNSdist developer here :) I agree that adding a new optional field for the HTTP version is a very good option, and a better one than adding a new socket protocol 👍

[johnhtodd]

I agree with the addition of an optional field, as it captures more of the relevant data. The use of HTTP/1 is not entirely off the table (limited use cases, but it exists) so adding an additional field makes more sense for completeness, rather than addition of a large matrix of new socket protocols, excluding some in some subjective way, which may need to be updated again in the future, which seems fragile and not complete.

[edmonds]

I just submitted a PR to add a new http_protocol field, please leave a comment or a 👍 on #21 if you want to see this merged.