Hello. On 1/29/20 11:57 AM, Shane Kerr wrote: > One possible application of this might be to allow a resolver to > extend the TTL of an entire zone.
Overall I suspect the TTL-extending use case might be sufficiently different (and much more complicated) to consider separately/independently. > As far as the wire format & protocol behavior, I think the changes > from this draft needed would be: > > * Returning the entire signed SOA in the additional section, rather > than just the serial in an EDNS record (for DNSSEC validation purposes). > * Including an EDNS option in the response indicating that it is okay > for a resolver to extend the TTL of other records in the zone I haven't thought that much about it, but I'm not convinced that validating the SOA (serial) would really help. The main related problem I see is signature validity of the records that get extended, i.e. all/any of them and not just SOA. As long as RRSIG of an RRset holds, resolvers can be "spoofed" to serve that RRset, regardless of original TTL... so why would the attacker bother to spoof SOA serial instead? On the other hand if RRSIG expires, I don't think even validating SOA serial would be enough to keep serving this RRset, as e.g. downstream couldn't validate it normally. > Even just using SOA in the response instead of the serial in an EDNS > record would be enough to allow later work on the TTL-extending > technique, if we're squeamish about adding to the DNS camel. 😊 In suitable zones (e.g. root) I can imagine the resolver explicitly querying for SOA in order to extend all the TTLs (though not beyond RRSIG validity). Still, generally there needs to be at least some way for zones to opt out from any such TTL-extending technique. Maybe utilizing ZONEMD should be considered instead. --Vladimir _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
