[nsd-users] Suitability of NSD for ENUM

[Rick van Rein]

Hello Matthijs,

> Although it can serve a reasonable number of zones, NSD3 has turned
> out to be not that good in scaling when it comes to a large number of
> zones. This will be tackled in NSD4. How many zones are we talking about?

Only tens right now.  But I'm thinking ahead of future growth, and with
NSD4 in the future, you seem to be working along the same path.  That
makes me quite happy, as I do prefer NSD.

> The domain name table is stored as a red black tree.

A self-balancing binary tree over the names -- excellent, and then indeed
Miek's remark applies that the number of labels or their lengths have no
influence on performance.  Well done :)

> > The Memory Usage tool is great --even if it does not show NAPTR
> > records-- but it does not take DNSSEC into account, right?  That
> > could be a useful addition to the tool?
> 
> True. Then again, it is an estimate tool;).

Ehm... it's a bit hard to estimate the footprint of DNSSEC.  Statements
like "the tenfold of data compared to unsigned" do not take into account
that the zone size varies -- but key size takes up a fixed amount of
space, while RRSIG scale along with the number of _names_, not _records_.

The tool would greatly benefit from explicit DNSSEC support, IMHO.  But
yeah of course, it's just an estimate.

> > If memory runs out, will NSD try to offload into swap, or is this
> > left to the OS?
> 
> This is OS specific.

OK, so it will keep the zone info loaded in memory, and VM should be
allocated accordingly.  NSD will not drop impopular data and reload it
from the database on demand.  That is neutral -- but good to know.


Thanks,
 -Rick