Re: Problem with different TTL

Aurelien,

I believe if I am not mistaken that sdb is maintained by the bind creators 
themselves.
I could be wrong however, and I am sorry that I could not help you more 
earlier. I will
try to use the patch myself.

Thanks,
Tim

--------------------------------------------------
From: "Aurelien Requiem" <[email protected]>
Sent: Monday, January 11, 2010 10:46 AM
To: <[email protected]>
Subject: Re: [Bind-dlz-testers] Problem with different TTL

> Tim,
>
> I have created a minor patch for dlz in order to accept the TTL like
> it's done in the text files.
> Basically, we only log the information in debug mode only. Nothing else.
> I don't think we should do more than logging compared to the text files
> behavior...
>
> Also, I don't know who's in charge of "sdb.c" but the same problem is
> present (same code).
>
> Please find the patch attach to this email. All comments are welcome.
>
> Thanks
>
>
> On 6/01/2010 6:47 AM, Aurelien Requiem wrote:
>> Tim,
>>
>> I'll try to work today on a cleaner patch and post it there for a code
>> review.
>> If it's well accepted by the community, I'll submit it into the code
>> repository.
>> I guess the change will be fairly simple and minor. I just need to
>> figure out what's the good way to log with warnings ;-)
>>
>> Thanks
>>
>> Aurelien
>> On 6/01/2010 2:00 AM, Tim Tessier wrote:
>>
>>> Aurelien,
>>>
>>> WARNING - not a file config example merely a RR example
>>>
>>> www IN A 127.0.0.1 TTL 25
>>> www IN A 127.0.0.2 TTL 50
>>>
>>> This is a problem because it's like saying that there are two separate 
>>> TTL's
>>> for
>>> the same resource even though they are logically the same resource
>>> regardless if
>>> they are different physical resources.
>>>
>>> www IN A 127.0.0.1 TTL 25
>>> www IN A 127.0.0.1 TTL 25
>>>
>>> Alternatively, this does nothing for the configuration and is a possible
>>> hint at configuration
>>> problems or some other issue arising due to abnormal means.
>>>
>>> $TTL 86400
>>> SOA ...
>>> www IN A 127.0.0.1 TTL 25
>>> www IN A 127.0.0.2 TTL 50[defaulting to 8600] would be bad
>>>
>>>
>>> $TTL 86400
>>> SOA ...
>>> www IN A 127.0.0.1 TTL 25
>>> www IN A 127.0.0.2 TTL 50[defaulting to 25] and outputting a critical
>>> warning without failing is desired
>>>
>>>    I agree however, that this shouldn't break the system.
>>> I believe you are on the right track. The better approach would be to 
>>> log a
>>> warning and not
>>> break the system. I do believe however that the TTL information will 
>>> have to
>>> be removed
>>> from the record information or duplicated from the first because if it 
>>> is
>>> not specified, then
>>> it might default to the default TTL for the zone which would be bad.
>>>    I believe a quick look at the bind sources is in order or a double 
>>> check of
>>> what happens when
>>> that Bad TTL is not returned. I can't locate the RFC that says this but 
>>> I am
>>> assuming that it is most definitely
>>> there and required, but also, should be handled by the dns configuration
>>> system. Of course, if I understood
>>> the problem correctly.
>>>
>>> Thanks,
>>> Tim Tessier
>>>
>>> --------------------------------------------------
>>> From: "Aurelien Requiem"<[email protected]>
>>> Sent: Tuesday, January 05, 2010 5:00 AM
>>> To:<[email protected]>
>>> Subject: Re: [Bind-dlz-testers] Problem with different TTL
>>>
>>>
>>>
>>>> Tim, Rob,
>>>>
>>>> Rob, where did you get the information about the TTL please ? If you
>>>> could point this in a document or RFC that would be very good.
>>>>
>>>> Tim, the main goal of my patch is to have dlz behave like bind. Nothing
>>>> more.
>>>> As explained, with a flat file with bind, if 2 different TTLs are set,
>>>> only the 1st one is return for all records.
>>>> With dlz, nothing is returned. The patch allow dlz to behave just like
>>>> bind.
>>>>
>>>> Thanks
>>>>
>>>> PS : I know what you mean about VS and gdb ;-) Instead of gdb, try 
>>>> using
>>>> ddd :-)
>>>>
>>>> Aurelien
>>>>
>>>> On 5/01/2010 4:05 AM, Rob Butler wrote:
>>>>
>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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-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-testers
>
> --------------0105020 


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