Hi, I like the idea of having a way to add provenance information to responses. However, as with all new proposals, I think what's needed is a careful analysis of alternative ways to achieve the same goal, then an assessment of what's the best approach (which may very well turn out to be RRSERIAL).
Some thoughts on this (some may be new, others not): 1.) multi-qtype --------------- With the proposed extension, we get a response for one and a half queries (whatever was asked, plus a piece from the SOA record). The same thing could be achieved with some generic multi-qtype query method. Ray wrote a draft for this a while ago: https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/ This would facilitate - the debugging use case, - other use cases (as explained in Ray's draft), - enable DNSSEC validation (if requested; note that this is regardless of whether DNSSEC is useful for the debugging use case). If we now introduce RRSERIAL and then end up introducing multi-qtype one day, we'd have two methods for this. This would not be a desirable state (unless there is some extra advantage through RRSERIAL). On a related note, multi-qtype would also allow you to use the same method for other kinds of debugging in the future. For example, you may want to look at the response together with a ZONEMD record, or whatever else may help you debug. 2.) NSID option --------------- The draft says, RRSERIAL helps "recognize the origin of an answer" (supposedly when secondaries are out of sync). There already is a way to do that, using the NSID option (RFC 5001). It works as a part of another query, so no separate query is necessary (dig +nsid ...). The question here would be why another method for discovering the origin should be introduced. 3.) Versioning -------------- The draft says that RRSERIAL is useful for "associating this answer with a respective zone version". We (deSEC) ran into problems several times because we relied on the serial as a version indicator. One of the issue was the following: when customers created a zone, made a change or two, then deleted the zone, and created it again. As we don't keep deleted states, the serial for the recreated zone started counting from its default value, and then often ended up lower or equal to the serial of the old zone last seen on secondaries. If this sequence happens quickly enough that the secondary didn't see the deletion, weird things happen. So, using the serial as a version indicator may be misleading. That's not to say that it is not useful; my point is rather to ask whether it is wise to introduce more of it. I would expect that once it is there, automation tools will start using it, and edge cases will be forgotten. Thinking about multi-qtype again: Ray's draft has it such that multiple qtypes can be queried for the same owner name only. That means that SOA could only be queried in an apex query. The RRSERIAL method does not have this issue, which is certainly favorable. Cheers, Peter On 5/28/21 4:26 PM, IETF Secretariat wrote:
The DNSOP WG has placed draft-salgado-dnsop-rrserial in state Call For Adoption By WG Issued (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
-- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
