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

Mukund Sivaraman <> Thu, 25 October 2018 03:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A2E0130DDF for <>; Wed, 24 Oct 2018 20:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E5FtcLbpdkn8 for <>; Wed, 24 Oct 2018 20:09:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 25203130934 for <>; Wed, 24 Oct 2018 20:09:32 -0700 (PDT)
Received: from jurassic (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1CE0032C0912; Thu, 25 Oct 2018 03:09:29 +0000 (UTC)
Date: Thu, 25 Oct 2018 08:39:26 +0530
From: Mukund Sivaraman <>
To: Ted Lemon <>
Cc: Shane Kerr <>, dnsop WG <>
Message-ID: <20181025030926.GA15675@jurassic>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <>
Subject: Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Oct 2018 03:09:36 -0000

On Wed, Oct 24, 2018 at 04:26:37PM -0400, Ted Lemon wrote:
> The good news is that in a typical DNS message, N is pretty small.
>  Although I suppose in an internet-facing name server, pretty small is
> still pretty big...

In BIND, name compression is still one of the big consumers of CPU. It
was tweaked for 9.12 to reduce the aggression of finding longest match,
but the custom compression specification in DNS is awkward. Matching
against every previously emitted label sequence when done aggressively,
dealing with case issues, limiting compression offset to first 16kB of
the message, etc. are all quirks.

A generic compression algorithm such as deflate over the whole message
may have done better as libraries have fast hand-written matching
subroutines in assembly. Such arch specific code of fast custom matching
is not reasonable to expect of a DNS implementation.

Disabling compression is almost desirable to avoid finding matches
(hence the message-compression named option), but RFC 1123 (which
predates EDNS) forbids it.