Spurious label compression pointers

[g]

Hello,

In DNS label compression (a la RFC 1035) a compression pointer is a two
byte field. The first two bits of which are set to 11 leaving 14 bits
for the pointer value. I have written an NSLOOKUP type tool that works
very well except on certain servers that use compression. It handles
most servers with compression no problem but certain servers (e.g.
NS.DIGEX.NET, SONY.COM etc.) seem to return pointer values that
pointeither nowhere logical or to the middle of a previous label, the
net effect of this is badly decoded labels.

I have read RFC1035 back to front, upside down and inside out but this
just does not make sense to me. I have read about the newer local
compression which starts with '10' and then points to a byte within the
CURRENT record but this is not what is causing the problem. Anyone seen
this anywhere? UN*X and NT NSLookup handle these bizzare pointers just
fine but to me, looking at the raw DNS packet in hex and applying
RFC1035 it just doesn't add up.

Has anyone encountered this? I beleive that certain, older versions of
BIND produce pointers incorrectly in certain circumstances, but if that
is the case - how do the NSLookup clients I have used handle them?

Perhaps I should add that the responses are typically TCP zone transfers
but UDP standard RR queries produce the same result...

Hope some one has seen and sorted this one before....

regards

G