Can't resolve many hosts

[Stuart Henderson]

On 2019-10-26, Luis P. Mendes via Unbound-users <unbound-users at nlnetlabs.nl> wrote:
> Hi,
>
> I've been following some tutorials and have come to the unbound.conf
> configuration that is shown below.

You have all sorts of confusion here.


> Many sites can't be accessed, for example:
>
> # dig https://nlnetlabs.nl

Covered by previous reply.


> The forward-addr are all of type:
>         forward-addr: 208.67.220.220 at 53#resolver2.opendns.com.
> I've read that this ways it enable DNSSEC validity.
>
> Should I use one line without the '@53#resolver2.opendns.com.' part?

ok.... the IP at port#hostname syntax is used for checking certificate
names with a DNS-over-TLS upstream and is nothing to do with dnssec.
For this you would need e.g.

        forward-addr: 9.9.9.9 at 853#dns.quad9.net
        forward-tls-upstream: yes

This would use a TLS channel between you and the forwarder but doesn't
enable any dnssec checking your side. (Some upstream resolvers will
do their own dnssec checking, others won't, according to their policy).

The hostname part of this is unused unless you are using a TLS channel
(i.e. "forward-addr: XXX at 53#somehost.net" is pointless).

For dnssec validation you would use something like

        module-config: "validator iterator"

and it's also often helpful to bump up logging with

        val-log-level: 2                                   

Also note that some public resolvers you might use as an upstream
will *block* downstream dnssec validation by stripping certain records.
A notable example of this is OpenDNS.

>====  unbound.conf
> server:
>         include: "/usr/pkg/etc/unbound/ads.conf"
>         verbosity: 1
>         interface: 0.0.0.0
>         access-control: 0.0.0.0/0 allow

..and finally, please don't run a resolver that is open to the world
unless it's properly monitored/controlled and you know what you're doing.
Just list your own network/s in access-control and deny the rest for now.