BADVERS is sent if the server doesn’t support the version in the request. As version 1 has not yet been defined every implementation should return BADVERS to a request with [1..255] in request and the response version version should be 0.
We should have bumped the version when we tightened the specification over the handling of unknown EDNS options but there were too many broken implementations for that to have actually worked. We should make Report Channel be dependent on EDNS(1) but there is still too many broken implementations out there. -- Mark Andrews > On 3 Nov 2024, at 08:57, Casey Deccio <ca...@deccio.net> wrote: > > >> On Nov 2, 2024, at 8:35 PM, Paul Vixie <paul=40redbarn....@dmarc.ietf.org> >> wrote: >> >> The version number in the initiation is the one that the initiator is >> expecting in the response. Probably should have made that an array. >> >> >> On Nov 2, 2024 19:54, Dave Lawrence <t...@dd.org> wrote: >> I agree with your reading. 6.1.3 seems quite clear that request = 0 >> and response = 0-255 is legit. > > (Responding to both messages above...) > > So with the following text: > > If a responder does not implement the VERSION level of the > request, then it MUST respond with RCODE=BADVERS. All responses > MUST be limited in format to the VERSION level of the request, but > the VERSION of each response SHOULD be the highest implementation > level of the responder. In this way, a requestor will learn the > implementation level of a responder as a side effect of every > response, including error responses and including RCODE=BADVERS. > > If requestor sends VERSION 0, responder can send VERSION 0 - 255. Got it. > > But when is RCODE=BADVERS expected from the responder? Two scenarios to > consider: > > 1. Requestor sends VERSION n, responder sends VERSION < n > 2. Requestor sends VERSION n, responder sends VERSION > n > > It seems to me that in case 1, RCODE=BADVERS is always expected. > > In case 2, it depends on your reading. If a responder implements level n, > does it implement all versions < n? If so, then RCODE=BADVERS never makes > sense. Otherwise, the responder's RCODE depends on whether or not they > implement VERSION n; thus, the RCODE cannot be definitively predicted by the > requestor. My reading of the spec seems to imply the former, but Paul's > response seems to imply the latter. > > Casey > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
