> On Feb 3, 2021, at 3:24 PM, Michael StJohns <[email protected]> wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > 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.
I agree its not specifying a change in how servers work. And I agree its specifying a change in data parameters. But I don't agree that NSEC TTLs get set by humans. Certainly not in the same way that other TTLs do. So in my view this is really implementation advice, not operational advice. > > 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" 4034 probably should've said nothing about NSEC TTLs and just left it to 4035. Where this draft updates 4035 to say "The TTL value for any NSEC RR SHOULD" I think it might be better to say "each NSEC RR" rather than any? > > 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. I think the draft already explains why that it not always possible. The client might not have any other information that it can use to do the right thing. But as Paul is suggesting upthread if the client does have the other information (SOA) then yes, it could change its caching behavior. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
