Number of additional records in queries

Unbound
1

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™ 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!

2

I think the only other records you can legitimately put in a query are
TSIG, TKEY, and SIG(0).

Tony.

3

This feels like one of those situations where even if there's no prohibition on additional, arbitrary records being included in the additional section, there's also no known reason for a query to include them and hence no reliable behaviour that could be expected of a system processing that query and generating a response.

I don't think 1035 has any clear advice on the contents of the answer, authority or additional sections in messages with QR=0. That document is far from the final word on these matters, of course.

Joe

4

I appreciate both the replies. I thank you and generally agree. My question is more practical, though. And there will be no judgement of the answer (at least by me).

The state of things as I see it now in regards to the referenced additional section record check are:

- A strict reading of the RFCs does not generally prohibit records of any type or quantity in the additional section of queries.
- A strict reading of the RFCs requires a FORMERR response if two or more OPT records exist in the additional section.
- Google and other public DNS services generally answer queries with various records in the additional section.

- Unbound will attempt to process all queries with a single record in the additional section. This record can have any type, including OPT.
- Unbound will send a FORMERR response for any query that has more than one record in the additional section regardless of the type of any of the records.

Is this the desired behavior in the stock Unbound recursive DNS server?

Thank you for your time!

5

I appreciate both the replies. I thank you and generally agree. My question is more practical, though. And there will be no judgement of the answer (at least by me).

The state of things as I see it now in regards to the referenced additional section record check are:

- A strict reading of the RFCs does not generally prohibit records of any type or quantity in the additional section of queries.
- A strict reading of the RFCs requires a FORMERR response if two or more OPT records exist in the additional section.
- Google and other public DNS services generally answer queries with various records in the additional section.

- Unbound will attempt to process all queries with a single record in the additional section. This record can have any type, including OPT.
- Unbound will send a FORMERR response for any query that has more than one record in the additional section regardless of the type of any of the records.

Is this the desired behavior in the stock Unbound recursive DNS server?

I would say yes, it is very much desired.

Rationale:
If any future protocol extension makes use of new RR type in additional section and these are silently ignored then we have no way of detecting if the new extension is supported or not.

In other words FORMERR is the only future-proof thing to do.

Petr Špaček @ CZ.NIC

6

If this is indeed the rationale then it would suggest the additional record check should be locked down further to pass only the OPT record, and not all record types, as the sole record allowed in the additional section of a query. And FORMERR everything else.

Thanks again to everyone for their replies. I am not sure what we are going to do yet but I am sure it will be interesting.

7

I don't think you can design a DNS protocol extension on the assumption
that servers will reject extra records in a query! Many servers won't!
The extension would have to say that the server must indicate that it
knows what is going on by putting an extension response record in the
answer (like TKEY, TSIG, EDNS do).

There's a downside to eagerly rejecting the entire query if it contains
anything unexpected: a client probing for a new feature will have to retry
with a simpler request, which is slower and more complicated than getting
a useful response that omits some of the parts that the client wanted. If
you have multiple extensions you can end up with a combinatorial explosion
of retry attempts :frowning:

But that's basically an argument for using a well-defined extension
framework, i.e. EDNS, that is designed so that extensions can coexist.
There's also the perennial discussion about whether it's best to design
protocol extensions as must-understand or must-ignore: for the basic DNS
it's unspecified; for EDNS and DSO it's must-ignore; for TSIG it's
must-understand.

Tony.