Suitability of NSD for ENUM

NSD
1

Hello,

I'm rolling out a registrar service for ENUM and wondering if NSD is
suitable for its special format -- rather long lists of labels in a
zone name and potentially a lot of small domains. Scaling is what I'm
wondering about.

Did I understand correctly that the search for an RRset is done on
the entire label list (or name) requested? So the special format of
names in ENUM is not special in any way?

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?

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

This is wishful thinking of course... it'd be cool if ENUM would be a
scalability problem... but I'm looking ahead, and hoping to cause those
scalability problems in the years to come :wink:

Thanks,

Rick van Rein
OpenFortress

2

[ Quoting <rick@openfortress.nl> in "[nsd-users] Suitability of NSD for ..." ]

Hello,

I'm rolling out a registrar service for ENUM and wondering if NSD is
suitable for its special format -- rather long lists of labels in a
zone name and potentially a lot of small domains. Scaling is what I'm
wondering about.

What special format? It's just an domain name.

NSD scales very well, except for large numbers of small zones, esp.
if you want to add/remove them on the fly.

I thought (I'm not involved) NSD4 is set to remedy these issues.

Regards,

3

Hello,

What special format? It's just an domain name.

It all depends on how it works internally, which is a blank to me.
Some names are just d.i.f.f.i.c.u.l.t to read if you handle all the
labels separately.

Scaling many small zones is also a problem for DNSSEC, I suppose.
And /of course/ I want to support DNSSEC on ENUM!

Thanks,
-Rick

4

Hi,

Hello,

I'm rolling out a registrar service for ENUM and wondering if NSD
is suitable for its special format -- rather long lists of labels
in a zone name and potentially a lot of small domains. Scaling is
what I'm wondering about.

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?

Did I understand correctly that the search for an RRset is done on
the entire label list (or name) requested? So the special format
of names in ENUM is not special in any way?

The domain name table is stored as a red black tree. Each domain name
is treated equally, when it comes to searching (it is just another
node in the tree).

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

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

This is OS specific.

Best regards,
  Matthijs

5

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

> 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

6

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

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.

7

[ Quoting <rick@openfortress.nl> in "Re: [nsd-users] Suitability of NSD ..." ]

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

Future growth, ENUM... You make me curious :slight_smile:

grtz Miek

8

is 10000 large?