Re: Problem with different TTL

DNS requires all the TTL's for a RRset be the same.  A RR set is all the records of the same type (like A, TXT, MX) for the same name.  Thus, if you have two records with the same name and of the same type with different TTL's, your data is incorrect.

Rob

----- Original Message ----
> From: Tim Tessier <[email protected]>
> To: [email protected]
> Sent: Mon, January 4, 2010 10:56:52 AM
> Subject: Re: [Bind-dlz-testers] 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" 
> Sent: Saturday, January 02, 2010 4:09 PM
> To: 
> 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"
> >> Sent: Saturday, January 02, 2010 5:49 AM
> >> To:
> >> 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 
> _______________________________________________
> 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