[nsd-users] Suitability of NSD for ENUM

Matthijs Mekking matthijs at nlnetlabs.nl
Mon Apr 16 09:00:05 UTC 2012

Hash: SHA1

On 04/16/2012 11:01 AM, Rick van Rein wrote:
> 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.

Just to make myself clear, I agree with that statement.

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

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the nsd-users mailing list