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 > _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
