[dns-operations] Non-EDNS FORMERR with qdcount==0?
muks at mukund.org
Mon Nov 18 10:24:36 UTC 2019
On Mon, Nov 18, 2019 at 04:06:57AM -0500, Viktor Dukhovni wrote:
> EDNS(0) queries to the (protocol-violating w.r.t. to unexpected QTYPES)
> nameservers for mail.protection.outlook.com, which don't support EDNS(0),
> elicit a response which fails to include a copy of the original question
> (see below). Is this valid?
> My response validation logic checks not only the source IP and transction id,
> but also looks for a matching question, and discards the response otherwise, so
> I don't see the FORMERR, and retry without EDNS(0) when the server leaves out
> the question.
> MUST servers reflect the question (on error?) or can they leave it
It would depend on how much of the question was syntactically parsable.
E.g., when Loop tries to parse a client query message, it parses it in
multiple passes. In the first pass, it tries to see if the UDP
datagram/TCP "message" has enough octets for a message header. If it
doesn't, then it drops the message without any response. If it could
parse the header, it tries to parse the rest of the message. If it could
not even parse the question section in the rest of the message, it would
return a reply message with rcode=FORMERR without a question section in
> Is FORMERR special in this regard (not being an answer to a question),
> but an error processing my query packet?
Maybe the outlook.com implementation thinks this question is
syntactically incorrect, and so it can't use it in the reply.
> FWIW, "unbound-host" handles the "empty" FORMERR response, and retries the
> query without EDNS. Is unbound-host doing what's expected, or employing
> a work-around for known breakage?
Loop's resolver does the same too, and appears to be a workaround (the
code is from 2000 by Bob Halley written for BIND, and it describes the
same). If EDNS is not used in the query and this happens, it abandons
the query completely without trying any other nameservers because it
expects all of them would have trouble with some aspect of this query.
More information about the dns-operations