[dns-operations] Pointer to discussion of name compression trade-offs?

[Viktor Dukhovni]

On Thu, Apr 30, 2020 at 07:55:00AM +0000, Paul Vixie wrote:
> On Thursday, 30 April 2020 07:17:48 UTC Viktor Dukhovni wrote:
> > I recall seeing a discussion (perhaps a few years back) of balancing
> > CPU-cost vs. space gained in DNS name compression.  Where IIRC it
> > was suggested that most of the gain may come from only storing and
> > checking the offsets of particular elements of the response, perhaps
> > just the qname and the owner of the current RRset, or was it owners
> > of all previous RRsets?  Or something like that, and that this saved
> > CPU with compression effectiveness not suffering much.
> > 
> > Does anyone have a pointer to discussion of this topic?
> 
> i didn't see it here, but i did see it on twitter and later at dns-oarc.
> 
> https://indico.dns-oarc.net/event/29/contributions/658/attachments/641/1039/Welcome_to_DNS-final.pdf

That's great, but I don't see any discussion of trade-offs there, the
"tdns" code appears at first glance to compress all names.  Perhaps the
point is that the tree updates and lookups are cheap enough to not slice
and dice which names to compress?

FWIW, it also looks like with very large TCP responses, the "tdns" code
could attempt to use pointers beyond the first 16k of the packet,
which would get truncated to 14 bits, corrupting the answer:

    https://github.com/ahupowerdns/hello-dns/blob/master/tdns/dnsmessages.cc#L131-L156

Once the payload offset is >= 2^14 the new offset should not be stored in
the tree.

-- 
    Viktor.