Re: Problem with different TTL

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