Maintained by: NLnet Labs

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

W.C.A. Wijngaards
Fri Jan 11 11:57:55 CET 2013


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

Hi Alexander,

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

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

iQIcBAEBAgAGBQJQ7/AzAAoJEJ9vHC1+BF+NW6wQAJddaCHZYdiNbyIGWQpm3N5e
uToy3K8nirTobWlWvnYkWdBpvV6XUP6YDXdOH7MERIaPb1AiuDzOaFy1fAzXYiE5
SMk0SYlr5k/FhhhBsmz0krT0zQ06P8wRiBvMizhoGClKkevm5ywpxpc+Lkh89YG0
T1Ku6x84vJHvzenJ4JHZZ2YpKnJ6pt6XUAJiO3dsZMyIyyh6LcfNU1tSEKNcXyF8
/r363M1zjo6RCWWviqXy+DfR3qeQAso/24ataprpyxee2JdPCCafUTpNymOl5vaX
MBr8g+SeLepWN0x8IEJowzxdREYYp89KBTVGJglRo0k7sdxl+fTPFpLr/1jJMvU+
2zJygUfGwMYpzcWqqL0hmcGU6ajWLJWYihywBl6hfjK50Garo2msHF746X0gqzQ9
TQVYnKbcXOmCp0vIQB/jcDA42koIK3cfgpoU8iYHU8Uv0nadAuJWrsBD6MSA7dRW
gBePivBtkFNmFl6Dex90I71mQSmEZI8wof2p8ZEu3F3iqN+qFWW03duaW62ldhsU
YCflgA6op2aqPfJ4kYxzmiT5Vjm2pXotSV5j6BYo8CONQEQLfutmdBzuwGwiwG1o
RGzHby15t0Z/R1/MXcAC2drU7B7WjE37sX37ycczSYj6giEqhdAoiMU46duEUOV0
fl2x9E4sUlPNkcIe/6BS
=+8bM
-----END PGP SIGNATURE-----