Spurious label compression pointers

[Barry Margolin]

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

Zone transfers can be sent in two formats: one-answer or many-answer.  The
traditional way is one-answer, and servers usually send in this format
unless the DNS administrator overrides the default because he knows that
all the slave servers understand the one-answer format.

In one-answer format, each resource record in the zone transfer is a
separate DNS message, each with its own DNS header.  Thus, offsets are
relative to the start of that message, not the first message in the zone
transfer.

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