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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 24 October 2018 09:02 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6C311130E7F for <dnsop@ietfa.amsl.com>; Wed, 24 Oct 2018 02:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rMpTlHE6vbIp for <dnsop@ietfa.amsl.com>; Wed, 24 Oct 2018 02:01:58 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A5D130E7E for <dnsop@ietf.org>; Wed, 24 Oct 2018 02:01:58 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id A4A7A704C5 for <dnsop@ietf.org>; Wed, 24 Oct 2018 05:01:55 -0400 (EDT)
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Reply-To: dnsop <dnsop@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Message-Id: <BC2CDF40-4FF0-4111-88B7-04969491D2E0@dukhovni.org>
Date: Wed, 24 Oct 2018 05:01:53 -0400
To: dnsop <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I-VRQLwqBBdmELDZfaGHpMufPYE>
Subject: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Oct 2018 09:02:01 -0000

My reading of RFC 1035 is that DNS name "compression"
via "pointers" is restricted to name strictly earlier
in the DNS message:

   4.1.4. Message compression

   In order to reduce the size of messages, the domain system utilizes a
   compression scheme which eliminates the repetition of domain names in a
   message.  In this scheme, an entire domain name or a list of labels at
   the end of a domain name is replaced with a pointer to a prior occurance
   of the same name.

And yet, here and there I see mention of having to take care to avoid "loops",
but loops are impossible in a monotone strictly decreasing sequence.

Is there a later RFC that relaxes the constraint and allows pointers to names
later in the message?  I'm having a bit of trouble finding the later text...

Secondarily, can the pointer point to some odd-ball location earlier in the
message that is not semantically a label in its original context, but just
happens to carry data that decodes as the desired label?  Or, are pointers
only valid to prior locations that are corresponding labels in their original