-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I agree with what Hugo said
I would also like to point out that this draft spirit is aiming to be a debugging tool to be used by humans and not in between servers. If we start introducing all these new use cases in-between servers (like authoritatives signaling secondaries or resolvers storing new data) it would add an inmense amount of complexity that might be out of scope at the moment. Would it be simpler to progress with this as a read-only way to query an authoritative server in an atomic way for what's the current status of a record? I guess if we agree on that, we could expand on a better description or explanation to reflect such intention. Mauricio - -- Mauricio Vergara Ereche keybase.io/mave On 2021-05-10 at 16:37, hsalg...@nic.cl wrote: > 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 -----BEGIN PGP SIGNATURE----- Version: FlowCrypt Email Encryption 8.0.7 Comment: Seamlessly send and receive encrypted email wl0EAREIAAYFAmCZZoQAIQkQrsJmYrknD50WIQSoP40HN6s57D3KCvuuwmZi uScPnffaAJ0dlCkRap3/3U5phundHmQNLztK5QCfUNSsrGOP3l7t06x4XNIG K3Hze2k= =Pgk2 -----END PGP SIGNATURE-----
0xAEC26662B9270F9D.asc
Description: application/pgp-keys
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
