Bug 715 - Can unbound NOT add field of Additional Records into DNS query?
Can unbound NOT add field of Additional Records into DNS query?
Status: ASSIGNED
Product: unbound
Classification: Unclassified
Component: server
1.4.20
x86_64 Linux
: P1 blocker
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-23 14:28 CEST by sunshine
Modified: 2016-07-25 14:34 CEST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description sunshine 2015-10-23 14:28:09 CEST
Unbound support team, 

I am from Alcatel-Lucent, and unbound is integrated into our product ISC(IP Server Controller). Application of IMS in this ISC uses unbound as a validating, recursive, and caching DNS resolver(Many thanks to your contribution).

In ISC, IMS will send DNS query (without Additional Records) to unbound, which will forward this DNS query to the external DNS server. According to our observation, unbound will always add the field of "Additional Records" into DNS query message and then forward it out to external DNS server. 

In project of VoLTE for CMCC(China Mobile Communications Corporation) , current existing DNS server from ZTE deployed years ago does not support this field of Additional Records. And the upgrade of DNS server/ZTE is planned months later. So this project is blocked by this issue. So I am writing here to ask for support as following:

1. Is there any configure we can do to make unbound not to add this Additional Records into DNS query message before forwarding it out to external DNS server?

2. If there is no such configure, would you please be kind to deliver us one enhanced version which not add this Additional Records? either binary or source code ok.

3. If possible, we can do this building with source code change. Would you please be kind to share with us where source code should be changed?

Many thanks in advance. If there is anything I can do to get the response/support at the quickest time, feel free to let me know.

Best Wishes
Sunshine Ren
Comment 1 Wouter Wijngaards 2015-10-23 14:40:21 CEST
Hi Sunshine_ren,

The additional record you mention is the EDNS record.  This record is for Extended DNS, and unbound must have it to use DNSSEC security.  Unbound does not support operations with EDNS disabled, because we want to encourage the deployment of the security.  But unbound has a backwards compatibility mode.

Unbound falls back to non-EDNS, where, if the upstream server replies with FORMERR or NOTIMPL to the query with the EDNS record in the Additional Section, unbound will then query again without the additional section.  This should be automatic.  But it does not happen in your case (or you would not have written this report?).

So, the server it is sending to is causing the problem, I think.  It should choose to reply NOTIMPL at the EDNS in the Additional section.  Or it could implement EDNS (of course).

Best regards, Wouter
Comment 2 sunshine 2015-10-23 14:48:47 CEST
Wouter:

Thanks very much for your quick response.

will the Additional Records be added into DNS query message in the backwards compatibility mode? How to configure unbound to make it work in this mode?

Thanks
Sunshine
Comment 3 Wouter Wijngaards 2015-10-23 14:55:00 CEST
Hi Sunshine,

There is no configuration necessary to enable the compatibility.  Unbound detects based on the answers from the server if EDNS is supported.  If it is not supported Unbound retries the query by sending it again without the Additional section in the second query.  That is then a query without an additional section, and the older software on the other server can then send a reply.

Best regards, Wouter
Comment 4 sunshine 2015-10-23 14:58:23 CEST
would be please be kind to share with me where the logic adding the additional section is in the source code?
Comment 5 Wouter Wijngaards 2015-10-23 15:04:16 CEST
services/outside_network.c: serviced_encode() line 1375

I would recommend not turning it off; the 'right' fix is likely to fix the other server or find a 'root-cause' for the problem.  But I cannot really say without knowing what is happening.  Why is the EDNS record a problem?  Why does Unbound not fall back to compatibility mode; if it should do that?  What does unbound say when you run it with verbosity 5, in logs?

Best regards, Wouter
Comment 6 sunshine 2015-10-23 15:18:25 CEST
Wouter, 

Appreciated if you can share with us how to enable the compatibility.

More background to share with you that ZTE server will reject this DNS including AdditionalRecords directly, so there is no another chance to send another query.

Sunshine
Comment 7 Wouter Wijngaards 2015-10-23 15:32:35 CEST
Hi Sunshine,

The compatibility is always on.  It does not need to be enabled.  It detects with the method described in the EDNS RFC 6891 http://www.rfc-editor.org/info/rfc6891

This detection needs two (or more) queries to detect that EDNS is not working.

Thus, if the ZTE server only allows one query, this will not work.

I think it is strange that the server only allows you to send the query once, and does not allow a repeat without the additional section.

Best regards, Wouter