> > Paul wrote: > Evan Hunt wrote: > (I do like the idea of advertising a separate expiry value though.) > i think if we're going to put something into the 20-year deployment funnel > we should treat the fixed costs as high and demand more benefits. that's > where the proposal up-thread came from.
The idea is interesting, definitely. Here's something potentially useful, in terms of "more benefits": As I understand it, there would be signaling on this via another EDNS bit. This makes it effectively orthogonal to DNSSEC. Which means, at least semantically, a response to a query could have meanings for: - The bare RR type - The DNSSEC RR type(s) that go with the response to the bare RR query - The EXPIRY RR type associated with the base RR query - The combination(s) of DNSSEC+EXPIRY RR types And given the DNSSEC RR types that might appear, the corresponding DNSSEC+EXPIRY could allow a zone owner to signal a variety of intents. (Assuming that DNSSEC+EXPIRY records are themselves signed...) There is the potential for a zone owner to indicate whether an entire zone, or perhaps some subset of records from the zone, should be treated as "INSECURE" rather than "INVALID" iff the signature record(s) expire, but where the DNSKEY used for signing is itself correct. Or, alternatively, the zone owner could signal that the default behavior is explicitly correct, i.e. that if for whatever reason, no unexpired signatures can be obtained, that the result should be treated as BOGUS/INVALID. A zone's default EXPIRY could be attached to the SOA record, and the NSEC/NSEC3 records would be able to securely assert the existence/non-existence of an EXPIRY for anything in the zone. Recursives could explicitly determine intent, and pass along the results (proof) to clients. Clients would not need to guess why INVALID or REFUSED happens, which would also benefit DNS operators investigating DNSSEC-related issues. It is work, but I think it adds a lot of value. Thoughts? Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
