Bind 9 and sdb

Paul Kelly pkelly at virtual.org.uk
Mon Feb 19 22:36:13 UTC 2001


further to this problem, looking in lib/dns/sdb.c at around 785 there is
the following lines:

                       if (result == ISC_R_SUCCESS) {
                                if (type != dns_rdatatype_ns)
                                        result = DNS_R_DELEGATION;
                                break;
                        }

surely this should be:

                      if (result == ISC_R_SUCCESS) {
                                if (type == dns_rdatatype_ns)
                                        result = DNS_R_DELEGATION;
                                break;
                        }

also:
                       if (result == ISC_R_SUCCESS) {
                                if (type != dns_rdatatype_dname)
                                        result = DNS_R_DNAME;
                                break;
maybe that should be:

                       if (result == ISC_R_SUCCESS) {
                                if (type == dns_rdatatype_dname)
                                        result = DNS_R_DNAME;
                                break;

???

i tried changing these two line changes and suddenly it works. am i
missing something here?

Thanks
Paul

On Mon, 19 Feb 2001, Paul Kelly wrote:

> 
> hi,
> 
> I have the same problem, i have just written a mysql sdb driver but the
> nameserver dies whenever a recursion lookup is attempted, the recursion is
> generated when a delegated name server record is looked up.. 
> 
> ie subdomain IN NS ns.anotherplace.com. 
> 
> a backtrace shows:
> 
> #0  dns_rdata_clone (src=0xdededede, target=0xff0b1b28) at rdata.c:369
> 369             REQUIRE(DNS_RDATA_VALIDFLAGS(src));
> (gdb) bt
> #0  dns_rdata_clone (src=0xdededede, target=0xff0b1b28) at rdata.c:369
> #1  0xe5fcc in isc__rdatalist_current (rdataset=0xdededede,
> rdata=0xff0b1b28) at rdatalist.c:124
> #2  0xe67e4 in dns_rdataset_current (rdataset=0x6c93360, rdata=0xff0b1b28)
> at rdataset.c:254
> #3  0xea12c in fctx_getaddresses (fctx=0x6c932a8) at resolver.c:1440
> #4  0xea8b0 in fctx_try (fctx=0x6c932a8) at resolver.c:1687
> #5  0xeb8f8 in fctx_start (task=0x0, event=0x6c932f8) at resolver.c:1960
> #6  0x19b348 in dispatch (manager=0x2203d0) at task.c:845
> #7  0x19b60c in run (uap=0x2203d0) at task.c:974
> 
> Disabling recursion will prevent the coredump...
> 
> Any ideas?
> 
> Thanks
> Paul Kelly
> 
> 
> On Thu, 15 Feb 2001, jps wrote:
> 
> > 
> > Hello,
> > 
> > has anyone tried successfully to use the postgres sdb sample
> > provided with bind 9 (up to 9.1.1rc2) ?
> > 
> > I used the zonetodb program to convert a working zone file
> > into a postgresql database, and recompiled bind9 to add
> > pgsqldb.c support (without any changes).
> > 
> > it works fine:
> > - when I dig 'ANY' my local zone.
> > - when I dig 'A' records for hosts within this local zone.
> > - when I dig 'NS' records for delegated sub-zones.
> > 
> > but when I dig 'A' records for any of the sub-zones:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > dns_rdata_clone (src=0xdededede, target=0xdededede) at rdata.c:369
> > 369             REQUIRE(DNS_RDATA_VALIDFLAGS(src));
> > 
> > with this backtrace:
> > 
> > #0  dns_rdata_clone (src=0xdededede, target=0xdededede) at rdata.c:369
> > #1  0x100b2338 in isc__rdatalist_current (rdataset=0xdededede, 
> > rdata=0x7ffff8b8) at rdatalist.c:124
> > #2  0x100b2c3c in dns_rdataset_current (rdataset=0x3004e0c0, 
> > rdata=0x7ffff8b8) at rdataset.c:254
> > #3  0x100b6b7c in fctx_getaddresses (fctx=0x3004e008) at resolver.c:1440
> > #4  0x100b7338 in fctx_try (fctx=0x3004e008) at resolver.c:1687
> > #5  0x100b8404 in fctx_start (task=0xdededede, event=0x3004e058) at 
> > resolver.c:1960
> > #6  0x10175ca8 in dispatch (manager=0x300280f8) at task.c:845
> > #7  0x10176520 in isc__taskmgr_dispatch () at task.c:1202
> > #8  0x101785b4 in evloop () at app.c:310
> > #9  0x101788d4 in isc_app_run () at app.c:502
> > #10 0x1000a778 in main (argc=3, argv=0x101a0000) at ./main.c:564
> > 
> > any idea ?
> > 
> > thanks,
> > 
> >  - Jean-Pierre.
> > 
> > 
> 
> 
> 



More information about the bind-users mailing list