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

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