GitLab

Per customer, it looks like the corresponding RFC 7873 (cookie) handling code is broken for this case.

The same code seems to exist in both v9_11_sub and master branches.

As of 9.11.3-S1, 'named' returns a noerror response to a query without
an empty question section (and no EDNS for that matter).  Previously
it returned FORMERR in this case.  Is that intentional?

This is because of the following code in client.c:client_request():
               
                if ((client->attributes & NS_CLIENTATTR_WANTCOOKIE) != 0 ||
                    (client->message->opcode == dns_opcode_query &&
                     client->message->counts[DNS_SECTION_QUESTION] == 0U)) {
                        result = dns_message_reply(client->message, ISC_TRUE);
                        if (result != ISC_R_SUCCESS) {
                                ns_client_error(client, result);
                                return;
                        }                                                                                                                                      
                        if (notimp)
                                client->message->rcode = dns_rcode_notimp;
                        ns_client_send(client);
                        return;
                }                                                                                                                                              

which in the public repo version was introduced at commit ce67023ae:

4152.   [func]          Implement DNS COOKIE option.  This replaces the
                        experimental SIT option of BIND 9.10.  [...]

RFC7873 certainly talks about a special case of an empty query, but it
adds a condition of the existence of the cookie option:

   For servers with DNS Cookies enabled, the QUERY opcode behavior is
   extended to support queries with an empty Question Section (a QDCOUNT
   of zero (0)), provided that an OPT record is present with a COOKIE
   option.

So the above code doesn't seem to be fully compliant with the RFC.  Is
there other reason for this behavior, or perhaps the first '||'
should have been '&&'?

See: https://support.isc.org/Ticket/Display.html?id=12856 for the details.