Bind 9 and sdb

Paul Kelly pkelly at virtual.org.uk
Mon Feb 19 23:12:10 UTC 2001


my mistake the original code is right :/ sorry for spamming the list

paul

On Mon, 19 Feb 2001, Paul Kelly wrote:

> 
> 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