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!
