BIND DLZ funnies and Segfaults

[Adam Tkac]

On Wed, Oct 17, 2007 at 12:58:16PM +0200, Kristian Larsson wrote:
> Hello all!
> 
> I'm a long time BIND user though quite new with
> this DLZ deal. I've been running a BIND+DLZ+MySQL
> instance for a short time. Most things are working
> as expected except for the actual DB connection.
> It would seem that the DB connection times out
> after a "couple of hours" of inactivity. If I ask
> named questions continuosly this isn't a problem
> but if I don't for a few hours then it dies and
> all that seems to remedy the situation is a
> restart of named. I haven't had the time to
> measure how much inactivity it actually takes, but
> leaving it overnight always results in
> disconnection. 
> So I talked to a collegue who has been fiddling
> around with this for a bit. He had chosen the
> PostgreSQL path as that was what he was using. He
> did not see the disconnection problems with
> postgres although he had also setup a small test
> with MySQL and he could confirm my findings.
> I was also told that the Postgres driver would
> perform better due to a better implementation with
> threading and all. This led me to recompile my
> BIND with PostgreSQL support and try it out.
> So far, this is what I've got:
> 
> mcore1 named # ./named -c /etc/bind/named.conf -g -d 5 
> 17-Oct-2007 12:49:21.308 starting BIND 9.4.2rc1 -c /etc/bind/named.conf -g -d 5
> 17-Oct-2007 12:49:21.309 Registering DLZ postgres driver.
> 17-Oct-2007 12:49:21.309 Registering SDLZ driver 'postgres'
> 17-Oct-2007 12:49:21.309 Registering DLZ driver 'postgres'
> 17-Oct-2007 12:49:21.310 loading configuration from '/etc/bind/named.conf'
> 17-Oct-2007 12:49:21.311 set maximum stack size to -1: success
> 17-Oct-2007 12:49:21.311 set maximum data size to -1: success
> 17-Oct-2007 12:49:21.311 set maximum core size to -1: success
> 17-Oct-2007 12:49:21.311 set maximum open files to 1024: success
> 17-Oct-2007 12:49:21.311 listening on IPv4 interface lo, 127.0.0.1#53
> 17-Oct-2007 12:49:21.311 clientmgr @0x2b8716ce01c8: create
> 17-Oct-2007 12:49:21.312 clientmgr @0x2b8716ce01c8: createclients
> 17-Oct-2007 12:49:21.312 clientmgr @0x2b8716ce01c8: create new
> 17-Oct-2007 12:49:21.312 client @0x6ba360: create
> 17-Oct-2007 12:49:21.312 clientmgr @0x2b8716ce01c8: createclients
> 17-Oct-2007 12:49:21.312 clientmgr @0x2b8716ce01c8: create new
> 17-Oct-2007 12:49:21.312 client @0x6bb850: create
> 17-Oct-2007 12:49:21.312 Loading 'postgres zone' using driver postgres
> 17-Oct-2007 12:49:21.312 Loading SDLZ driver.
> 17-Oct-2007 12:49:21.312 Postgres driver running single threaded
> 17-Oct-2007 12:49:21.312 Postgres driver created database instance object.
> Segmentation fault (core dumped)
> mcore1 named # 
> 
> My named.conf is pretty straight-forward:
> ----------------------------------
> options {
> 	directory       "/var/cache/bind";
> 	listen-on       { 127.0.0.1; };
> 	recursion no;
> };
> 
> dlz "postgres zone" {
>         database "postgres 1
>         {host=localhost port=5432 dbname=dns user=bind pass=230casdasd3}
>         {select zone from dns_records where zone = '%zone%'}
>         {select ttl, type, mx_priority, case when lower(type)='txt' then '\"'
>                 || data || '\"' when lower(type)='soa' then data || ' ' || resp_person || ' '
>                 || serial || ' ' || refresh || ' ' || retry || ' ' || expire || ' ' || minimum
>                 else data end from dns_records where zone = '%zone%' and host = '%record%'}";
> };
> 
> ----------------------------------
> 
> The only difference I can see between this and 
> the machine that my collegue (successfully) is
> using is that I'm on a amd64 (Opteron 248) 
> while he is on a Intel. Could this have any
> influence ?

Maybe. Especially when one machine is 64bit and other is 32bit

> Where should I start looking or what more
> information do I need to provide for
> troubleshooting?

Looks like a bug somewhere in DLZ postgres module. Best should be fill a
bug to bind9-bugs at isc.org (if you have pure BIND) or to your OS vendor.
Core dump is usually enough information.

Adam