From arekm@maven.pl Fri Jul 29 12:03:50 2016 MIME-Version: 1.0 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham autolearn_force=no version=3.4.0 Message-ID: <201607291403.41905.arekm@maven.pl> content-type: Text/Plain; charset="utf-8" X-Received: by 10.28.22.6 with SMTP id 6mr45251869wmw.55.1469793823874; Fri, 29 Jul 2016 05:03:43 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by bugs.isc.org (Postfix) with ESMTP id 998CC71B5A9 for ; Fri, 29 Jul 2016 12:03:49 +0000 (UTC) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 2F0A534950D for ; Fri, 29 Jul 2016 12:03:46 +0000 (UTC) Received: by mail-wm0-x22d.google.com with SMTP id i5so148909979wmg.0 for ; Fri, 29 Jul 2016 05:03:45 -0700 (PDT) Received: from xps.localnet ([91.234.176.247]) by smtp.gmail.com with ESMTPSA id p83sm2727996wma.18.2016.07.29.05.03.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jul 2016 05:03:42 -0700 (PDT) Delivered-To: bind9-bugs@bugs.isc.org Subject: bind 9.11.0rc3: ignores notifies that are send while refresh is in progress User-Agent: KMail/1.13.7 (Linux/4.7.0; KDE/4.14.21; x86_64; ; ) Return-Path: X-Original-To: bind9-bugs@bugs.isc.org Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maven.pl; s=maven; h=from:to:subject:date:user-agent:mime-version :content-transfer-encoding:message-id; bh=r7AAXkYP0XNpVzZ+L/q/atcx5ebCVybWp9BqWHiUeMU=; b=R+PM+NDUEvd2gOwV5LSRcMjLWzjRGHhOyzJYlnxiaAjN6a/vl/8fFmQRhUGpHvbcOH iC8Lpg9+ojML4IgJQvEYGkbIIyHbKHHTHSLnDaaJbWq92tFZSZJ0zEWNL1d/Q7REQARA Xow4Ec7gfdkcmye+f5uL1xmczyg9+/Ilm2W1g= X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:mime-version :content-transfer-encoding:message-id; bh=r7AAXkYP0XNpVzZ+L/q/atcx5ebCVybWp9BqWHiUeMU=; b=Fjg/pIy1tDUVRISwS9PmXFOhaaeDi/CqtbN8gKB/37js3bvFO2JAdDFuubcKR37XOf nh7iWb4nck/e0V9qCN9DHi+lAFaExmfEZOtPPcILVt9Z8UdLKucAhGRw5c2PEF2/X8JI TKD3Qhs8kS7DXhRbpWL8LP7C6kGL0qKhFkz5ubUFPVdwnf69hJhfI0INPmO7N3N0/uEl bxF5yB7U8T70PWDxYmaAlStJ4CMsEEACM2rdNJOy3F0eVro6ypE2wD4b5I09dKTM9ppL PnjFp7TN8wt5oE6aGYEf5kdahsLbbRGqHsA+AldEmt9flLsWScM+ZDDm9mDxx37aECNH moOQ== Date: Fri, 29 Jul 2016 14:03:41 +0200 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org To: bind-bugs@isc.org Content-Transfer-Encoding: quoted-printable X-GM-Message-State: AEkoouuKR0Ra6eCAkLBgF94oxQc0oDXMAQAMfBDmhJn0qiSqmCQCNrlnsw9HEMW0KmSDQg== From: "Arkadiusz Miśkiewicz" X-RT-Original-Encoding: utf-8 X-RT-Interface: Email Content-Length: 3037 bind 9.11.0rc3 running as slave nameserver. Primary nameserver runs 9.10.4 P2. On primary this happens (all that happens in 3 seconds): - zone data is updated, serial set to 2016072731 - primary sends notify - rndc notify test.zone.pl is called also (so second notify is send - this is unneded as first should be enough but that's how the system operates here currently) - afer 2 seconds zone data is updated again, serial set to 2016072744 - primary sends notify - rndc notify test.zone.pl is called also (so second notify is send) How secondary server sees it: 29-Jul-2016 13:13:14.695 notify: info: client 1.1.1.1#30572: received notify for zone 'test.zone.pl' 29-Jul-2016 13:13:14.695 general: info: zone test.zone.pl/IN: notify from 1.1.1.1#30572: serial 2016072731: refresh in progress, refresh check queued 29-Jul-2016 13:13:19.695 notify: info: client 1.1.1.1#30572: received notify for zone 'test.zone.pl' 29-Jul-2016 13:13:19.695 general: info: zone test.zone.pl/IN: notify from 1.1.1.1#30572: serial 2016072731: refresh in progress, refresh check queued 29-Jul-2016 13:14:33.862 general: info: zone test.zone.pl/IN: Transfer started. 29-Jul-2016 13:14:33.868 xfer-in: info: transfer of 'test.zone.pl/IN' from 1.1.1.1#53: connected using 91.2.2.2#36328 29-Jul-2016 13:14:33.875 general: info: zone test.zone.pl/IN: transferred serial 2016072731 29-Jul-2016 13:14:33.875 xfer-in: info: transfer of 'test.zone.pl/IN' from 1.1.1.1#53: Transfer status: success 29-Jul-2016 13:14:33.875 xfer-in: info: transfer of 'test.zone.pl/IN' from 1.1.1.1#53: Transfer completed: 1 messages, 24 records, 1062 bytes, 0.007 secs (151714 bytes/sec) so far good, zone with serial 2016072731 got transferred 29-Jul-2016 13:15:14.693 notify: info: client 1.1.1.1#64827: received notify for zone 'test.zone.pl' 29-Jul-2016 13:15:14.693 general: info: zone test.zone.pl/IN: notify from 1.1.1.1#64827: serial 2016072744: refresh in progress, refresh check queued here we get first notify of zone with serial 2016072744 (so bigger than previously) 29-Jul-2016 13:15:19.693 notify: info: client 1.1.1.1#64827: received notify for zone 'test.zone.pl' 29-Jul-2016 13:15:19.693 general: info: zone test.zone.pl/IN: notify from 1.1.1.1#64827: serial 2016072744: refresh in progress, refresh check queued here we got second notify (that one from rndc notify ...) with serial 2016072744 29-Jul-2016 13:16:08.208 general: info: zone test.zone.pl/IN: loaded serial 2016072731 yet bind happily ends process of loading zone with old serial 2016072731 and *no longer* refreshes zone with serial 2016072744. After that nothing new happens with the zone and after about half hour we manually forced new notify via rndc notify. In short words: if notify with new serial is delivered to secondary ns while refresh process of the same zone with older serial is in progress then bind will ignore new serial zone and will not fetch it again leaving secondary dns desynchronized from primary. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )