group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1553176@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package bind9 - 1:9.9.5.dfsg-3ubuntu0.12

---------------
bind9 (1:9.9.5.dfsg-3ubuntu0.12) trusty; urgency=medium

  * Backport (70_precise_mtime.diff) 18b87b2a58d422fe4d3073540bf89b5a812ed2e5
    to trusty. LP: #1553176

 -- LaMont Jones <lamont@xxxxxxxxxxxxx>  Fri, 03 Feb 2017 13:13:21 -0700

** Changed in: bind9 (Ubuntu Trusty)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1553176

Title:
  BIND ignores nanoseconds field in timestamps, fails to load newer
  versions of zones on reload

Status in BIND:
  Fix Released
Status in MAAS:
  Fix Released
Status in MAAS 1.9 series:
  In Progress
Status in bind9 package in Ubuntu:
  Fix Released
Status in bind9 source package in Trusty:
  Fix Released
Status in bind9 source package in Xenial:
  Fix Released

Bug description:
  Since 2.6, linux has supported nanosecond granular time in stat(2)
  returns.  BIND has a comment in the code that it might use it, but
  continues to ignore it.

  As of 9.9.3b2, named checks the time of (at least) zone files on disk
  (expanding to include include files in 9.10.0a2).  Because the check
  is only done to a granularity of seconds, changing the zone file twice
  in the same second can cause BIND to decide that it need not reload
  the zone, even though it is out of date.

  [Impact]

   * If a zone file is changed (generally by automated processes) more
  than once in a second, bind9 happily thinks it has already loaded the
  zone.  A trivial demonstration of the bug can be seen at
  paste.ubuntu.com/23921121/ -- http://paste.ubuntu.com/23921176/ is the
  same test with the fixed code.  Making this a test case is somewhat
  problematic in that it needs to make sure that they happen inside of
  the same second.

   * MAAS is exactly the sort of use case that hits this bug.

   * The upload changes BIND's utility function to actual use the
  st_mtim.tv_nsec instead of '0'.

  [Test Case]

   * See the pastebin above.  (Change a zone file and reload it, and
  then do it again less than a second later.)

  [Regression Potential]

   * Ignoring the whole "rebuilds sometimes break things", the most
  likely regression would be one where something was either relying on
  BIND not reloading the dozone (unlikely), or otherwise relying on the
  modify time on a zone file to some arbitrary value.

  [Other Info]

    This bug was fixed in 1:9.10.3.dfsg.P2-5, which landed in xenial
  March 2016.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bind/+bug/1553176/+subscriptions