[Unbound-users] Could not generate request: out of memory

[Gareth Hopkins]

Hi There, 

Any ideas ? 

Cheers, 

Gareth 

On 12 Jul 2012, at 9:29 PM, Gareth Hopkins wrote:

> Hi All, 
> 
> I'm hoping someone can assist here. 
> 
> We have an unbound caching instance (1.4.16) which experienced an issue earlier today. Connectivity between it and the internet went down (telco cable break), and just afterwards we started getting these error messages
> 
> Jul 12 08:37:27 unbound[814:0] error: Could not generate request: out of memory
> Jul 12 08:37:27 unbound[814:0] error: mem error generating DS request
> Jul 12 08:37:29 unbound[814:0] error: Could not generate request: out of memory
> Jul 12 08:37:29 unbound[814:0] error: mem error generating DS request
> Jul 12 08:37:34 unbound[814:0] error: Could not generate request: out of memory
> Jul 12 08:37:34 unbound[814:0] error: mem error generating DS request
> Jul 12 08:37:36 unbound[814:0] error: Could not generate request: out of memory
> Jul 12 08:37:36 unbound[814:0] error: mem error generating DS request
> 
> We were unable to get any answers from the cache for records that were definitely cached (google.com as an example) along with records which we have stub zones for (the stub servers were definitely visible during this outage). When internet connectivity came back, everything returned back to normal. 
> 
> So the box was unable to see the root name servers during this time. Is this expected behavior and if so, is there anyway to keep it answering for queries already cached and available via stub zones ? Something perhaps happened with DNSSEC and not being able to refresh the trust anchor ?
> 
> Nothing fancy in the configs 
> 
> server:
> 
>        num-threads: 1 
>        outgoing-range: 4096
>        num-queries-per-thread: 2048
> 
>        rrset-cache-size: 2048m
>        msg-cache-size: 1024m
>        verbosity: 1
>        statistics-interval: 0
>        extended-statistics: yes
>        statistics-cumulative: no 
>        interface: 127.0.0.1
>        interface: *external_interface*
>        port: 53
>        access-control: 0.0.0.0/0 allow_snoop
>        access-control: 127.0.0.1 allow_snoop
>        chroot: ""
>        username: "unbound"
>        directory: "/usr/local/etc/unbound"
>        logfile: "/var/log/unbound/unbound.log"
>        log-time-ascii: yes
>        pidfile: "/var/run/unbound.pid"
>        root-hints: "/usr/local/etc/unbound/root.servers"
>        hide-identity: yes
>        hide-version: yes
>        harden-glue: yes
>        module-config: "validator iterator"
>        auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
> 
>        local-zone: "localhost." static
>        local-data: "localhost. 10800 IN A 127.0.0.1"
> 
>        local-zone: "127.in-addr.arpa." static
>        local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."
> 
>        local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." static
>        local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN PTR localhost."
> 
> # Remote control config section.
> remote-control:
>        # Enable remote control with unbound-control.
>        control-enable: yes
> 
>        # what interfaces are listened to for remote control.
>        control-interface: 127.0.0.1
> 
> stub-zone:
>        name: "internal.zone"
>        stub-addr: *internal stub address*
>        stub-prime: no
> 
> # unbound-control status
> version: 1.4.16
> verbosity: 1
> threads: 1
> modules: 2 [ validator iterator ]
> uptime: 1358672 seconds
> unbound (pid 814) is running…
> 
> Regards, 
> Gareth 
>