Hello LaMont, or anyone else affected, Accepted bind9 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/bind9/1:9.9.5.dfsg- 3ubuntu0.12 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Changed in: bind9 (Ubuntu Trusty) Status: New => Fix Committed ** Tags added: verification-needed ** Changed in: bind9 (Ubuntu) Status: Confirmed => Fix Released ** Changed in: bind9 (Ubuntu Trusty) Assignee: (unassigned) => LaMont Jones (lamont) -- 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 bind9 package in Ubuntu: Fix Released Status in bind9 source package in Trusty: Fix Committed 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 _______________________________________________ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : [email protected] Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
