unbound-host(1) incorrectly returns NXDOMAIN

While debugging an issue I have with unbound(8) on OpenBSD I found a
likely unrelated issue with unbound-host(1), which is most likely
related to libunbound(3). When behind a router that redirects all DNS
queries (behind free WiFi portal from the Dutch railways while
commuting) unbound-host(1) is seemingly unable to lookup domains and
always responds with NXDOMAIN.

Using a different lookup tool, e.g. drill(1), I'm able to retrieve the
expected result.

I'm not sure if this is a case of PEBKAC and/or if I forgot to toggle an
option somewhere, but I would expect that unbound-host(1) gives me the
same answer as an alternative DNS lookup tool, e.g. drill(1). Am I wrong
to assume this? If not, any idea what is causing this behaviour?

$ cat /etc/resolv.conf
# Generated by iwn0 dhclient
search wifi.ns.nl
nameserver 10.87.0.1
lookup file bind

$ unbound-host -r -ddv nlnetlabs.nl
[1548308933] libunbound[27251:0] debug: switching log to stderr
[1548308933] libunbound[27251:0] debug: module config: "validator iterator"
[1548308933] libunbound[27251:0] notice: init module 0: validator
[1548308933] libunbound[27251:0] notice: init module 1: iterator
[1548308933] libunbound[27251:0] debug: target fetch policy for level 0 is 0
[1548308933] libunbound[27251:0] debug: target fetch policy for level 1 is 0
[1548308933] libunbound[27251:0] debug: target fetch policy for level 2 is 0
[1548308933] libunbound[27251:0] debug: target fetch policy for level 3 is 0
[1548308933] libunbound[27251:0] debug: target fetch policy for level 4 is 0
[1548308933] libunbound[27251:0] debug: Forward zone server list:
[1548308933] libunbound[27251:0] info: DelegationPoint<.>: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS
[1548308933] libunbound[27251:0] debug: validator[module 0] operate: extstate:module_state_initial event:module_event_new
[1548308933] libunbound[27251:0] info: validator operate: query nlnetlabs.nl. A IN
[1548308933] libunbound[27251:0] debug: iterator[module 1] operate: extstate:module_state_initial event:module_event_pass
[1548308933] libunbound[27251:0] info: resolving nlnetlabs.nl. A IN
[1548308933] libunbound[27251:0] info: processQueryTargets: nlnetlabs.nl. A IN
[1548308933] libunbound[27251:0] info: sending query: nlnetlabs.nl. A IN
[1548308933] libunbound[27251:0] debug: sending to target: <.> 10.87.0.1#53
[1548308933] libunbound[27251:0] debug: iterator[module 1] operate: extstate:module_wait_reply event:module_event_reply
[1548308933] libunbound[27251:0] info: iterator operate: query nlnetlabs.nl. A IN
[1548308933] libunbound[27251:0] info: response for nlnetlabs.nl. A IN
[1548308933] libunbound[27251:0] info: reply from <.> 10.87.0.1#53
[1548308933] libunbound[27251:0] info: query response was NXDOMAIN ANSWER
[1548308933] libunbound[27251:0] info: finishing processing for nlnetlabs.nl. A IN
[1548308933] libunbound[27251:0] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone
[1548308933] libunbound[27251:0] info: validator operate: query nlnetlabs.nl. A IN
Host nlnetlabs.nl not found: 3(NXDOMAIN). (insecure)

$ drill -d @10.87.0.1 nlnetlabs.nl
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 7150
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; nlnetlabs.nl. IN A

;; ANSWER SECTION:
nlnetlabs.nl. 9759 IN A 185.49.140.10

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 30 msec
;; SERVER: 10.87.0.1
;; WHEN: Thu Jan 24 06:49:39 2019

Hi Björn,

The query that unbound generates has the DO flag turned on and includes
EDNS. And that is not the default for the query from drill. You can
enable that (-D for drill, or +dnssec for dig). Perhaps the proxy acts
different for EDNS or when the DO flag is set (eg. switches to a
different upstream, that supports DNSSEC). Then something could be
wrong for that different upstream server that you select with the
different query options.

Additionally, the CD flag, (+cdflag) can also be turned on, and that
could perhaps be treated different. But I think this is less likely.

The protocol, just to make sure, should send the same answer to both
queries, (but with DNSSEC records to Unbound, then).

Best regards, Wouter

Ah, yes, this explains the difference in behaviour. Thank you.

In the mean time it seems that my issue is related to the 'proxy'
responding with NXDOMAIN when EDNS is included. Of course, this has
nothing to with unbound.