[nsd-users] IXFR regression in nsd 3.2.9?

[Matthijs Mekking]

-----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-----