Maintained by: NLnet Labs

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

Gareth Hopkins
Thu Jul 12 21:29:05 CEST 2012


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