Can't resolve many hosts

Unbound
1

Hi,

I've been following some tutorials and have come to the unbound.conf
configuration that is shown below.

Many sites can't be accessed, for example:

# dig https://nlnetlabs.nl

; <<>> DiG 9.10.5-P1 <<>> https://nlnetlabs.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48218
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;https://nlnetlabs.nl. IN A

;; AUTHORITY SECTION:
nl. 600 IN SOA ns1.dns.nl. hostmaster.domain-registry.nl. 2019102634 3600 600 2419200 600

;; Query time: 281 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Oct 26 16:48:00 WEST 2019
;; MSG SIZE rcvd: 120

The forward-addr are all of type:
        forward-addr: 208.67.220.220@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?

Luis

==== 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
        username: "_unbound"
        logfile: "/log/unbound.log"
        use-syslog: no
        log-time-ascii: yes
        log-queries: yes
        log-replies: yes
        root-hints: "/usr/pkg/etc/unbound/root.hints"
        hide-identity: yes
        hide-version: yes
        use-caps-for-id: yes
        private-domain: "home"
        private-domain: "lan"
        auto-trust-anchor-file: "/usr/pkg/etc/unbound/root.key"
        domain-insecure: "home"
        domain-insecure: "lan"
        unblock-lan-zones: yes
        insecure-lan-zones: yes
        local-zone: "home.lan." static
        local-data: "leao.home.lan. IN A 192.168.1.30"
        local-data: "netpi.home.lan. IN A 192.168.1.253"
        local-data-ptr: "192.168.1.30 leao.home.lan"
        local-data-ptr: "192.168.1.253 netpi.home.lan"
python:
remote-control:
        control-enable: yes
forward-zone:
        name: "."
        forward-addr: 208.67.222.220@53#resolver3.opendns.com.
        forward-addr: 91.239.100.100@53#anycast.censurfridns.dk.
        forward-addr: 208.67.222.222@53#resolver1.opendns.com.
        forward-addr: 208.67.220.220@53#resolver2.opendns.com.

2

Look up domain names, not URLs.

Joe

3

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@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@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@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@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.