Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?

[Viktor Dukhovni <[e-mail]>]

On Oct 24, 2018, at 5:57 AM, [e-mail] wrote:

> Surely any sequence of labels that terminates with a pointer to any
> label within that same sequence is an existence proof of such a loop.
> The degenerate case is a single label terminated by a pointer to
> itself.

So I gather that:

  1.  Pointers must indeed go back to an earlier location in the packet.
  2.  This is not alone quite sufficient to prevent loops.

Thus, given "1" we get the follow possibilities:

    a.  The most recent pointer expands to a name that terminates
        at an offset prior to the pointer.

    b.  The most recent pointer leads to an earlier label of the
        same domain (length-1 pointer loop).  This is easy to detect.

    c.  The most recent pointer expands to a domain that moves
        past the location of the pointer, without arriving at that
        pointer, because it is just part of the data of some label.
        For example:

           ... 10 05 l a r r y 10 m o e  NNN MMM     c u r l y [...]
              | initial length 10 label |ptr 10 back|
                 |len 5 label |len 10 pointer-skipping label |

        yielding the domain name:

		\005larry\010moe.larry.moe\NNN\MMMcurly.[...]

	in which the double occurence of "larry" and "moe" just
	happens to be possible to compress away, due to a fortuitous
        position in the packet, with the pointer bytes also matching
        label content within the domain name.

So it seems that with "1" enforced, and "b" easily handled, it seems
to me (ready to be proved wrong again) that the remaining way one
can get loops is for some pointer to expand to something that
(directly without traversing any other pointer) reaches that very
same pointer or skips past it as ordinary data in the expanding
name.  Such a packet does not violate the restriction on pointers
going forward, but supposing no loop results, is this a valid
compressed name?

I'm inclined to say that such a compressed name, by creating a
pointer to a name that ultimately that same pointer as label content,
is all too clever and that I would not be wrong to write a decoder
that rejects such compressed encodings.

Am I missing something this time?

-- 
	Viktor.