[bind10-dev] new in-memory zone data design

[Peter Koch]

Shane,

first let me thank the team for the opportunity to observe this in-depth
discussion of algorithms and their avg/best case properties.

> The upside is that for large zones with mostly the same TTL, you save 4
> bytes per RdataSet. The downsides are that you have to figure out what
> that TTL is, and also for zones with multiple TTL you don't get any
> benefit. (Possibly you could try to optimize for zones with a small
> number of TTL, which is probably most zones, but that probably goes too
> far on the complexity level.)

set alert='bikeshed'

I'd be interested in the penalty, if any, that means for zones with non-
uniform TTLs.  There's already a case to distinguish between A/AAAA
and infrastructure data and I'd rather not see future DNS extensions
making TTL 'requirements' based on the performance argument.
Also, NSEC/NSEC3 and their RRSIGs usually have a different TTL than 'positive'
RR types.

> Ah, wildcards. I'm quite happy if zones using wildcards are less
> efficient than "normal" zones. I don't think we need to kill ourselves
> to optimize for a feature not used *so* commonly, and not at all for
> performance-critical zones, AFAIK.

Guilty as charged.  There are lots of wildcards in DE, albeit not immediately
under teh top level label.  However, there are lots of servers that serve
large numbers of (small) zones that do contain wildcard owners.

-Peter