This release is an alpha release. There are some major changes in the name resolution algorithm, there is a new version of the zone compiler (not finished yet), and there are some internal changes. See the release notes below for more information.
If you decide to try this release we would appreciate it if you try to compiler your zones with both the old (zonec) and new (zonec2) compilers. They should produce exactly the same database file, except in cases where one of the compilers does not support certain RRs or character escapes. If they do not produce the same files we'd like to hear about it.
Please read the README document for configuration and installation
instructions.
looks good, my version of gcc (on linux) doesnt seem to like
"__attribute__ (format ..." for function pointers, I get
"argument format specified for non-function" errors.
> - Database can be loaded using mmap(2) (use the
> --enable-mmap
> configure option to enable). This is useful on operating
> systems such as Solaris that do not allow memory
> overcommit.
Not to start an overcommit flame war, but why would overcommit ever
"help" on a DNS server?
] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
"Erik" == Erik Rozendaal <erik@NLnetLabs.nl> writes:
> CODE CHANGES:
> - Database can be loaded using mmap(2) (use the
> --enable-mmap > configure option to enable). This is useful on operating
> systems such as Solaris that do not allow memory
> overcommit.
Not to start an overcommit flame war, but why would overcommit ever
"help" on a DNS server?
When NSD starts it loads the database into memory. After doing so, it forks of a (configurable) number of child servers to handle UDP and TCP connections. By default there is a single TCP server and a single UDP server. The child servers do not modify the database, so the operating system can share the memory pages between the parent process and the child process. Unfortunately, systems that do not allow memory overcommit will reserve memory anyway.
When the database is large (such as .de, which is about 6 gigabytes), this will result in the usage of 12 gigabyte of additional memory. Even though this memory is never used, systems that do not support memory overcommit will have to reserve this amount of space in real or swap memory.
When NSD starts it loads the database into memory. After doing so,
> it forks of a (configurable) number of child servers to handle UDP
> and TCP connections. By default there is a single TCP server and a
> single UDP server. The child servers do not modify the database,
> so the operating system can share the memory pages between the
> parent process and the child process. Unfortunately, systems that
> do not allow memory overcommit will reserve memory anyway.
Okay, got that.
But, a *Linux* system in default overcommit mode might kill NSD off
randomly. (or other processes) Solaris does different things.
If the data can, and should be shared (read-only), then the *correct* thing
is to mmap() things appropriately. That is the right thing to do, even on a
system that supports overcommit.
] Out and about in Ottawa. hmmm... beer. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy"); [
[On 22 Sep, @19:00, Michael wrote in "Re: ANNOUNCEMENT: NSD 1.3.0 al ..."]
-----BEGIN PGP SIGNED MESSAGE-----
> When NSD starts it loads the database into memory. After doing so,
> it forks of a (configurable) number of child servers to handle UDP
> and TCP connections. By default there is a single TCP server and a
> single UDP server. The child servers do not modify the database,
> so the operating system can share the memory pages between the
> parent process and the child process. Unfortunately, systems that
> do not allow memory overcommit will reserve memory anyway.
Okay, got that.
But, a *Linux* system in default overcommit mode might kill NSD off
randomly. (or other processes) Solaris does different things.
if you mean the OOM killer, upgrade to linux 2.4.23-pre5. A previous prepatch
removed the OOM killer from the stable linux tree.
Got a chance to do some initial testing anyway, the zone I'm
testing with has 958,848 records and compiles to about 242Mb.
zonec2 seems to take nearly 3 times as long compared to zonec
(average of 1m48s Vs 42s), I havn't done a profile yet to
figure out where it's spending most of it's time though.
On a first pass. zonec2 would not compile my zone, it seems to
require brackets around the parameters to the SOA, even when
they are on the same line, ie;
zone. 300 IN SOA noc.heanet.ie. zone. ( 1064248044 600 300 604800 300 )
will compile, but
zone. 300 IN SOA noc.heanet.ie. zone. 1064248044 600 300 604800 300
will not. The latter has always worked for me in the various
versions of bind and previous versions of zonec, and it's the
output dig usually generates.
[On 22 Sep, @20:46, Colm wrote in "Re: ANNOUNCEMENT: NSD 1.3.0 al ..."]
> I'll test 1.3 properly on Monday, but so far it's loading db files,
> and serving records
Got a chance to do some initial testing anyway, the zone I'm
testing with has 958,848 records and compiles to about 242Mb.
zonec2 seems to take nearly 3 times as long compared to zonec
(average of 1m48s Vs 42s), I havn't done a profile yet to
figure out where it's spending most of it's time though.
funny, we know it was performing more slowly, but we did not
measure 300% increase, more like 40%.
On a first pass. zonec2 would not compile my zone, it seems to
require brackets around the parameters to the SOA, even when
they are on the same line, ie;
zone. 300 IN SOA noc.heanet.ie. zone. ( 1064248044 600 300 604800 300 )
will compile, but
zone. 300 IN SOA noc.heanet.ie. zone. 1064248044 600 300 604800 300
will not. The latter has always worked for me in the various
must be bug. If I have the time I will check it tomorrow,
[Quoting Alexis Yushin, on Sep 17, 12:31, in "Re: ANNOUNCEMENT: NS ..."]
Hi,
Just a minor remark: with the code change that took place in this release I'd
strongly recommend calling it 2.x.x
We had had an extensive discussion on the numbering scheme at the
last NSD-team meeting.
The version scheme in short:
X.Y.Z
X: is updated at major functionality changes (like DNSSEC).
Y: is updated at major code-changes.
Z: is updated at bug-fixes and minor feature changes.
Version 1.3.x has a new name resolution algorithm in place plus a
new zonefile parser. There is hardly any functionality change with
respect to 1.2.x.
Version 1.4.x will have a new (two-step) database structure. Again,
there will be hardly any functionality change.
The steps in 1.3.x and 1.4.x are necessary in preparation for
DNSSEC support.
Version 2.0.0 will be the first version that includes full DNSSEC
support.
Jakob Schlyter writes:
> I'd like to second this - do not rely on overcommit.
>
> is performance worse with mmap?
Performance should be the same, but there's a different problem: if you
edit the file while nsd has it mapped, fun ensues.
I agree, though. It's better to mmap() and pray that the file isn't
changed, than to read() and pray that overcommit won't explode.
Seeing this discussion and being agnostic, it seems to me that this
has more to do with the operating environment (amount of data served,
operating system used etc.) then with nsd itself, praying is not
an option.
My suggestions is, that a proper thing to do is to document that
nsd has specific memory requirements (lots) and how the various
system might deal with it or not. For the known cases, there will
be some defaults, however, there should be some hooks to the
configure/makefiles to allow for tuning to the environment.
It's better to mmap() and pray that the file isn't changed, than to read() and pray that overcommit won't explode.
Seeing this discussion and being agnostic, it seems to me that this has more to do with the operating environment (amount of data served, operating system used etc.) then with nsd itself, praying is not an option.
If the nsd admin is in a position to guarantee that nsd.db is never edited, mmap() is fine.
To do that, write access to nsd.db must be tightly controlled and zonec must use e.g. "open(); write(); close(); rename()" in order to build the new database without touching the old one. So, root passwords carefully controlled, no stray users with write access to the nsd files, etc.
My suggestions is, that a proper thing to do is to document that nsd has specific memory requirements (lots) and how the various system might deal with it or not.
How many linux 2.4.x kernels have contained sweeping VM changes so far? The one mentioned this week was a prepatch, even. I don't think "document how various systems might deal with it" is a good policy when the _stable_ linux kernels change like that.
How many linux 2.4.x kernels have contained sweeping VM changes so far?
The one mentioned this week was a prepatch, even. I don't think
"document how various systems might deal with it" is a good policy when
the _stable_ linux kernels change like that.
[On 25 Sep, @13:15, Arnt wrote in "Re: mmap vs alloc ..."]
>My suggestions is, that a proper thing to do is to document that nsd
>has specific memory requirements (lots) and how the various system
>might deal with it or not.
How many linux 2.4.x kernels have contained sweeping VM changes so far?
The one mentioned this week was a prepatch, even. I don't think
"document how various systems might deal with it" is a good policy when
the _stable_ linux kernels change like that.
to stray entirely offtopic.
linux 2.4.10 contained a new VM, this AA VM (named after the developer Andrea
Arcangeli) was said to be much better than the stuff built by Rik van Riel.
This was the one big change of VM's in Linux 2.4. Since 2.4 came out people
moaned about the OOM killer (which kind of sucked, because most of the time
it would kill the wrong process). So now finally this OOM killer has been
removed and linux 2.4.24 will finally ship with a sane VM.
In 2.5/2.6 things are better organized with the Reverse Mapping VM from (again)
Rik van Riel,
How many linux 2.4.x kernels have contained sweeping VM changes so far? The one mentioned this week was a prepatch, even. I don't think "document how various systems might deal with it" is a good policy when the _stable_ linux kernels change like that.
Not all operating systems have linux kernels.
Sure. I'm a freebsd user now myself (after 10+ years of linux).
What I'm saying is:
1. If one documents how unix software works on different unixes, linux must be included. It's too important. Fringe systems such as openserver can be skipped, linux not.
2. Since there have been multiple major changes in the 2.4 series, it's reasonable to assume that there will be more (in 2.4 and/or 2.6), and "document how program x works on linux vm" is then a bad policy.
3. 1 and 2 combine to make "document it" a bad policy in general.
Documentation is good. But it's not a cure for all ills.
