Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

[Hugo Salgado <[e-mail]>]

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 <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dnsop
> > >
> > 
> > 
> > -- 
> > Mauricio Vergara Ereche
> > keybase.io/mave



> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop