[Unbound-users] Unbound rejects queries with unknown data in additional section

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Alexander,

On 01/11/2013 10:31 AM, Alexander E. Patrakov wrote:
> 2013/1/11 W.C.A. Wijngaards <wouter at nlnetlabs.nl>:
>> On 01/11/2013 08:37 AM, Alexander E. Patrakov wrote:
>>> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ7+aBAAoJEJ9vHC1+BF+NhbUP/2ddJijaOdLU0I1ksr6i/RD3
n+DFH43wGQAFKzoqBPC97bO4SkqTawa6xcp9yYvkU1SkCkhtBWdTxNUw2w7Lq0k+
M2oVr/HSSlAZxVXRdY0oVvfTMEtoRQqRS6VSLvtJNHu+TCf0HqTVGprMlPurhSWt
ZOfRyYMQWYhBT3mpj+rAUwD6TKn1kVEprPCMpxDPzr3H7plMeN7RoBZUNbH7JZtP
Kt8r7S9/7UNi8w9aX7pQ+8e8d2GJLAKANT5h0+kNb7tfzTZwmTSCjxz5c7BD9BAR
mTlkmT+SRJa9THGQwT+kGMyTdrjhv4BQxrb1s/LbukeVG3J1f1g0Wb1oapzv/Knf
5GvfMuK60IhpOC279lzCINygZ72nF6L/EMHMOrCqin4p6/mYn1pWvaIp5F1zOvfa
Ls8+aVL/UF1PXfbp8Wrxhym13JDu5ficrKowhrQhVYVItUlvH1VMd0r1fnWLfo0s
hTngnuLTx3MyamS1bHJfGlAQj9XNlJu3hey+rE7LrutOLpKmqBoEZVR1GkgS4Zki
7K9pG/5p7QcolV87ZakqQw/u560RqafX5gPbzpy2+Jbxy758BOE0bqWAi6K90wIK
nJqotxA9/s2YzEUwL2x6COyHoA0mam+FEBqdiAAXBcKjdMC1bIKbvNHeL1k01b6I
XwWVTVGCm8hU0k4fBQyL
=bAus
-----END PGP SIGNATURE-----