Unbound rejects queries with unknown data in additional section

Unbound
1

Hello.

I found a difference in behaviour between Unbound and BIND. Could you
please explain if this is intentional?

The difference happens if a query contains something except the query
section and the OPT record. Namely, a non-standard record in the
additional section. To reproduce the problem, you can run this command
in bash:

echo '4VEBAAABAAAAAAABA3d3dwZkYWRhZGECcnUAAAEAAQD/7QABAAAAAAAEIYWXrg=='

base64 -d > /dev/udp/127.0.0.1/53

and observe the FORMERR in wireshark or in the log if 127.0.0.1 runs
unbound-1.4.17. This comes from the parse_edns_from_pkt() function.

BIND just ignores the unknown record and replies normally.

2

Hi Alexander,

Hello.

I found a difference in behaviour between Unbound and BIND. Could
you please explain if this is intentional?

Yes this was intentional. It is copied from NSD. It rejects a query
that has unknown components, because the server does not support this
sort of query. FORMERR, because this rcode means there was something
wrong with the query.

The difference happens if a query contains something except the
query section and the OPT record. Namely, a non-standard record in
the additional section. To reproduce the problem, you can run this
command in bash:

echo
'4VEBAAABAAAAAAABA3d3dwZkYWRhZGECcnUAAAEAAQD/7QABAAAAAAAEIYWXrg=='
> base64 -d > /dev/udp/127.0.0.1/53

and observe the FORMERR in wireshark or in the log if 127.0.0.1
runs unbound-1.4.17. This comes from the parse_edns_from_pkt()
function.

BIND just ignores the unknown record and replies normally.

Is there some reason you want this?

Best regards,
   Wouter

3

I found a difference in behaviour between Unbound and BIND. Could
you please explain if this is intentional?

Yes this was intentional. It is copied from NSD. It rejects a query
that has unknown components, because the server does not support this
sort of query. FORMERR, because this rcode means there was something
wrong with the query.

OK, I see.

Is there some reason you want this?

My company develops parental control software. One of its functions is
to redirect all DNS queries originating from the user's computer to
our DNS servers, adding a record to the additional section for user
tracking purposes.

Now imagine what happens if a user with our software connects e.g. to
a network where an administrator redirects all DNS queries to his own
nameservers running unbound (and there are valid legal reasons why
this redirection is necessary in a number of cases). Now all users of
our software get FORMERRs. Well, the software fails closed, but some
would prefer it to fail open.

And here is why I have chosen the additional section as the place for
the user-tracking record: IETF did the same >10 years ago when the OPT
record was standardized. They trusted the implementors of DNS servers
to ignore stuff in the additional section that they don't understand
(see http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS). And
now unbound wastes this trust.

So in fact that's a general case of the "be liberal in what you
accept" rule. Yes, my software also has a bug that it does not retry
without that user-tracking additional record on a FORMERR.

4

Hi Alexander,

I found a difference in behaviour between Unbound and BIND.
Could you please explain if this is intentional?

Yes this was intentional. It is copied from NSD. It rejects a
query that has unknown components, because the server does not
support this sort of query. FORMERR, because this rcode means
there was something wrong with the query.

OK, I see.

Is there some reason you want this?

My company develops parental control software. One of its functions
is to redirect all DNS queries originating from the user's computer
to our DNS servers, adding a record to the additional section for
user tracking purposes.

This is not going to work, even if I fix unbound to be more lenient.
It is not going to be compatible with other software, in general.

Now imagine what happens if a user with our software connects e.g.
to a network where an administrator redirects all DNS queries to
his own nameservers running unbound (and there are valid legal
reasons why this redirection is necessary in a number of cases).
Now all users of our software get FORMERRs. Well, the software
fails closed, but some would prefer it to fail open.

You send malformed queries, it is normal to get error responses. That
said, thank you for reporting that you need more lenience.

