How to make unbound work without forward zone? about pi-hole-for-android HOT 3 CLOSED

server:
        access-control: 127.0.0.0/8 allow
        cache-max-ttl: 14400
        cache-min-ttl: 600
        do-tcp: yes
        hide-identity: yes
        hide-version: yes
        interface: 127.0.0.1
        minimal-responses: yes
        prefetch: yes
        qname-minimisation: yes
        rrset-roundrobin: yes
        ssl-upstream: yes
        use-caps-for-id: yes
        verbosity: 1
        port: 5335

#forward-zone:
#        name: "."
#        forward-addr: 9.9.9.9@853 # quad9.net primary
#        forward-addr: 1.1.1.1@853 # cloudflare primary
#        forward-addr: 149.112.112.112@853 # quad9.net secondary
#        forward-addr: 1.0.0.1@853 # cloudflare secondary

server:
        access-control: 127.0.0.0/8 allow
#        cache-max-ttl: 14400
#        cache-min-ttl: 600
        do-tcp: yes
        do-ip4: yes
        do-udp: yes
        hide-identity: yes
        hide-version: yes
        interface: 127.0.0.1
#        minimal-responses: yes
        prefetch: yes
#        qname-minimisation: yes
#        rrset-roundrobin: yes
#        ssl-upstream: yes
#        use-caps-for-id: yes
        verbosity: 1
        port: 5335
    # May be set to yes if you have IPv6 connectivity
        do-ip6: no
    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
        prefer-ip6: no
    # Trust glue only if it is within the server's authority
        harden-glue: yes
    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
        harden-dnssec-stripped: yes
    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
        use-caps-for-id: no
    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
        edns-buffer-size: 1232
        so-rcvbuf: 1m