On Jun 6, 2023, at 8:06 AM, Philip Homburg <[email protected]> wrote: > >> One large problem with publishing a protocol as "experimental" is >> there is not objective way to exit that status. There are no criteria >> that say "this experiment succeeded" or "this experiment failed". >> >> It will take much less IETF effort to fix the charter now than it >> will to move the already-deployed protocol to standards track. We >> might as well bit the bureaucratic bullet now and just fix the >> charter. If most folks agree, I can do that work. > > This draft seems fine as an experiment, but as standard, maybe there are > some operational considerations that need to be addressed.
We still have time to add those known operational considerations. In fact, we should be listing those even if this is an experimental RFC. > The first is that at the moment some people are serving different content on > port 853, from what they are serving on port 53. If so, they are not following the draft: An authoritative server implementing DoT or DoQ MUST authoritatively serve the same zones over all supported transports. If both DoT and DoQ are offered, a nameserver's reply to a particular query MUST be the same on both transports (with the possible exception of how the TC bit is set). Which authoritative servers are serving different content on 853, and what are the differences? We should certainly discuss that in the draft. > I can't quickly find > anything in this draft on how to reach those people or how to deal with > that. How to reach them: no idea. How to deal with that: it's prohibited with MUST-level language. > Current users of port 853 are not implementing this draft. So it > may take then considerable time to sort out this issue. Are you talking about authoritative servers or the client-facing side of recursive resolvers? If the latter, that's very clearly out of scope for this document (or any document other than the DoT spec). But if it authoritative servers doing something else on 853, we should certainly cover it. > If this draft becomes a standard, 'almost overnight' traffic seen by > authoritative servers may switch from almost exclusively UDP to port 53, to > TLS or QUIC to port 853. It seems that the draft is rather weak in looking at > the operational impact that could have. If you have suggestions for what more could be said, we'd be happy to add them. Note that the DNS traffic will not automatically switch to TLS or QUIC: probe traffic will increase. The DNS traffic will only switch if the authoritative server operators turn on the service. The increase in probe traffic is covered throughout the document, but if you think that adding more in a particular place would help reduce negative impacts, please say where and we can add it. > We also don't know much on how this affects recursive resolvers. The draft > says in Section 4.6.10: "a recursive resolver following this guidance may > also choose not to initiate new connections for encrypted transport". It > is not great to have security related standards where the implementor may or > may not implement the feature that is discussed. I don't understand this. All security protocols are optional. The existence of this draft, when it becomes an RFC, does not force any client to use it, just as no resolver is forced to set the DO bit on queries and then interpret the DNSSEC material in the responses. > Maybe we should first experiment, and then create an updated document that > becomes a standard. Yep, that's what we are discussing. What criteria would you use to determine the success of the experiment? --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
