Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unbound returns additional records on NODATA response #48

Closed
Daggolin opened this issue Jul 11, 2019 · 5 comments

Comments

@Daggolin
Copy link

commented Jul 11, 2019

When Unbound gets a response from an authoritative server without answer section
(NODATA), but with additional section filled (but no referral NS records), it
returns the additional section records to the client.

This can be misused to tunnel data through unsuspicious queries (like A/AAAA) and
can be a potential security risk.

Other DNS resolvers (BIND 9, PowerDNS-Recursor, Knot-Resolver) do not forward
the additional section to the client.

@wcawijngaards

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

Unbound removes some of those records, eg. unrelated A/AAAA. This happens in the scrubber.
You could enable minimal-responses, does that remove the problem for you?
So A/AAAA should be removed by the scrubber? Is that not happening? Is it another type that is deemed 'unknown' and we just pass it on, because it looks harmless?

@wcawijngaards wcawijngaards self-assigned this Jul 11, 2019

@Daggolin

This comment has been minimized.

Copy link
Author

commented Jul 11, 2019

Adding "minimal-responses: yes" to the config didn't affect the behavior regarding additional sections in NODATA responses.

We encountered this behavior while doing research on dns-tunneling. This is a simple dig-example of what it looks like:

; <<>> DiG 9.14.3 <<>> add-test.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20284
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;add-test.example.com.   IN      A

;; ADDITIONAL SECTION:
add-test.example.com. 10 IN      TXT     "response" "abc"
add-test.example.com. 10 IN      TXT     "extra" "abc"

;; Query time: 608 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Do Jul 11 11:25:02 CEST 2019
@wcawijngaards

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

Data tunneling is not something we can really stop, eg. they query for type TXT with that. But this additional looks like something we could remove if minimal-responses is yes. Without that, it does not look like something that has to be removed.
The additional section is there to give additional data. And it looks like that additional data is related to the query somehow.

@wcawijngaards

This comment has been minimized.

Copy link
Member

commented Jul 11, 2019

An issue is that if we restrict the filter to not allow anything that does not fit with the query, in additional, protocol extension is harmed, because it cannot transmit new data in the additional sectoin any more that the resolver has not been designed for yet. So Unbound allows unknown stuff in various types of queries. The filter (scrubber we call it) removes stuff that we can tell is problematic.

@wcawijngaards

This comment has been minimized.

Copy link
Member

commented Jul 12, 2019

Fix is in the commit. It removes the additional section for negative responses, if minimal-responses is enabled. Not the authority section because those entries are needed for DNSSEC and the SOA record for TTL.

jedisct1 added a commit to jedisct1/unbound that referenced this issue Jul 24, 2019
Merge remote-tracking branch 'nlnet/master'
* nlnet/master:
  - Fix question section mismatch in local zone redirect.
  Fixup space in error message.
  - Fix NLnetLabs#49: Set no renegotiation on the SSL context to stop client   session renegotiation.
  - Fix NLnetLabs#48: Unbound returns additional records on NODATA response,   if minimal-responses is enabled, also the additional for negative   responses is removed.
  -  Fix in respip addrtree selection. Absence of addr_tree_init_parents() call    made it impossible to go up the tree when the matching netmask is too    specific.
  - Fix for possible assertion failure when answering respip CNAME from cache.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.