Maintained by: NLnet Labs

[Unbound-users] Problem to resolve domains from a certain registrar

Leo Bush
Thu Aug 25 17:33:06 CEST 2011


Hello
>> Then I changed the following two settings:
>>     do-tcp: yes
>>     edns-buffer-size: 512
>>
>> I restarted the unbound daemon. I find immediately the following 
>> messages in the log:
>> Aug 24 15:28:57 resolv5 unbound: [10817:1] error: mem error 
>> generating DNSKEY request
>> Aug 24 15:28:57 resolv5 unbound: [10817:1] error: Could not generate 
>> request: out of memory
>> Aug 24 15:28:57 resolv5 unbound: [10817:1] error: mem error 
>> generating DNSKEY request
>> Aug 24 15:28:57 resolv5 unbound: [10817:1] error: Could not generate 
>> request: out of memory
>
> This doesn't look good anyway. Are you low on memeory? What are the 
> other unbound settings look like?
>
>

Up to now, I never had these errors, only yesterday after the option 
edns-buffer-size: 512.
This is a photo of the current state.
Mem:   2055060k total,  1984176k used,    70884k free,    89028k buffers
Swap:  2064376k total,     7932k used,  2056444k free,   114800k cached

My current config file looks as follows (all other lines are commented):
server:
         verbosity: 1
         statistics-interval: 0
         statistics-cumulative: no
         extended-statistics: yes
         num-threads: 2
         interface: 0.0.0.0
         interface: 2001:7e8:f00:1::1
         interface-automatic: no
         outgoing-range: 768
         so-rcvbuf: 2m
         so-sndbuf: 2m
         msg-cache-size: 350m
         msg-cache-slabs: 2
         rrset-cache-size: 700m
         rrset-cache-slabs: 2
         infra-cache-slabs: 2
         access-control: 127.0.0.0/8 allow
         access-control: ::1 allow
         access-control: 83.199.0.0/17 allow
         ...
         chroot: ""
         username: "unbound"
         directory: "/etc/unbound"
         log-time-ascii: yes
         pidfile: "/var/run/unbound/unbound.pid"
         hide-identity: yes
         hide-version: yes
         harden-glue: yes
         harden-dnssec-stripped: yes
         harden-referral-path: yes
         use-caps-for-id: no
         unwanted-reply-threshold: 10000000
         prefetch: yes
         prefetch-key: yes
         auto-trust-anchor-file: "/etc/unbound/root.key"
         val-clean-additional: yes
         val-permissive-mode: no
         val-log-level: 2
         key-cache-size: 16m
         key-cache-slabs: 2
         neg-cache-size: 2m
remote-control:
         control-enable: yes
         server-key-file: "/etc/unbound/unbound_server.key"
         server-cert-file: "/etc/unbound/unbound_server.pem"
         control-key-file: "/etc/unbound/unbound_control.key"
         control-cert-file: "/etc/unbound/unbound_control.pem"


>
> There lately was an issue with priming the root with DNSSEC last very 
> long in some cases...
> What are the settings for your trusted keys and do you use IPv6?
>

We use IPv6.

[resolv1 ~]$ ls -l "/etc/unbound/root.key"
-rw-r--r--. 1 unbound unbound 759 Aug 25 15:40 /etc/unbound/root.key
[resolv1 ~]$ cat "/etc/unbound/root.key"
; autotrust trust anchor file
;;id: . 1
;;last_queried: 1314279650 ;;Thu Aug 25 15:40:50 2011
;;last_success: 1314279650 ;;Thu Aug 25 15:40:50 2011
;;next_probe_time: 1314322249 ;;Fri Aug 26 03:30:49 2011
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.       172800  IN      DNSKEY  257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0= 
;{id = 19036 (ksk), size = 2048b} ;;state=2 [  VALID  ] ;;count=0 
;;lastchange=1308043580 ;;Tue Jun 14 11:26:20 2011


This afternoon I tried to block traffic from my resolver to one or two 
of the three resolvers from register.be. Especially when blocking 
outgoing traffic towards ns3.register.be, unbound's behavior improved 
(approximately ~60% of success), but the problem did not disappear. I 
still got SERVFAILs.


kind regards

Leo Bush