auth-zone doesn't play nicely with forward-zone

[CHTJonas]

Describe the bug When querying for a record within an auth-zone, queries should not be issued to a server listed under a forward-zone stanza.

To reproduce

forward-zone:
        name: "."
        forward-addr: 9.9.9.9

auth-zone:
        name: "bar.org.uk."
        primary: 5001:123:abcd:987::53
        fallback-enabled: no
        for-downstream: no
        for-upstream: yes
        zonefile: "/opt/unbound-1.14.0/etc/unbound/zones/bar.org.uk.zone"

Expected behavior Unbound should respond to queries for foo.bar.org.uk. from its local copy of the zone. Currently it can be observed to be contacting the server listed under the forward-zone stanza.

System:

• Unbound version: 1.14.0
• OS: Ubuntu 20.04.3 LTS
• Linux: 5.4.0-1048-raspi #53-Ubuntu SMP PREEMPT Wed Dec 8 13:06:23 UTC 2021 aarch64
• unbound -V output:

Version 1.14.0

Configure line: --prefix=/opt/unbound-1.14.0 --enable-tfo-client --enable-tfo-server
Linked libs: mini-event internal (it uses select), OpenSSL 1.1.1f  31 Mar 2020
Linked modules: dns64 respip validator iterator
TCP Fastopen feature available

Additional information I used sudo tcpdump -i eth0 src or dst 9.9.9.9 to observe forwarded query traffic.

[JiangHeng12138]

for-downstrem may be yes in auth-zone

[for-downstream:]() <yes or no>
              Default  yes.  If enabled, Unbound serves authority responses to
              downstream clients for this zone.  This option makes Unbound be-
              have,  for  the queries with names in this zone, like one of the
              authority servers for that zone.  Turn it off if  you  want  Un-
              bound to provide recursion for the zone but have a local copy of
              zone data.  If for-downstream is no  and  for-upstream  is  yes,
              then  Unbound  will DNSSEC validate the contents of the zone be-
              fore serving the zone contents to clients and  store  validation
              results in the cache.

[CHTJonas]

I can't use the for-downstream: yes option because it interferes with CNAME resolution. Put simply I have one locally-cached auth-zone that contains CNAMEs to another locally-cached auth-zone and enabling for-downstream prevents these from being resolved.

However I have managed to find a workaround for this issue with the config below (the trust-anchor bit can be ignored if your zone does not use DNSSEC):

server:
        trust-anchor: "bar.org.uk. DS 12345 13 2 blahblahblah"
        trust-anchor: "foo.net. DS 12345 13 2 blahblahblah"

stub-zone:
        name: "bar.org.uk."
        stub-addr: 5001:123:abcd:987::53

stub-zone:
        name: "foo.net."
        stub-addr: 5001:123:abcd:987::53

forward-zone:
        name: "."
        forward-addr: 9.9.9.9

auth-zone:
        name: "bar.org.uk."
        primary: 5001:123:abcd:987::53
        fallback-enabled: no
        for-downstream: no
        for-upstream: yes
        zonefile: "/opt/unbound-1.14.0/etc/unbound/zones/bar.org.uk.zone"

auth-zone:
        name: "foo.net."
        primary: 5001:123:abcd:987::53
        fallback-enabled: no
        for-downstream: no
        for-upstream: yes
        zonefile: "/opt/unbound-1.14.0/etc/unbound/zones/foo.net.zone"

Why the stub-zone stanzas are needed I'm unsure; the zonefiles configured under auth-zone stanzas already contain the information the stub-zone stanzas specify.

[actck]

Same issus with version 1.17.1, is this expected behavior?