[DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")
Hugo, On 27/01/2020 16.08, Hugo Salgado wrote: Dear DNSOPers, as an operator I tend to have this need to couple an answer for a query to an auth server, with the actual "SOA zone version" used. So I think it'll be valuable to have an EDNS option for it. Here I'm proposing it with this new draft. The 'camel index' for its implementation/hack/proof-of-concept is about 37 lines in NSD 4.1 (more details in Appendix A). I've asked some operators and they see value on it. Is there any support for adoption in DNSOP? - Name: draft-salgado-rrserial Revision: 01 Title: The "RRSERIAL" EDNS option for the SOA serial of a RR's zone Document date: 2020-01-27 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-salgado-rrserial-01.txt Status: https://datatracker.ietf.org/doc/draft-salgado-rrserial/ Htmlized: https://tools.ietf.org/html/draft-salgado-rrserial-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-salgado-rrserial Diff: https://www.ietf.org/rfcdiff?url2=draft-salgado-rrserial-01 Abstract: The "RRSERIAL" EDNS option allows a DNS querier to ask a DNS authoritative server to add a EDNS option in the answer of such query with the SOA serial number field of the origin zone which contains the answered resource record. This "RRSERIAL" data allows to debug problems and diagnosis by helping to recognize the origin of an answer, associating this answer with a respective zone version. One possible application of this might be to allow a resolver to extend the TTL of an entire zone. This is an idea that either Mukund Sivaraman or Stephen Morris came up with a couple of years ago (I can't remember who) and we discussed. The basic idea is that if your zone does not change frequently and uses SOA serial to indicate new versions of the zone, then you can return the SOA serial and then a resolver can "reset" all of the TTL counters for every RR that it has cached in the zone. So, imagine you have: postbox.zone.test MX ..., TTL 900, expires in 460 seconds www.zone.test , TTL 60, expires in 1 second You get back a response for a lookup of an A record for www.zone.test that says that the zone serial for zone.test has not changed, then you could end up with a cache that looks like: postbox.zone.test MX ..., TTL 900, expires in 900 seconds www.zone.test ..., TTL 60, expires in 60 seconds www.zone.test A ..., TTL 60, expires in 60 seconds IIRC this was even suggested in one of the very early DNS RFC as an area for research. The question is whether it is actually worth doing this, as you will have to keep track of the TTL as well as the expiration of each RR, and do the update on each new lookup. Plus if your resolver was optimistically sending such an option with every query, you'd probably only want to include the EDNS option for servers that you think might support it, which means tracking that additional information in the server address cache/database that your resolver has. 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. 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. 😊 Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")
Shane Kerr wrote: > > * Returning the entire signed SOA in the additional section, rather than > just the serial in an EDNS record (for DNSSEC validation purposes). I think it would be more traditional to put it in the AUTHORITY section :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Lough Foyle to Carlingford Lough: Southwest 5 to 7. Slight or moderate for a time in east, otherwise moderate or rough, occasionally very rough in north. Occasional rain or drizzle. Moderate or good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")
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
Re: [DNSOP] rrserial as a path to fame and fortune (was: Adoption of new EDNS opcode "rrserial")
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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
