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

--- lib/dns/sdlz.c.orig	2010-01-03 08:02:38.000000000 +1100
+++ lib/dns/sdlz.c	2010-01-12 02:41:41.000000000 +1100
@@ -1518,7 +1518,9 @@
 		ISC_LIST_APPEND(lookup->lists, rdatalist, link);
 	} else
 		if (rdatalist->ttl != ttl)
-			return (DNS_R_BADTTL);
+			isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE,
+			    DNS_LOGMODULE_DLZ, ISC_LOG_DEBUG(2),
+			    "Inconsistent TTL.");
 
 	rdata = isc_mem_get(mctx, sizeof(dns_rdata_t));
 	if (rdata == NULL)