On Mon, 2021-05-10 at 12:37 -0400, Hugo Salgado 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/
Thanks Hugo, that is useful. In section 3.2, 'the resource record of the ANSWER section' is ambiguous. The answer section can contain many resource record (s/sets). I suggest a reference to 'QNAME (original)' from RFC8499, or a careful copy of the words in that definition. Also in section 3.2, I do not think responding with the option should be limited to NOERROR. Specifically, I'd very much also want it to work for NXDOMAIN, and I can imagine some cases of it being useful even in SERVFAIL cases (at least in database-driven name servers like PowerDNS, where individual records inside a zone can be broken). > 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 agree, and I do not think this is a reason to not have this feature. > 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. +1 > And responding to the comment that having multi-queries is better, is > something that is long overdue, and would certainly make this hack > obsolete. Multi-query has not happened. I doubt it will happen. And in fact, mapping this specific use case onto it would limit implementations. I can imagine multi-query being implemented in some proxy/frontend, that sends out parallel queries to 'simpler' auths that do not even know about multi-query, and then the atomicity is gone. > 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. To expose it in resolvers, resolvers would have to set the option on all their outgoing queries, so that they can remember the serial involved in each RRset that they got. I don't think this puts a big burden on storage requirements, but adding EDNS options to all your resolver-to-auth traffic is always a gamble, finding out which auths will suddenly return SERVFAIL, or REFUSED, or just drop your query - or, in some observed cases, tell you NXDOMAIN because they're confused. Now, those auths are wrong, and should not exist, but I trust there will be some reluctance in deployments. That said, supporting this feature in resolvers does not require any changes to the protocol itself; the EDNS option, as your draft currently defines it, looks fine to me. Of course, if the document does want to support the resolver case, it should explain what that means. (Unrelated to anything above, I can see reasons to put the whole SOA in there instead of just the serial; this also reinvokes the 'why not put it in AUTHORITY or ADDITIONAL' question, but I really like the short EDNS option that does not change the processing of any RRsets from a query response.) Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
