Request text duplication

[chrysn]

Using the application/dns-message format means following general DNS practice that the request is more or less echoed in the response. (The queries are part of the response). This makes sense in DNS where there's only the transaction ID, but less so in CoAP where there's cryptographic request/response protection.

Are there any mechanisms of DNS that'd allow us to elide the queries from the response?

If so, I suggest we recommend them with some level of normativity.

If not, then this probably won't change short of using alternative serializations (which I understand to be in scope for add-ons in this document), but should be pointed out, stating that wire efficiency is traded here for cognitive (transferring established DNS concepts) and implementation (where responses are fed to a local DNS-ish processor) complexity.

[chrysn]

Looking a bit deeper into how DNS packets are made up, I learned that there is internal lookup compression used when a name's text starts with 0b11 (where otherwise there are zeros from a label being less than 64 byte long). I found no specification that'd describe other use of other patterns there (say, a 0b01 that'd indicate a string offset in the request rather the response), so probably there's no such specification and we fall to the "If not" branch.

(It would barely pay to send responses without the requests without such cross-references, as without the internal lookup the response records would just again contain all the long text from the requests).

[miri64]

One could just set qdcount field of a DNS response to 0 and not include the question section. All information needed to figure out to what question the record is an answer for should be present in the answer section. However, any change to the message format makes the implementation of a simple DoC-to-DNS-proxy more complicated. Currently such a proxy would only need to replace the transaction ID of the DNS query and response (in case the client implementation decides to honor the SHALL on setting that field to 0 for cache-friendlyness) as the only modification to the DNS messages.

[chrysn]

With the compression inside the response, that alone won't do much good; it'd turn a response that currently has a c0 xx name reference into one that repeats the name just again.

As for implementation complexity, the nice thing about application/dns-message is that a simpler server can just not do any of these tricks -- but alas, there seem to be no existing viable tricks.

[miri64]

So the question is if we should skip application/dns-message altogether in the draft opting for a more compressed format or to move the latter to a follow-up draft. In my opinion, we should stick to application/dns-message for now, point out the drawbacks and add considerations on a later format (e.g. based on CBOR).

[chrysn]

I agree with you. As we can't do anything within the existing dns-message (that we can recommend or even make mandatory), all this becomes just a point to be documented. Text suggestion:

For a CoAP based protocol, the use of application/dns-message is suboptimal: The requested names are sent in the response, even though the protocol and its security mechanisms provide strong request-response bindings that this information could be implied.
The message format is used nonetheless because its ease of integration with existing DNS applications. Alternative media types can be used that perform better on the wire, but they can not be expected to be supported by DoC servers unless advertised.
Note that just leaving the question section of the response empty would do little for the message sizes, as the names are part of the response. They are usually compressed using the DNS format's internal message compression ({{rfc1035}} Section 4.1.4), so eliding questions would just make larger answers.

Alternative formats (either DNS serialized in CBOR with consideration for request-response binding, or even more getaddrinfo-like subsets of DNS) can still be added later on, in follow-ups or appendices, and be optional and to-be-negotiated.

[miri64]

The message format is used nonetheless because its ease of integration with existing DNS applications. Alternative media types can be used that perform better on the wire, but they can not be expected to be supported by DoC servers unless advertised.

"[…] existing DNS applicaitons and use cases.", I would say, but otherwise it makes sense to add this. Question is where.

[chrysn]

Question is where

That's why this is not a PR ;-) -- I'll just try to keep it in mind while the document grows and place it when the right point presents itself.

[miri64]

RFC 8427 (Representing DNS Messages in JSON) could be of interest when it comes to other serialization formats of DNS messages ;-).

[chrysn]

Summarizing two points of a recent chat here:

• DNSSec is not a case we'll have to optimize for -- that is verified at the resolver. (If DNSSec were to be used, we'd need to transport all details of the response that are necessary for verification, and that makes responses large again)
• CNAME flattening is a thing that resolvers do (responding host IN AAAA 2001:db8::1 when really the records are host IN CNAME alias / alias IN A 2001:db8::1), as is stripping of responses that the client didn't ask for explicitly. Thus in particular the resolving DoC server may do that, and thus we can look into optimizations for cases normalized into "request for AAAA, here's the set of addresses" as opposed to needing to express variations of "here's a CNAME chain and then an AAAA record" or "here's a AAAA record and by the way these three NS come for free".

[miri64]

• CNAME flattening is a thing that resolvers do (responding host IN AAAA 2001:db8::1 when really the records are host IN CNAME alias / alias IN A 2001:db8::1), as is stripping of responses that the client didn't ask for explicitly.

Mh, I don't think we came to that conclusion... that is just something we proposed in #14.

[chrysn]

Would "that some resolvers do, and that resolvers may do" be correct for the first half (CNAME flattening), and "is something that resolvers may do" for the latter (removing unrelated records)?

[miri64]

I am not sure CNAME flattening is something that resolvers do in general.

[waehlisch]

I am not sure CNAME flattening is something that resolvers do in general.

no. they don't do that in general but some do this, e.g., Cloudflare. (at least in the past, i don't know the current state).

host IN CNAME alias / alias IN A 2001:db8::1

the canonical name is not the alias but the "owner" is the alias (see Section 3.3.1, RFC 1035). in this example, the alias is "host".

[miri64]

Since omitting the question is a big part of https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/, I think we can close this. Or do you disagree @chrysn?

[chrysn]

Yes, let's defer that to dns-cbor; closing.