From debian/patches/disable-nsupdate.patch -#define NSUPDATE +/* #define NSUPDATE */
In looking at server/dhcpd.c, I see a number of NSUPDATE defines; around line 1035, there’s the syslogmessage we’re all seeing. #if defined (NSUPDATE) (DDNS Code) #else /* If we don't have support for updates compiled in tell the user */ if (ddns_update_style != DDNS_UPDATE_STYLE_NONE) { log_fatal("Support for ddns-update-style not compiled in"); } #endif That’s the *exact* error message I’m seeing in 4.3.3-3. The whole point of NSUPDATE is to update DNS… As far as bug 712503 (where NSUPDATE was disabled) goes, it makes sense to me that dhcp would have to hold a random port open so named can communicate with it. My guess (having not read the code) is that its behavior isn’t that different from how a web browser sends opens and sends data from a random port TO the server… and the reply comes from the server back to the sending port. The web browser has to listen on that port to receive the reply. In the same way, dhcpd has to open the (random) port, and send the data TO named for NSUPDATE… and also has to hold the port open to receive a reply (success/failure/whatever) from named. I’ll grant I’m **totally ignorant** of what actually happens between dhcpd and named, but it seems sensible to me... -- Troy Telford ttelford.gro...@gmail.com