> 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 experiment could just be to gain operational experience. We can be upfront that we don't know what will happen, and encourage people to be careful. > 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. Of course they are not following this draft. After all this is just a draft. They are following RFC 7858 (DoT) and are running a recursive resolver on this port. I don't know if they also have a recursor on port 53, that is very well possible. The problem is that they have an authoritative on 53 but not on 853. The problem is that this draft is essentially updating RFC 7858 without explicitly doing so. > How to reach them: no idea. How to deal with that: it's prohibited > with MUST-level language. The obvious 'solution' is to move this draft to a new port, because 853 is already in use for other traffic. Just adding a MUST that is in conflict with current practice makes for a poor standard. If the problem is small, then experimental is fine and we can start telling people that they have to stop doing this. > 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. Yes, I'm talking about recursive. And that's why I said, the operational aspects are not sufficiently discussed. Marking recursive out of scope does not help when other recursive resolvers connect to such servers. > 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. No, I'm saying it should be experimental because we don't know and should experiment. > 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. Usually, if you say you implement a security standard, it should actually be secure if you follow the standard. It is a bad security standard, if the standard says that you can stop being secure if you are overloaded. That only leads to problems later on. What if TLS would say that you can stop encrypting data if you get overloaded. People would get very upset. > Yep, that's what we are discussing. What criteria would you use to > determine the success of the experiment? The success of the experiement is that operational issues are documented, including operational practices and the feedback of the experiment is used in a new draft that is intended to become a standard. >From https://www.ietf.org/standards/process/informational-vs-experimental/ "If the IETF may publish something based on this on the standards track once we know how well this one works, it's Experimental. This is the typical case of not being able to decide which protocol is "better" before we have experience of dealing with them from a stable specification. Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208)" So I think it best to no longer delay this draft, publish it as experimental and gain experience in how this actually works. _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
