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

[Mukund Sivaraman <[e-mail]>]

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.

		Mukund