On 15:26 29/01, Vladimír Čunát wrote: > 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. >
I think so, too. The original technique aims at debugging, so it does not consider the spoof factor, and being hop-to-hop it is not allowed to be exposed in resolvers either. This extension could still be useful in that use case if we can take advantage of a future secure resolver-authoritative channel (ADoT), assuming we can get aroung the other problems (RRSIG expirations, authoritative signaling, etc). Anyway, if it's adopted and WG agreed, we could change this draft to the "complete SOA+RRs in additional" answer, and it will certainly solve my original debugging need O:) Hugo > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
