We upgraded to NSD 3.2.9 (from 3.2.8) because we encountered the problem "Fix denial of existence response for empty non-terminal that looks like a NSEC3-only domain (but has data below it)." (a nasty problem with DNSSEC). But we now have IXFR issues. On one name server, NSD 3.2.9 works fine, zones are IXFRed and work. On another name server, with much more zones (and big ones), we deleted the databases and compiled everything again with zonec (no problem). The server works fine but, when a zone for which it is a slave is modified, we see the following: 1) Zones are transferred from the master. nsd-patch -l says: zone zonecheck.fr transfer id 4e4f serial 2010101202 timestamp 1330954843.828433: seq_nr 0 of 287 bytes zone zonecheck.fr transfer id 4e4f serial 2010101202: commit of 1 packets time Mon Mar 5 13:40:43 2012, from serial 2010101201, log message: xfrd: zone zonecheck.fr received update to serial 2010101202 at time 1330954843 from 192.134.4.2 in 1 parts 2) But the daemon does not take them into account (see the serial number on ns2.nic.fr): % check_soa zonecheck.fr zonecheck.fr. 2010101202 (pri) dnsmaster.nic.fr. zonecheck.fr. 2010101202 (sec) ns1.nic.fr. zonecheck.fr. 2010101201 (sec) ns2.nic.fr. zonecheck.fr. 2010101202 (sec) ns3.nic.fr. We do not see in the log the message which indicates the update. With 3.2.8, we had: Mar 5 13:20:38 ns2 nsd[25255]: Zone zonecheck.fr serial 2010101200 is updated to 2010101201. 3) We also observe that nsd-patch now runs endlessly: # nsdc patch reading database database region after loading domain names: 20487745 objects (20487745 small/0 large), 1327521688 bytes allocated (35924654 wasted) in 324102 chunks, 324101 cleanups, 9631752 in recyclebin 39547 0 0 0 0 4938 14951 23553 18949 19717 20350 20846 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 database region after loading database: 63529025 objects (63529016 small/9 large), 2553031096 bytes allocated (37243126 wasted) in 623293 chunks, 623301 cleanups, 10819688 in recyclebin 0 29842 37070 0 21837 19073 27919 0 22414 25163 24075 0 704 815 720 0 32 152 160 0 45 49 52 0 36 42 51 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 reading updates to database [Then nothing, until we kill the process] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11124 nsd 25 0 2496m 2.4g 256 R 100.0 7.7 11:27.74 nsd 11295 root 25 0 2472m 2.4g 668 R 100.0 7.6 8:11.07 nsd-patch (With 3.2.8, it takes only 2-3 minutes on the same machine) 4) Downgrading to 3.2.8, everything works fine again.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stephane, This is fixed in NSD 3.2.10: Bugfix #423: Fix slow zone transfer processing due to 'Fix is_existing flag for ENT' bugfix. Best regards, Wouter On 03/05/2012 03:37 PM, Stephane Bortzmeyer wrote:> We upgraded to NSD 3.2.9 (from 3.2.8) because we encountered the > problem "Fix denial of existence response for empty non-terminal > that looks like a NSEC3-only domain (but has data below it)." (a > nasty problem with DNSSEC). But we now have IXFR issues. > > On one name server, NSD 3.2.9 works fine, zones are IXFRed and > work. > > On another name server, with much more zones (and big ones), we > deleted the databases and compiled everything again with zonec (no > problem). The server works fine but, when a zone for which it is a > slave is modified, we see the following: > > 1) Zones are transferred from the master. nsd-patch -l says: > > zone zonecheck.fr transfer id 4e4f serial 2010101202 timestamp > 1330954843.828433: seq_nr 0 of 287 bytes zone zonecheck.fr transfer > id 4e4f serial 2010101202: commit of 1 packets time Mon Mar 5 > 13:40:43 2012, from serial 2010101201, log message: xfrd: zone > zonecheck.fr received update to serial 2010101202 at time > 1330954843 from 192.134.4.2 in 1 parts > > 2) But the daemon does not take them into account (see the serial > number on ns2.nic.fr): > > % check_soa zonecheck.fr zonecheck.fr. 2010101202 (pri) > dnsmaster.nic.fr. zonecheck.fr. 2010101202 (sec) ns1.nic.fr. > zonecheck.fr. 2010101201 (sec) ns2.nic.fr. zonecheck.fr. 2010101202 > (sec) ns3.nic.fr. > > We do not see in the log the message which indicates the update. > With 3.2.8, we had: > > Mar 5 13:20:38 ns2 nsd[25255]: Zone zonecheck.fr serial 2010101200 > is updated to 2010101201. > > 3) We also observe that nsd-patch now runs endlessly: > > # nsdc patch reading database database region after loading domain > names: 20487745 objects (20487745 small/0 large), 1327521688 bytes > allocated (35924654 wasted) in 324102 chunks, 324101 cleanups, > 9631752 in recyclebin 39547 0 0 0 0 4938 14951 23553 18949 19717 > 20350 20846 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 database region after > loading database: 63529025 objects (63529016 small/9 large), > 2553031096 bytes allocated (37243126 wasted) in 623293 chunks, > 623301 cleanups, 10819688 in recyclebin 0 29842 37070 0 21837 19073 > 27919 0 22414 25163 24075 0 704 815 720 0 32 152 160 0 45 49 52 0 > 36 42 51 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 reading updates to database [Then nothing, until we > kill the process] > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 11124 nsd 25 0 2496m 2.4g 256 R 100.0 7.7 11:27.74 nsd > 11295 root 25 0 2472m 2.4g 668 R 100.0 7.6 8:11.07 > nsd-patch > > (With 3.2.8, it takes only 2-3 minutes on the same machine) > > 4) Downgrading to 3.2.8, everything works fine again. > _______________________________________________ nsd-users mailing > list nsd-users at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/nsd-users-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPVNItAAoJEJ9vHC1+BF+NU0MP/RSQba6gOsh+sxIiJ97m/Wed CQnW8PxrHcBH4xMb2Ao+tY4HIuHC2/Lu8WsHXbMebEAbAdl9CLfYsNamraOEJFyy TmJ2Sa7n9ipTMBEwT36uqZLwoeEpy4F2D6YtGuxuZPCo+R6qaI7ajw3iGNJlQZwN Ig/GaJ9q81OS/ZOglHXuLxncAgPTje7dyelHDUoAivsM1sX67WyISilU72MGtyFj va8fqpjstaufTt8pamVlwK7gdqJ4pe+15x1lXfLfB7a5uXLpbJ7CleStgXNmUPHi z7w+AFLNfGI35LkUoVwIvB+mb/FyWzt3pPrXxG/s69aE1s8dK9c04yK7u/R92kwO 40R5s5YJbC6LlplHVtzvmGsoNQusNKYL2YLweTvxGcni7u96N1uxwzET6NtZfjSw n7MrN2PgX9rpF/R/HcpdEdNLEAE6PKlPg6r4k8pyxUQReYjAJVrNb5TlFPknTy6Q YJ9jDqCyj1eqnoeIxmFl1zDp3nBU8ixHm/dsU5NSKunuqqVkp+FnHRIAGfXWCghg VjQOtORO9Hy6TyAO9dXZKFNVyWExmhjkAOBROZmK3PweVrtiBBNOZifAd51389zl yL35cGGISozOgTRVyvbIK/wTBTI+RdcgpsGrxJmIOa3BMgWZ7cGtHX5EnR/PRIxB X7kD7hpZpiAMKtAz2Q7w =JXvz -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Stephane, We noticed a bug introduced in NSD 3.2.9 that would make zone transfers go very, very slow. This was fixed in the already released NSD 3.2.10: Bugfix #423: Fix slow zone transfer processing due to 'Fix is_existing flag for ENT' bugfix. Best regards, Matthijs On 03/05/2012 03:37 PM, Stephane Bortzmeyer wrote:> We upgraded to NSD 3.2.9 (from 3.2.8) because we encountered the > problem "Fix denial of existence response for empty non-terminal > that looks like a NSEC3-only domain (but has data below it)." (a > nasty problem with DNSSEC). But we now have IXFR issues. > > On one name server, NSD 3.2.9 works fine, zones are IXFRed and > work. > > On another name server, with much more zones (and big ones), we > deleted the databases and compiled everything again with zonec (no > problem). The server works fine but, when a zone for which it is a > slave is modified, we see the following: > > 1) Zones are transferred from the master. nsd-patch -l says: > > zone zonecheck.fr transfer id 4e4f serial 2010101202 timestamp > 1330954843.828433: seq_nr 0 of 287 bytes zone zonecheck.fr transfer > id 4e4f serial 2010101202: commit of 1 packets time Mon Mar 5 > 13:40:43 2012, from serial 2010101201, log message: xfrd: zone > zonecheck.fr received update to serial 2010101202 at time > 1330954843 from 192.134.4.2 in 1 parts > > 2) But the daemon does not take them into account (see the serial > number on ns2.nic.fr): > > % check_soa zonecheck.fr zonecheck.fr. 2010101202 (pri) > dnsmaster.nic.fr. zonecheck.fr. 2010101202 (sec) ns1.nic.fr. > zonecheck.fr. 2010101201 (sec) ns2.nic.fr. zonecheck.fr. 2010101202 > (sec) ns3.nic.fr. > > We do not see in the log the message which indicates the update. > With 3.2.8, we had: > > Mar 5 13:20:38 ns2 nsd[25255]: Zone zonecheck.fr serial 2010101200 > is updated to 2010101201. > > 3) We also observe that nsd-patch now runs endlessly: > > # nsdc patch reading database database region after loading domain > names: 20487745 objects (20487745 small/0 large), 1327521688 bytes > allocated (35924654 wasted) in 324102 chunks, 324101 cleanups, > 9631752 in recyclebin 39547 0 0 0 0 4938 14951 23553 18949 19717 > 20350 20846 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 database region after > loading database: 63529025 objects (63529016 small/9 large), > 2553031096 bytes allocated (37243126 wasted) in 623293 chunks, > 623301 cleanups, 10819688 in recyclebin 0 29842 37070 0 21837 19073 > 27919 0 22414 25163 24075 0 704 815 720 0 32 152 160 0 45 49 52 0 > 36 42 51 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > 0 0 0 0 0 0 0 reading updates to database [Then nothing, until we > kill the process] > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 11124 nsd 25 0 2496m 2.4g 256 R 100.0 7.7 11:27.74 nsd > 11295 root 25 0 2472m 2.4g 668 R 100.0 7.6 8:11.07 > nsd-patch > > (With 3.2.8, it takes only 2-3 minutes on the same machine) > > 4) Downgrading to 3.2.8, everything works fine again. > _______________________________________________ nsd-users mailing > list nsd-users at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/nsd-users-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPVNNfAAoJEA8yVCPsQCW5MrEIAK5Xt2cEYG07jpN5UB41NuOE IxG3Eqg5ymmVOnzsl9letaw0uR2D1KKTycrGK22w25sf9I4tMmXMgGX5O/rKtHIs RQ/MB8LfQu+K7qtHrghtVRCxUvY/16dEmC7nK2TmFTMcZyWrwwb41FIDr09Ip2NF O/kS++Ry0Vf5mo2KSoZuiLiTxN3gS/UDrCbxud4ie2WljJ2C/ExcYTLmzIARZWaj unIAiqbBZFdefDdSHdYmNMbV/lP/E+HTe93A/uHaskkHHttHiU6bjx4sDup/H+TO tLAAnXPDOPErLPs7xsQYiL7Png9/VvPqY3Fbh6nl7ba3H+MuHFrasRbo8VZi8IY=uC/5 -----END PGP SIGNATURE-----
On Mon, Mar 05, 2012 at 03:58:06PM +0100, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote a message of 16 lines which said:> We'll test with 3.2.10 to see.It seems to work. IXFR now works and the server serves the new data.