[bind10-dev] Suboptimal way of splitting XFR-out to messages

[Mark Andrews]

In message <m2sjkyvrei.wl%jinmei at isc.org>, JINMEI Tatuya / =?ISO-2022-JP?B?GyRC
P0BMQEMjOkgbKEI=?= writes:
> At Mon, 05 Dec 2011 13:11:12 +0100,
> Shane Kerr <shane at isc.org> wrote:
> 
> > I think the best thing to do is probably to create a low-priority ticket
> > backlog mentioning this optimization, and why it is not very important.
> > Perhaps it makes sense to include a comment somewhere in the XFR-out
> > mentioning this as well?
> 
> Adding a comment is an easy task.  Maybe you want to create a ticket:-)
> 
> FWIW BIND 9 has the following comment (although it doesn't mention the
> suboptimal/optimization issues):
> 
> 		/*
> 		 * TCP. Build a response dns_message_t, temporarily storing
> 		 * the raw, uncompressed owner names and RR data contiguously
> 		 * in xfr->buf.  We know that if the uncompressed data fits
> 		 * in xfr->buf, the compressed data will surely fit in a TCP
> 		 * message.
> 		 */

Additionally using messages sizes large than 16K by itself lead to
sub-optimal compression as only the first 16K is available as targets
of compression pointers.  If you want to have optimal compression
you need to start a new message whenever the message overhead is
less than what is lost due to not having a compression target
available.  In most cases this happen a couple of records after the
16K mark.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org