[On Hold]UnboundDNS Stopped running - No errors ?

[sedace]

Hi,

Running 18.1.12 on generic hardware, recently (sat 7/21) updated from 18.1.9 that was running fine for a month or so.   Well, Just a few mins ago users (ie, my family, this is a home / small business deployment) noticed that websites were not responding, quick diagnostic showed I wasn't getting DNS resolution.  I logged into the web interface and went to Services \ Unbound DNS \ General and the service start button on the top was Red.  I clicked the "play" button and it started and DNS was working fine.  I haven't logged into the router and am the only one with access so it wasn't stopped manually. 

I then went into the system \ log files \ general and didn't see any error messages but the last one pertaining to DNS was Jul 26 17:29:21    opnsense: /usr/local/etc/rc.dyndns: Dynamic DNS: (Success) IP Address Updated Successfully!  which would be a different service so I believe it would be unrelated. 

Is there any other log files, perhaps from the shell in var \ log that I can review that might show why the DNS service stopped functioning?  I'm not super versed in Unix so might be a simple thing I'm missing.   

[bringha]

Hi there,

login into your sense with ssh and get a shell

cd into /var/log

check the resolver.log file with

clog resolver.log

Br br

[sedace]

Thanks, I'll check into that if it happens again, it doesn't go back far enough at the moment to see what happened then. 

[funar]

I've been having a similar issue with Unbound as well, but I think I have narrowed it down to DNSSEC support. Using Log Level 2, I was able to observe the following snippet of logs:

Version 18.7, but this issue was also present on 18.1.[10-13] (possibly earlier)

Aug  1 12:35:18 gateway unbound: [71731:7] info: response for ghostery-collector.ghostery.com. AAAA IN
Aug  1 12:35:18 gateway unbound: [71731:7] info: reply from <.> 2620:fe::9#853
Aug  1 12:35:18 gateway unbound: [71731:7] info: query response was nodata ANSWER
Aug  1 12:35:18 gateway unbound: [71731:7] info: resolving ghostery.com. DS IN
Aug  1 12:35:19 gateway unbound: [71731:7] info: DS response was error, thus bogus
Aug  1 12:35:19 gateway unbound: [71731:7] info: resolving ghostery.com. DS IN
Aug  1 12:35:19 gateway unbound: [71731:7] info: DS response was error, thus bogus
Aug  1 12:35:19 gateway unbound: [71731:7] info: resolving ghostery.com. DS IN
Aug  1 12:35:19 gateway unbound: [71731:7] info: DS response was error, thus bogus
Aug  1 12:35:19 gateway unbound: [71731:7] info: resolving ghostery.com. DS IN
Aug  1 12:35:19 gateway unbound: [71731:7] info: DS response was error, thus bogus
Aug  1 12:35:19 gateway unbound: [71731:7] info: resolving ghostery.com. DS IN
Aug  1 12:35:19 gateway unbound: [71731:7] info: DS response was error, thus bogus
Aug  1 12:35:19 gateway unbound: [71731:7] info: resolving ghostery.com. DS IN
Aug  1 12:35:19 gateway unbound: [71731:7] info: DS response was error, thus bogus
Aug  1 12:35:19 gateway unbound: [71731:7] info: Could not establish a chain of trust to keys for ghostery.com. DNSKEY IN
Aug  1 12:35:32 gateway unbound: [71731:b] info: resolving tmi.twitch.tv. A IN
Aug  1 12:35:32 gateway unbound: [71731:4] info: resolving tmi.twitch.tv. A IN
Aug  1 12:35:36 gateway unbound: [71731:4] info: resolving api-global.netflix.com. AAAA IN
Aug  1 12:35:36 gateway unbound: [71731:0] info: resolving secure.netflix.com. AAAA IN
Aug  1 12:35:36 gateway unbound: [71731:c] info: resolving customerevents.netflix.com. AAAA IN
Aug  1 12:35:36 gateway unbound: [71731:c] info: resolving customerevents.netflix.com. AAAA IN
Aug  1 12:35:36 gateway unbound: [71731:5] info: resolving cdn-0.nflximg.com. AAAA IN
Aug  1 12:35:36 gateway unbound: [71731:c] info: resolving customerevents.netflix.com. AAAA IN
Aug  1 12:35:36 gateway unbound: [71731:4] info: resolving secure.netflix.com. A IN

Prior to the "Could not establish a chain..." log entry, DNS resolution is working fine. "ghostery.com" just happened to be the domain that triggered it this time.  I've also witnessed it with others, including google.com, and microsoft.com.  Once the "chain of trust" error occurs, Unbound will log that it's resolving other requests, but it never actually performs the query, nor does it respond to the client's request. It requires a restart of the Unbound service to restore functionality -  at least, until it happens again.

The temporary, but undesirable solution for now is to disable DNSSEC in Unbound. Unbound doesn't get choked up with DNSSEC disabled.

A little more about my config -
I'm forwarding all my queries to Quad9 via TLS on IPv4 and IPv6.  Additionally, I run a local BIND9 server for local resolution that us configured as a Stub in Unbound.

[funar]

Scratch that... Disabling DNSSEC does not make the issue go away.  Instead, it just delays it by a few days at a time.