And here is why I have chosen the additional section as the place
for the user-tracking record: IETF did the same >10 years ago when
the OPT record was standardized. They trusted the implementors of
DNS servers to ignore stuff in the additional section that they
don't understand (see
http://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS). And now
unbound wastes this trust.

Your reference to wikipedia does not say that DNS servers ignore stuff
in the additional section, and that is why EDNS must be backwards
compatible (does not reply with EDNS OPT unless used in the query).
EDNS is defined in RFC 2671. This RFC says that it is accepted
behaviour to signal non-support for a query with OPT with a FORMERR
response and that this behaviour is supposed to be handled by
requestors. I was not around in the IETF at the time of the EDNS OPT
standardization, but they certainly did not count on servers ignoring
the OPT record.

The upcoming update of EDNS does not improve here, servers are
expected to behave even worse in the face of the additional OPT
record. But, it does specify the future compatibility more (I believe).

So in fact that's a general case of the "be liberal in what you
accept" rule. Yes, my software also has a bug that it does not
retry without that user-tracking additional record on a FORMERR.

But you are correct that lenience is very important. We strive for
that. But I am unsure if my fix of unbound would help you, or if it
is a good idea to do so. If that would help future compatibility to
ignore additional stuff. Or if FORMERR is a better response to
indicate the query is malformed with additional stuff.

Best regards,
   Wouter

5

Hi Alexander,

This is not going to work, even if I fix unbound to be more lenient.
It is not going to be compatible with other software, in general.

Well, just for avoiding misunderstandings - the queries with the
user-tracking record are in fact not supposed to hit unbound. They are
only supposed to hit our proprietary recursive DNS server. But in fact
they do hit unbound if an ISP redirects all DNS traffic to his unbound
servers.

Your reference to wikipedia does not say that DNS servers ignore stuff
in the additional section, and that is why EDNS must be backwards
compatible (does not reply with EDNS OPT unless used in the query).

Quote from the Mechanism section: "The mechanism is backward
compatible, because older DNS responders ignore any RR of the unknown
OPT type in a request".

EDNS is defined in RFC 2671. This RFC says that it is accepted
behaviour to signal non-support for a query with OPT with a FORMERR
response and that this behaviour is supposed to be handled by
requestors. I was not around in the IETF at the time of the EDNS OPT
standardization, but they certainly did not count on servers ignoring
the OPT record.

Thanks for correcting me.

6

Hi Alexander,

Hi Alexander,

This is not going to work, even if I fix unbound to be more
lenient. It is not going to be compatible with other software, in
general.

Well, just for avoiding misunderstandings - the queries with the
user-tracking record are in fact not supposed to hit unbound. They
are only supposed to hit our proprietary recursive DNS server. But
in fact they do hit unbound if an ISP redirects all DNS traffic to
his unbound servers.

Yes your own server can do what you want it to do. I would like to
note that the redirect is also likely to be a problem, a lot of stuff
breaks in hotels (the likely redirect case; for an ISP that is
strange, perhaps run probes there, such as netalyzer). Fix the ISP
could be a very desirable solution to your problems, but often not
possible.

Your reference to wikipedia does not say that DNS servers ignore
stuff in the additional section, and that is why EDNS must be
backwards compatible (does not reply with EDNS OPT unless used in
the query).

Quote from the Mechanism section: "The mechanism is backward
compatible, because older DNS responders ignore any RR of the
unknown OPT type in a request".

Yes, I was reading that as you replied to me. The wikipedia page is
wrong. You have been misled; the additional is not ignored in queries.

In fact, the RFC (that is referenced) mandates that you must be able
to handle older boxes (and middleboxes) that send error replies, or
otherwise mistreat the query.

EDNS is defined in RFC 2671. This RFC says that it is accepted
behaviour to signal non-support for a query with OPT with a
FORMERR response and that this behaviour is supposed to be
handled by requestors. I was not around in the IETF at the time
of the EDNS OPT standardization, but they certainly did not count
on servers ignoring the OPT record.

Thanks for correcting me.

Best regards,
   Wouter