Case-Insensitive Response Compression May Cause Problems With Mixed-Case Data and Non-Conforming Clients

Mark Andrews marka at isc.org
Mon Feb 10 14:56:14 UTC 2014


In message <22ppmve5pg.fsf at ziptop.autonomica.net>, Lars-Johan Liman writes:
> [Using my old e-mail address since I noticed that it's still used for
> this list. I need to fix that ...]
> 
> marka at isc.org:
> > Named is not yet fully case preserving.  Owner names are stored based on
> > first use of the name in the database (zone or cache) when the red black
> > tree is created.  We need to extend the database to record the case used
> > in the owner name.  The are two obvious ways to do this.
> 
> > 	1) record the complete owner name with the rdata.
> > 	2) record a bit vector that contains the case bit (0x20)
> > 	   of each character in the owner name.
> 
> Hmm. How correct will 2) be if the byte has the high bit set (i.e., its
> value is in the range [128-255])? Will there be "bad" consequences?
> I'm sure you've been down that path already. :-)

Given those octets are not case insensitive the contents of the bit
in the character will match the contents of the bit in the vector.
Similarly for everything that isn't a alpha character.  It's only
for the alpha characters that they may differ.  It's likely to be
as fast or faster to set/clear the bit in every character as it is
to go if isalpha() then set/clear the bit only if it is alpha.

Something like this will do it.  This even records the 0x20 bit
of the length octets.

	unsigned char vector[32];

	/* Record the original case */
	memset(vector, 0, sizeof(vector));
	for (i = 0; i < name->length; i++)
		if (name->data[i] & 0x20)
			vector[i>>3] |= (0x1u << (i&0x7);

	/* Restore the original case */
	for (i = 0; i < name->length; i++)
		if (vector[i>>3] & (0x1u << (i&0x7))
			name->data[i] |= 0x20;
		else
			name->data[i] &= ~0x20;

Since we know the name length we can just store ((name->length + 7 ) / 8)
octets at the start of each rr assuming we have the name->length whenever
we would need it otherwise we can store the length as well to make it self
describing.

> I'm not sure assuming that the value is in the [0-127] range forever and
> all is correct, even if that happens to be the case* this very decade ...
>
> 
> 				Cheers,
> 				  /Liman
> * Pun intended. :-)
> #----------------------------------------------------------------------
> # Lars-Johan Liman, M.Sc.               !  E-mail: liman at netnod.se
> # Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
> # Netnod Internet Exchange, Stockholm   !  http://www.netnod.se/
> #----------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


More information about the bind-workers mailing list