On Feb 3, 2021, at 3:24 PM, Michael StJohns <[email protected]> wrote: > > On 2/3/2021 2:31 PM, Paul Hoffman wrote: >> On Jan 29, 2021, at 9:31 AM, Michael StJohns <[email protected]> wrote: >>> I can't support this as Standards track even though it purports to update >>> standards as it doesn't actually specify an implementable protocol. >>> Basically, this is dependent upon humans doing the right thing, rather than >>> specifying behavior of the protocol. >> I don't understand the context of this. The draft specifies that the >> protocol is changing, and now authoritative servers change the way they act >> from $x to $y. Where is the "humans" part? > > You're not specifying a change in how the Auth servers work AFAICT, you're > specifying a change in the data parameters for a few records which get set by > humans (and maybe enforced by tools, not necessarily by the server).
This seems like a deep misreading of RFC 2308. Section 3 says: Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. "The TTL of this record is set from" means that the value *in the SOA that is returned* is set to the minimum of $a and $b. I cannot see how this can be read as "The human setting $a of the record sets it as the minimum of $a and $b". That is nonsensical. The sentence is about the TTL in the SOA that is being returned, not the TTL from the record in the file. > This is operational guidance rather than implementation guidance - the > servers continue to serve the data they are provided regardless of whether > its "right" with respect to this guidance. This is implementation guidance: authoritative servers who are about to send out an SOA record need to compare $a and $b, and use the lower of those two as the TTL in the SOA that is sent out. > For example, one of the texts you reference (RFC4034 Section 4) is all about > crafting the contents of the data protocol, rather than what the server > should do to enforce things. It probably should have said instead - "The > authoritative server SHOULD treat (and send) the TTL of the NSEC RR as having > the same value as the SOA minimum TTL field" Yes, exactly! (Notice the lack of humans there.) This draft could update it that way, but to include the "lesser of $x and $y" as well. > But then that gets into signing issues for the NSEC record and its > verification and you'd need to make sure that the signing part of this is > back filled to make sure that what's signed agrees with what the server is > actually sending. Fully agree. A note about that is important as well. > 8198 section 5.4 actually specifies an implementable behavior in that it > tells the client how to treat received and cached data. Agree. >>> For each of these, I'd recommend specifying what a client does in each of >>> the cases, rather than weasel wording the SHOULD with respect to the zone >>> contents to turn this into an implementable protocol. >> Here, I agree that the draft is unclear. It should say explicitly "resolvers >> keep doing $z, there is no change here". Also, for the text about >> authoritative servers, I agree that changing the SHOULDs from the current >> standards to MUSTs. >> >> I note that you didn't appear to accuse the authors of 4034, 4035, and 5155 >> of "weasle wording" when those documents were standardized. Doing so now >> seems out of line. > > As a whole those documents were less specific that I would have liked. > Basically, everywhere there is a SHOULD is a possibility where some resolvers > accept the data and others reject it. > > In any case where see a should, you need companion text to describe what to > do (either on the sender, or the receiver, or both) if you don't follow that > guidance. We agree, and I gave up pleading in the IETF for "every SHOULD needs to clearly explain the exceptions" probably 15 years ago. However, in this case, I think it is better to simply promote these to a MUST. > WRT to the parent documents - as a whole they mix implementable and human in > the loop functions and there's enough of the former to place them as > Standards. But when you extract guidance paragraphs, update them, but then > don't update the client guidance on how to handle the received data, you're > not really updating the standard and hence informational vs standard. Agree. Here, I think that this document should update RFC 8198 to make it clear that the resolver MAY pick the lower of $x and $y in case the authoritative server did not set $x based on this update. >>> E.g. for each of these clauses add something similar to "The client >>> SHOULD/MUST reduce the effective TTL for the received NSEC RR to the lesser >>> of the TTL of the current SOA record, the TTL of the SOA, and the TTL of >>> the NSEC RR record and MUST discard the NSEC RR when that effective TTL >>> expires." >> Again, this is not about the clients, as the document says (but not clearly >> enough). > > And that's really the problem. The client should be able to look at the > incoming data, do a sanity check on it and then do the appropriate things it > needs for self protection. If it can't - if you don't specify it should - > then eventually something will break that's rather unexpected and perhaps > with a very large impact. If this is important enough to make a change at > the server, its certainly important enough to require the corresponding > validation change at the client. Agree. >>> So - not ready for last call. >> Sure it is. These are normal last call comments. > > Given that there was little or not actual discussion on the document, I was > quite surprised to see it go for last call. But fair - "not ready to pass > last call". Good, we are in more agreement here. I'd like to see a bunch of technical changes (including the SHOULD -> MUST for the updated documents), and have a second last call for objections. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
