> On Aug 15, 2022, at 1:34 PM, Carsten Bormann <[email protected]> wrote: > > On 15. Aug 2022, at 17:11, Ted Lemon <[email protected]> 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.
You’re going to have to construct a DNS packet. I presume CoAP is using DTLS, so you have to have DTLS. So again, I don’t see how this reduces complexity. It seems like it adds complexity. > 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. It is not a given that caching with CoAP makes things better. What is CoAP’s caching behavior? How will it handle short TTLs? Reading the document, it’s clear this has not been considered. Given that the whole point of this is to make DNS connections private, I would assume that the cache shouldn’t have the credentials to peek into the packet. Except that it must. So I really don’t understand the threat model here. > 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.) I don’t think this is true. Just because you can do something doesn’t mean you should. Until we can come up with some use case for this that solves a problem that isn’t already solved, I don’t think the IETF should be pursuing this work at all. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
