Hi:
I'm testing nsd to be used as slave of a ccTLD (following the idea
proposed by Stephen).
I haven't good experience about it. The primary is a BIND 9 server,
sending notifies to my testing server. nsd seems to ignore notifies and
avoid periodical retries as specified in REFRESH soa param.
The server is able to transfer the zone and compile it with zonec free
of problems. If I run 'nsdc update' everything goes ok.
What should I do to prepare a nsd to be slave? I know is possible, as
told by Stephen and the root servers managers.
Best Regards
a message of 29 lines which said:
I haven't good experience about it. The primary is a BIND 9 server,
sending notifies to my testing server. nsd seems to ignore notifies
Indeed. I believe it is even documented somewhere.
What should I do to prepare a nsd to be slave?
Two realistic solutions and an experimental one:
* use a "logfile monitor" (we use SEC
<URL:http://kodu.neti.ee/~risto/sec>\) with a regexp of "nsd.*notify
from" and an action of "nsdc update".
* use cron to recompile every hour or less (ns2.nic.fr receives one
NOTIFY every ten minutes, there is not really any point in waiting for
them, we just recompile periodically).
* (Untested) see what's new in NSD 1.2 (just released). May be there
is a notify-handler plugin?
[Quoting Sebastian Castro, on Jul 9, 16:12, in "nsd running as slave ..."]
sending notifies to my testing server. nsd seems to ignore notifies and
That's correct.
avoid periodical retries as specified in REFRESH soa param.
That's also correct.
The server is able to transfer the zone and compile it with zonec free
of problems. If I run 'nsdc update' everything goes ok.
NSD expect you to put 'nsdc update' in crontab.
Please look in the README under
3.3 Keeping in sync the secondary zones with ``nsdc update'
There were good reasons to do it like this (keep the daemon light weight".
However, people are looking into a plugin, reacting properly
on incoming notifies. Plugings are supported as of version 1.2.
-- ted
I have most of the code ready for one, should be mailed to the list
early next week. But if anyone else wants to beat me to it, fire
away!
Right now I'm working on making an ACL plugin compile against the
current API (the works are all there now), and should be on the
list either later tonight, or early next week at the latest.
Hi Sebastian,
i would not run a nameserver in slave mode in a registry
environment. The best thing would be if you run all
nameservers as master. You have to provide the zonefile
to all the nameservers and then recompile the zonefile
at the nameserver which runs nsd. With the bind nameserver
you proceed as normal.
There are a lot of possibilities to implement this way.
If you need help, please ask for it.
Best Regards
Sven-Holger
Once Ted Lindgreen wrote:
...
There were good reasons to do it like this (keep the daemon light weight".
However, people are looking into a plugin, reacting properly
on incoming notifies. Plugings are supported as of version 1.2.
Which would only be useful if NSD database is split into zones, as
opposed to one flat namespace we have now.
Alexis
[Quoting Alexis Yushin, on Jul 9, 17:22, in "Re: nsd running as s ..."]
Once Ted Lindgreen wrote:
...
>There were good reasons to do it like this (keep the daemon light weight".
>
>However, people are looking into a plugin, reacting properly
>on incoming notifies. Plugings are supported as of version 1.2.
Which would only be useful if NSD database is split into zones, as
opposed to one flat namespace we have now.
Perhaps I mis something, but what I thought that people want is,
just to run "nsdc update" when a notify arrives (in contrast to
"when crontab thinks it's time"). The "nsdc update" will then do
the right thing (rebuild the database and signal nsd when necessary
or do nothing).
A trivial plugin can do some sanity check on arrival of a notify
and then fork and exec "nsdc update".
The sanity check is wise to prevent vulnaribility for DoSsing
by a notify flood. I guess a simple timer (ignore new notifies
for xx seconds/minutes after having forked+execed) would suffice.
-- ted
a message of 28 lines which said:
The sanity check is wise to prevent vulnaribility for DoSsing
by a notify flood. I guess a simple timer (ignore new notifies
for xx seconds/minutes after having forked+execed) would suffice.
We use a small shell script as a wrapper for "nsdc update".
#!/bin/ksh
PATH=${PATH}:/local/sbin
lockfile=/var/run/afnic-nsdc.lock
trap "rm -f $lockfile; exit 1" 1 2 3 15
if [ -e "${lockfile}" ]
then
echo "Another update/rebuild is running, cancelling (if it is an error, delete ${lockfile})"
exit 0
fi
# Small race condition here
echo $$ > "${lockfile}"
nsdc update
sleep 600 # Let the machine rest
rm -f "${lockfile}"