On 2023-06-07 23:12 UTC, Paul Hoffman <[email protected]> wrote: > On Jun 7, 2023, at 1:05 AM, Philip Homburg <[email protected]> > wrote: >> >>> 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. > > That's true with every new protocol from the IETF. It would be good to > understand what is different about this protocol for such an experiment. > >>> 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. > > Serving from port 853 in RFC 7858 (DoT) only applies to the client-facing > side of recursive resolvers. It doesn't apply to authoritative servers at all. > >> 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. > > It is not updating RFC 7858 at all. RFC 7858 explicitly applies to the > stub resolver and the client-facing side of recursive resolvers. This > draft applies to the server-facing side of recursive resolvers and > authoritative server. There is zero overlap. > >>From your response above, I take it that you don't have any examples > of authoritative servers already serving on port 853. Please let me > know if that's wrong; if so, please give at least one example. >
Up-thread Stéphane reported ns1.eu.org as an example. Open resolver on 853 and authority for eu.org on 53: | Also, currently, regarding the possible warning to system | administrators about the need for 53 and 853 to be in sync, we | currently find in the wild servers that implement different services on | the two ports. See for instance ns1.eu.org (authoritative for eu.org) | or ns1-dyn.bortzmeyer.fr (authoritative for dyn.bortzmeyer.fr). Both | have authoritative on 53 and an open resolver on 853. Should we | explicitely ban this practice? >>> 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. > > That was discussed in the WG, and rejected. > >> 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. > > Again, you haven't shown any current practice of authoritative servers > serving on port 853. If you can show that, it would very helpful. > >> >>> 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. > > This is unclear. If a recursive resolver has an NS record with addresses, > when would those addresses ever be the client-facing side of a different > resolver? > >>> 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. > > Please be specific about what we don't know so that we can be specific in the > draft. > >> >>> 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. > > Ah, OK. You are asking for the non-opportunistic version of this > protocol, with authenticated probing and never falling back to using > Do53. The WG was not able to get any traction on that idea, despite > many attempts. > >> >>> 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. > > Can you be more specific about "operational issues"? Every new protocol has > operational issues. Which are you concerned about here, and can they be > measured? > >> 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)" > > Earlier in that same document, it says what is an expriemental protocol, and > this draft doesn't match that description at all. > >> So I think it best to no longer delay this draft, publish it as experimental >> and gain experience in how this actually works. > > Without more detail about what you want to observe or measure in this > experiment that wouldn't be observed or measured for any normal > standard, it's hard to agree with that assessment. > > --Paul Hoffman > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- In my defence, I have been left unsupervised. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
