Unbound error
-
I'm getting the following errors in my Unbound log - any ideas?
unbound: [1011:0] notice: remote address is x.x.x.x port 53
unbound: [1011:0] notice: sendto failed: Operation not permitted
-
Is your state table full?
-
How do I tell if it is full?
-
Number of ways, but easiest is to check the Dashboard and look at the 'System' widget. There is a row that is titled 'State table size' which should give you current/total states. You can also view the history of your state table by visiting Status->RRD Graphs->System tab and choose states Graph to view.
-
State table size - 149/195000
Thanks!
-
hrrm looks fine. The graphs i assume reflect similar results?
-
I don't see anything out of the ordinary, other than when Unbound is enabled, I lose DNS resolution on my client.
-
Can you PM the config file for unbound?
-
If I am using Unbound as a typical DNS forwarder in an internet gateway, should I only set the Interface to LAN?
-
Interesting, I am unable to make changes to the Unbound config via GUI. Is there a way to wipe out the config? I uninstalled and reinstalled the package, but same behavior. Maybe pfSense restart?
-
As of september 15th, there is a new unbound version out.
http://www.unbound.net/download.html
SHA1 checksum: 834ccfd1cb41a44f53b33f8338a8f9cc68febaf7
SHA256 checksum: 83c7dc2756c488ab5bfcb9b25b81236a4ec42fb3d505267fcaf005555f3a2313
Date: 15 September, 2011Features
-
Note that Unbound implements RFC6303 (since version 1.4.7).
-
tcp-upstream yes/no option (works with set_option) for tunnels.
-
The format of answers to the qtype ANY with a CNAME have changed, so that there can be proper validated DNSSEC answers for them. This is for queries with qtype ANY where the domain name has a CNAME. Now an answer is returned, where before it resulted in SERVFAIL due to validation failure. When DNSSEC validation is disabled, the contents of the response have changed: the CNAME is not followed, and the correct contents of the RRsets at the initial name are included (where previously only partial contents of the initial names could have been included but the CNAME was followed). The qtype ANY is a query for debug where the resolver is to fill in relevant data that happens to be at hand from the cache.
Bug Fixes
-
Fix validation of qtype ANY responses with CNAMEs (thanks Cathy Zhang and Luo Ce). Unbound responds with the RR types that are available at the name for qtype ANY and validates those RR types. It does not test for completeness (i.e. with NSEC or NSEC3 query), and it does not follow the CNAME or DNAME to another name (with even more data for the already large response)
-
Documented the options that work with control set_option command.
-
Fix that internally, CNAMEs with NXDOMAIN have that as rcode.
-
Fix validation of . DS query.
-
Fix wildcard expansion no-data reply under an optout NSEC3 zone is validated as insecure, reported by Jia Li (lijia cnnic.cn).
-
Fix python site-packages path to /usr/lib64.
-
fix memory and fd leak after out-of-memory condition.
-
patch from Tom Hendrikx fixes load of python modules.
-
Applied patch from Karel Slany that fixes a memory leak in the unbound python module, in string conversions.
-
Fix num-threads 0 does not segfault, reported by Simon Deziel.
-
fix autoconf 2.68 warnings
-
iana portlist updated
It fixes an out of memory bug among other things.
Since you did not run out of states, could it be a out of memory issue?
-
-
Thanks for the response. Snort maxes out resources during startup, so perhaps it is causing problems while unbound is trying to start? The problem with that theory is that I've reinstalled and restarted Unbound while there are plenty of CPU and mem resources, and still problems.
-
That is the same kind of message I get when pinging (operation not permitted) after Snort has blocked a host when the host was both not on the active whitelist and generated an alert.
Just an FYI, take the best and leave the rest, but have you checked the Snort Blocked list to verify none of the involved hosts made it in there somehow?
I figured it couldn't hurt to ask.
-
The only thing that seems to break DNS is disabling DNS Forwarder and enabling Unbound. Snort is enabled the whole time, and DNS works fine when pfSense DNS Forwarder is enabled. Just for kicks, who would I quickly search the Snort rules for an IP? Is there a snort file that I can open in the shell and just do a search there?
-
… Just for kicks, who would I quickly search the Snort rules for an IP? Is there a snort file that I can open in the shell and just do a search there?
Sorry, I don't know the path to a file that holds the block list.
I just open the Block tab in the Snort web-interface page and use the browser to find anything I am looking for.
-
You might also try looking for an error along the lines of BAD-TRAFFIC TMG Firewall Client long host entry exploit.
That message is triggered by a bad traffic rule that looks for odd traffic on port 53, which happens to be DNS.
If you have a lot of these in your alerts of blocked log, chances are that some or all DNS replies are being blocked by snort.