Spurious label compression pointers

[g]

Sure, here is the hex dump with ascii...

This is a TCP zone transfer of digex.net from ns.digex.net (sorry guys...), it is
one of the few servers that gives me problems. This particular query is simply a
zone transfer query (the client incidently is NT command line NSLookup.)

The DNS section starts at 0x36, the first two bytes are TCP Length so any
compression pointers should interpret a reference of 0x0 to position 0x38 on this
dump. You can see that for instance, the name server label in the SOA which is
found at position 0x59 has a pointer reference at position 0x5C, this correctly
points to reference 0x0C which translates to absolute packet position of 0x44 on
this dump. This is good and is what I would expect, this gives me an expanded name
of ns.digex.net which is hunkydory.

So, why later in the dump when we get to a NS RR with a label name of
www.phillips.digex.net... (at absolute position 0x3AD) does the pointer in the
RDATA of 'dd' reference 0x10 (which translates to an absolute position of 0x48)???
NSLookup interprets this RDATA to be dd.philips.digex.net. I must admit, I really
can't see how it gets this. It's not a local pointer so whats going on? I may have
just missed something subtle in the RFC, it may be that this is an old BIND bug
which clients must know about but I am sure that would be documented.

Thanks for your time

regards

Greg

[View this in a fixed width font]

00000030                    00 47 00 06 80 00 00 00 00 01       .G........
00000040  00 00 00 00 05 64 69 67 65 78 03 6E 65 74 00 00 .....digex.net..
00000050  06 00 01 00 00 2A 30 00 26 02 6E 73 C0 0C 0A 68 .....*0.&.ns...h
00000060  6F 73 74 6D 61 73 74 65 72 C0 0C 77 27 BA B2 00 ostmaster..w'...
00000070  00 2A 30 00 00 0E 10 00 02 A3 00 00 00 2A 30    .*0..........*0
..
<snip>
..
000002A0  05 61 74 6C 61 73 C0 13 00 2C 00 06 80 00 00 00 .atlas...,......
000002B0  00 01 00 00 00 00 06 74 65 6D 70 6E 73 05 64 69 .......tempns.di
000002C0  67 65 78 03 6E 65 74 00 00 01 00 01 00 00 2A 30 gex.net.......*0
000002D0  00 04 CF 57 06 08 00 30 00 06 80 00 00 00 00 01 ...W...0........
000002E0  00 00 00 00 02 64 64 07 70 68 69 6C 69 70 73 05 .....dd.philips.
000002F0  64 69 67 65 78 03 6E 65 74 00 00 01 00 01 00 00 digex.net.......
00000300  2A 30 00 04 CF 57 10 C3 00 39 00 06 80 00 00 00 *0...W...9......
00000310  00 01 00 00 00 00 0B 77 77 77 2D 73 65 72 76 65 .......www-serve
00000320  72 73 07 70 68 69 6C 69 70 73 05 64 69 67 65 78 rs.philips.digex
00000330  03 6E 65 74 00 00 01 00 01 00 00 2A 30 00 04 CF .net.......*0...
00000340  57 01 2B 00 39 00 06 80 00 00 00 00 01 00 00 00 W.+.9...........
00000350  00 0B 77 77 77 2D 73 65 72 76 65 72 73 07 70 68 ..www-servers.ph
00000360  69 6C 69 70 73 05 64 69 67 65 78 03 6E 65 74 00 ilips.digex.net.
00000370  00 01 00 01 00 00 2A 30 00 04 CF 57 13 15 00 32 ......*0...W...2
00000380  00 06 80 00 00 00 00 01 00 00 00 00 03 77 77 77 .............www
00000390  07 70 68 69 6C 69 70 73 05 64 69 67 65 78 03 6E .philips.digex.n
000003A0  65 74 00 00 02 00 01 00 00 2A 30 00 05 02 64 64 et.......*0...dd
000003B0  C0 10 00 2B 00 06 80 00 00 00 00 01 00 00 00 00 ...+............
000003C0  05 6A 6F 68 6E 6C 05 64 69 67 65 78 03 6E 65 74 .johnl.digex.net
000003D0  00 00 01 00 01 00 00 2A 30 00 04 C7 7D 86 59 00 .......*0...}.Y.
000003E0  34 00 06 80 00 00 00 00 01 00 00 00 00 05 6A 6F 4.............jo
000003F0  68 6E 6C 05 64 69 67 65 78 03 6E 65 74 00 00 0D hnl.digex.net...
..
<snip>


Barry Margolin wrote:

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