Hello all, I'm currently busy trying to setup a server running NSD and new to that. From what I read on the list archives and documentation, zone transfers are not automatically handled. Suggestion is to use a cronjob and some people talked about using a plugin for such a task. My question is, what is the mechanism the most used amongst people on this list? And why? My thoughts is that when running a server as secondary for domains you don't have control on, the notify messages are quite useful to provide a good service to your users. On the other hand, too much notify messages can induce unneeded load on the server. Is there a publicly available plugin that could solve both issues: accept notify messages and trigger a transfer if needed, avoid too many notify messages? Thanks for your time, Antoine. -- http://www.belnet.be Tel: + 32 2 790 33 33 BELNET Service Support Team Fax: + 32 2 790 33 34>> Thanks to avoid sending me Word or PowerPoint attachments >> http://www.fsf.org/philosophy/no-word-attachments.html >> Please prefer plain/text mails instead of HTML ones.
[On 15 Oct, @ 15:43, Antoine wrote in "Handling of zone transfers and ..."]> My question is, what is the mechanism the most used amongst people on this > list? And why?I don't know what's used most, but what I use at home is just: % more nsd # do hourly nsdc update, to update the slave information # 17 over the hour 17 * * * * root /usr/sbin/nsdc update ie. a cronjob which checks every hour. If there are no updates, there is no ouput and you will not receive mail. If there is some problem connecting to a server you will get mailed every hour however. There is some stuff in the development pipeline, but I don't know the precise status of that. grtz Miek
Antoine Delvaux <antoine.delvaux at belnet.be> writes:> My thoughts is that when running a server as secondary for domains > you don't have control on, the notify messages are quite useful to > provide a good service to your users. On the other hand, too much > notify messages can induce unneeded load on the server.I'm still running 1.2.2 (been running nsd for a couple of years at this point) to secondary about 1000 zones, most of which are in turn secondaried from other hosts on the server from which I'm pulling them. The vast majority of them (98%) are Someone Else's Zones. One problem I've noticed (hopefully fixed in newer versions) is that "nsdc update" does not deal gracefully with having an expired or non-transferable zone. To my way of thinking it should either build nsd.db including the expired data but unset the authority bit in replies or simply leave the zone out of nsd.db rather than refusing to update the database for the other zones. My work-around has been to have a "metaconfig" nsd.zones file which is compiled into the "working" nsd.zones file before each "nsdc update" by a script that issues a query for the SOA record against the master nameserver for each zone and checks for the authority bit. Crude, but effective. If I need a swat with the clown hammer and incentive to upgrade, someone please tell me to get off my lazy behind. :) ---Rob
It may be useful to first have consensus on what we really want. Then we can see what we can do when our own AXFR is ready, and what we can do in the mean time using the bind-8 AXFR. I'll try to summarize: Suppose we have two more zones to service, some of which comes from elsewhere, f.i. with AXFR (but scp, rsync, whatever is also possible, but the main thing is that we have no control over the contents). We have 3 separate tools: 1. The AXFR (scp, rsync, whatever) tool and wrapper-script. 2. Zonec and wrapper-script. 3. The nsd daemon process. We want 1: - to check that the AXFR (scp,..) has succeeded and, as far as possible, to check for syntax-errors. - if above has failed, we want to keep the old zone-file (i.e. copy the current zone-file to the new temp directory. This way we make sure we have the complete set of zones. We want either 1, 2, or 3 (??) to check whether the zone-file has not expired. I think 1 would be best. 2 is perhaps possible. I'd like to keep 3 as mean and lean as possible, and thus not to clobber the daemon with it: when a zone has expired, 3 (the NSD daemon) should just not serve it (remove AA is not suitable for an auth-only server, and to hand out expired data is plain wrong). Meaning that tool 1 or 2 should just delete the expired zone-file. -- ted