Re: Problem with different TTL

Aurelien,

I have taken a quick look at this, it appears that you are right about the 
db being
read properly at this point. And with your modification, are you trying to 
avoid
errors, is that the main goal? If you are trying to get the different ttls 
to appear
then this most likely will require a patch to bind itself.

I am looking deeper into this however, as I need a little bit more time to 
set up
a mysql env to actually test this properly. Currently I have sqlite as the 
db, and although
I believe your assumptions to be correct I would like to be sure. Also, it 
was easy for me
to debug this little piece of code in windows using visual studio ( point 
and click ), please don't
make fun, as I am not as familiar with gdb as I am with VS.

Thanks,
Tim Tessier

--------------------------------------------------
From: "Aurelien Requiem" <[email protected]>
Sent: Saturday, January 02, 2010 4:09 PM
To: <[email protected]>
Subject: Re: [Bind-dlz-testers] Problem with different TTL

> Hi Tim,
>
> My TTL is read properly from what I've noticed. The problem only occurs
> when both are different otherwise, if they are identical, all is ok.
>
> I have attached the conf and the schema + data in the mail.
>
> Regarding te sources. I did a quick research and maid the following
> modification to fallback in the "text file" mode.
> This uses the 1st retrieved TTL from the DB to construct the answer. If
> a second record is found we don't check its TTL value, we don't use it
> and we don't raise the error.
> Only the 1st TTL value will be returned for both records as in the text
> file.
>
> --- lib/dns/sdlz.c.orig 2010-01-03 08:02:38.000000000 +1100
> +++ lib/dns/sdlz.c      2010-01-03 08:02:52.000000000 +1100
> @@ -1516,9 +1516,9 @@
>                 ISC_LIST_INIT(rdatalist->rdata);
>                 ISC_LINK_INIT(rdatalist, link);
>                 ISC_LIST_APPEND(lookup->lists, rdatalist, link);
> -       } else
> +       } /* else
>                 if (rdatalist->ttl != ttl)
> -                       return (DNS_R_BADTTL);
> +                       return (DNS_R_BADTTL); */
>
>         rdata = isc_mem_get(mctx, sizeof(dns_rdata_t));
>         if (rdata == NULL)
>
> I might be wrong, but Tim, if you want to confirm...
> I think the TTL values are properly read for the DB. At least the type
> seems to be ok "INT(11)".
> I haven't noticed any extra spaces too.
>
> Thanks
>
> Aurelien
>
> On 3/01/2010 6:26 AM, Tim Tessier wrote:
>> I actually had a similar problem while I was building a driver for 
>> sqlite.
>> Please verify that your ttl is actually correct and being read as a ttl
>> value.
>> I had an issue where the value being read into the ttl value was a 
>> fieldname
>> instead of an actual ttl. It could be that somehow your values are being
>> fudged
>> in such a way that the proper values are not coming through to bind. For
>> instance,
>> if for some reason you have spaces or extra values in places.
>>
>> If you have the config file and a sample db to try I can attempt to help.
>> Also, if you have the
>> sources, you can try writing some extra data to the logs for your result
>> sets to see if
>> something is going wrong there.
>>
>> Thanks,
>> Tim
>> --------------------------------------------------
>> From: "Aurelien Requiem"<[email protected]>
>> Sent: Saturday, January 02, 2010 5:49 AM
>> To:<[email protected]>
>> Subject: [Bind-dlz-testers] Problem with different TTL
>>
>>
>>> Hello,
>>>
>>> I'm having a bit of trouble at the moment with records with different 
>>> TTL.
>>> for www.test.menfin.net, I return 2 records. If both TTL are the same,
>>> everything is fine. If they are different, I have 2 behaviors
>>> With a regular text file, the 1st record TTL is returned for both
>>> records. If the query is answered by dlz, then nothing is returned.
>>> In the logs : dns_sdlz_putrr returned error. Error code was: bad ttl
>>>
>>> I know this question has been discussed in the past, but I still don't
>>> understand why such a difference between bind and dlz.
>>> http://article.gmane.org/gmane.network.dns.bind9.dlz/439/
>>>
>>> If such behavior isn't a wanted/good thing, could it be possible to make
>>> dlz behave like bind ?
>>> Or maybe does anyone know if this has been fixed/changed in more recent
>>> versions ?
>>>
>>> Regards.
>>>
>>> Environment :
>>>      gentoo / bind 9.4.3-p4 (ipv6, dlz, mysql, ssl)
>>>
>>> Aurelien
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Verizon Developer Community
>>> Take advantage of Verizon's best-in-class app development support
>>> A streamlined, 14 day to market process makes app distribution fast and
>>> easy
>>> Join now and get one step closer to millions of Verizon customers
>>> http://p.sf.net/sfu/verizon-dev2dev
>>> _______________________________________________
>>> Bind-dlz-testers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/bind-dlz-test
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and 
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Bind-dlz-testers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/bind-dlz-testers
>>
>
>



> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and 
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev



> _______________________________________________
> Bind-dlz-testers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bind-dlz- 


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev