Re: [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap

[Carsten Bormann <[e-mail]>]

On 15. Aug 2022, at 17:11, Ted Lemon <[e-mail]> wrote:
> 
> This is a good question. I think we’d want to understand what the actual use case is for DNS-over-CoAP before proceeding with this,

The main use case is systems that already implement CoAP and do not want to add machinery for some protocols that are used only for very specific purposes.

> since DNS-over-DTLS would obviously be less costly to implement.  

I’m not sure about that, not even in the case where you already have DTLS (and certainly not where you don’t have it because you are using OSCORE).

> The stated use case of this document is to encrypt DNS packets, which is already addressed by DNS-over-DTLS, so if that’s the only motivation for this work, it doesn’t seem like something the IETF should be doing.

See above.

> I’m sure one argument for DNS-over-CoAP is that on-path caching provides some benefit, but it also quite likely breaks the semantics of DNS, so it’s not clear to me that this is actually a good idea. I suspect the thing you need to build to make this work well is a lot more complex than simply a CoAP encapsulation. If this is an important use case, then it might be better to just put a DNS cache at that point in the path; it seems unlikely that the benefit of leveraging an existing CoAP caching strategy would justify the problems such a strategy would create.

I’ll leave that to the authors; obviously, all caches have limitations, but being able to make use of CoAP caches along the way would be an improvement.

> I’d be curious to know if there’s a way to actually compress a DNS packet using CoAP, and that could then make the dns-over-coap use case more interesting. However, the current proposal doesn’t do that, so what it appears to really be doing is adding a layer of complexity and extra bytes to the packet.

That can definitely be done (for a definition of “compress” — a concise form for some DNS data might be a better approach), but it to me it seemed working out the protocol machinery first is the right way to proceed here.  (From the point of view of the CoAP protocol, this would just be a separate media type.)

Grüße, Carsten