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

[JINMEI Tatuya / 神明達哉]

At Fri, 29 Jun 2012 19:25:35 +0200,
Peter Koch <pk at DENIC.DE> wrote:

> > 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.

Apart from how common it is to have different TTLs in a zone, I'd note
(or repeat) that in terms of memory-efficiency saving 4 bytes can be
moot for 64-bit machines (which I guess are more common today for
large scale operators where this kind of discussions matter).

> > 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.

Hmm, interesting.  Do you know how often these wildcard records are
used in DE?  In the case of large-#-of-small zones, I guess it also
depends on the expected total response performance.  I guess the
vast majority of the small zones are very minor in such cases, and if
the requested overall performance is moderate the additional overhead
due to wildcards can be less substantial.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.