Hello everyone. Thanks for the comments, I just uploaded an unchanged version (just to revive it) at: https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/
I agree RRSERIAL doesn't have much relevance in zones that don't give serial versioning a meaning to its content. We can add a paragraph about it, to make the applicability more clear. I also don't think we should start to "deprecate" the SOA serial meaning at this point. One can say that "modern" implementations using complex backends makes SOA serials irrelevant, but there's certainly a use case for classic and mainly static behavior. Just as NSID adds an "infrastructure" identification dimension to a response, RRSERIAL adds the data versioning dimension. And responding to the comment that having multi-queries is better, is something that is long overdue, and would certainly make this hack obsolete. But I think the multi-query issues are so complex that it's worth moving forward incrementally in the meantime. For the same reason, I think we could aim for it to have "experimental" status at the start, and after a few years we measure it to see its use and we can adapt or change it to standard or deprecate it in favor of another qtype. Other issues that I think need more analysis is deciding whether it makes any sense to expose RRSERIAL in resolvers. The original idea was only in authoritatives, but it might make some sense to debug in resolvers as well, to somehow identify the "data source" of a cached record. In this sense, I fear an increase in cache requirements of resolvers, which should somehow maintain the extra data; and also in traffic and option availability for upstream auths. Hugo On 12:47 07/05, Hugo Salgado wrote: > I'll upload a new version to revive it, and ask for a slot > in IETF111 for further discussion! > > Thanks, > > Hugo > > On 22:02 06/05, Mauricio Vergara Ereche wrote: > > Hi Hugo, > > > > I just want to bring back to life this topic as it solves an issue that > > several operators (like me) seem to be in need to solve while debugging > > issues. > > > > Mauricio > > > > On Mon, Jan 27, 2020 at 7:09 AM Hugo Salgado <hsalg...@nic.cl> 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. > > > ----- > > > > > > Best, > > > > > > Hugo Salgado > > > > > > _______________________________________________ > > > DNSOP mailing list > > > DNSOP@ietf.org > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > > > > -- > > Mauricio Vergara Ereche > > keybase.io/mave > _______________________________________________ > 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
