Number of additional records in queries

[Brown, Chris]

Greetings to all.

If I am reading the code correctly, in worker.c Unbound locks down the number of records in the additional section to 1 (probably to cover the OPT record), but does not (seemingly) limit it to an OPT record:

              if(LDNS_ARCOUNT(sldns_buffer_begin(pkt)) > 1) {
                                verbose(VERB_QUERY, "request wrong nr ar=%d",
                                                LDNS_ARCOUNT(sldns_buffer_begin(pkt)));
                                return worker_err_ratelimit(worker, LDNS_RCODE_FORMERR);
                }

Now obnoxiously I am going to quote RFC 6891:

   The OPT RR MAY be placed anywhere within the additional data section.
   When an OPT RR is included within any DNS message, it MUST be the
   only OPT RR in that message.  If a query message with more than one
   OPT RR is received, a FORMERR (RCODE=1) MUST be returned.  The
   placement flexibility for the OPT RR does not override the need for
   the TSIG or SIG(0) RRs to be the last in the additional section
   whenever they are present.

This indicates to me that the additional section may have more than one record in it, but may only have one OPT record.  Now it is certainly easy to misread it as saying the OPT record must be alone in a query.  And it is also possible to argue that some of the context the RFC paragraph is in applies to only responses.  And then there is always the most obnoxious thing anyone doing DNS can say which has become an override to everything else... "google answers that".  (Which they do, Google Don't Care(TM) about extra ARs in the query.)  Unbound FORMERRs any query with two or more ARs, in my testing.

So my question is...am I missing something in some RFC that would break the rules to send non-opt records along with OPT records in the ADDITIONAL section of queries?  Or is this just a sanity call Unbound made for...well...some sanity and maybe safety.  Missing something else?

Thanks for your help and thoughts!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20201016/2023074c/attachment.htm>