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 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.
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"
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.
8198 section 5.4 actually specifies an implementable behavior in that it
tells the client how to treat received and cached data.
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.
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.
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.
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".
In a similar vein, I think that the section on "No updates to RFC8198" should
indeed update RFC 8198. The resolver might have the SOA in its cache, and thus could do
the right thing even if the authoritative server has not been updated.
--Paul Hoffman
Longer Discourse -
As I model the DNS, I tend think of it as having three main parts: the
data source (what used to be called the zone master file), the
authoritative servers, and the clients. This is simplistic, but bear
with me. In early days, the authoritative servers generally served
what the data provider gave them, regardless of mistakes (and somewhere
around here I have a number of very broken master files). The AS' were
pass through entities to the point that there's very little text that
says something like "The AS MUST verify.... and MUST NOT serve data that
fails that verification step". Most of the documents talk about
setting this bit or clearing that bit in the data source, but then don't
take the step of indicating that the AS must do a sanity check and
refuse to serve bogus data. E.g. if a human screws up in the provision
of the data the AS screws up.
Separate from the protocol model, most providers of modern DNS AS
implementations tend to treat the data origin tools as part and parcel
of the AS, and does some verification during the record creation
process. But that's an implementation choice, rather than a requirement
of the specification. Mostly that's not a problem, be cause we mostly
do specify the behavior of the client upon receipt of the possibly bogus
data and all of that takes place without a human in the loop.
So I'm fine with the changes to the TTL setting, but you need to impose
the requirement on the client to do the right thing even if the data
creator screws up and does the wrong thing.
Later, Mike
ps - Peter -sorry I missed your immediate response. I think the above
covers your comments as well, but feel free to bring up anything I missed.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
