Spurious label compression pointers

[Barry Margolin]

In article <37EFC1AE.EB1A47FA at HooBie.net>, g  <g at HooBie.net> wrote:
>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.

Can you post specific queries that exhibit this, perhaps including a hex
dump of the packet that you think is wrong?

-- 
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.