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 AAAA ...., 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 AAAA ..., 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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
