Re: BIND-DLZ cache corruption issue.

Michael,

Please bring this up to the BIND developers.  DLZ is integrated into BIND now 
and the fix would have to be done there.

Rob


>
>From: Michael J. Ayers <[email protected]>
>To: [email protected]
>Sent: Fri, October 1, 2010 12:14:32 PM
>Subject: Re: [Bind-dlz-testers] BIND-DLZ cache corruption issue.
>
>Hey Graeme,
>
>
>That might be an option, I just think it is the wrong way to handle the issue 
>for a couple of reasons.  First, DLZ implementation is not documented in this 
>way.  That means it would fix the issue for myself and the organization I work 
>for but wouldn't resolve the issue for new or current adopters who are not 
>paying attention to this thread.  If the documentation were to change 
>I wouldn't feel this way, but I haven't seen a substantial change in 3-4 years, 
>so I wont hold my breath.  Second, you cannot just limit TXT records in this 
>way.  The data for the record is stored in the 'data' field just like every 
>other record.  While no other records currently approach this length, that 
>doesn't mean that a future one will not.  So it could be considered an 
>artificial limitation to restrict the entire data field in this manner when I 
>might have to open it up again in two years because DNSSEC implemented another 
>record type.  It also means a one-off departure, again from the documented 
>implementation, that I have to individually document here for those who pick up 
>any work I might leave behind in the future.  I could go on and on.
>
>
>My opinion, and it is just that, is that the proper way to resolve this is in 
>the code itself to gracefully handle this type of issue.  It does not seem like 
>it would be a complex modification and I think the gains of implementing it in 
>this way far outweigh any potential losses.  The developers will have to speak 
>to that though.  I am however more than willing to be as involved in this 
>process as a guinea pig, tester, etc. as they see fit.
>
>
>Thanks,
>
>
>Mike
>
>
>On Fri, Oct 1, 2010 at 1:45 AM, Graeme Fowler <[email protected]> wrote:
>
>On Thu, 2010-09-30 at 20:46 -0700, Michael J. Ayers wrote:
>>> This particular issue is cannot be replicated with a flat text zone
>>> file.  That issue was fixed with I believe the 9.5 release.  BIND now
>>> properly throws an error when it encounters a TXT record that is
>>> longer than 255 bytes in length or is not properly closed in
>>> quotations.
>>
>>So...
>>
>>Set the database schema such that TXT records have a maximum length of
>>253 - char(253) in SQL parlance - and then ensure that the query BIND
>>makes through the DLZ driver has escaped quotes at either end. That
>>assumes that the quotes are included in the character string length as
>>defined in the RFC for TXT records (1034 or 1035 IIRC).
>>
>>That way you eliminate the possibility of corrupt data as described. It
>>may still be possible to malform the data, but not in the way you
>>describe.
>>
>>Graeme
>>
>>
>>
>>------------------------------------------------------------------------------
>>Start uncovering the many advantages of virtual appliances
>>and start using them to simplify application deployment and
>>accelerate your shift to cloud computing.
>>http://p.sf.net/sfu/novell-sfdev2dev
>>_______________________________________________
>>Bind-dlz-testers mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/bind-dlz-testers
>>
>
>
>-- 
>Michael J. Ayers
>Senior Systems Engineer
>

------------------------------------------------------------------------------
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security 
easier or more difficult to achieve? Read this whitepaper to separate the 
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d

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