9.9.1-P2

7 files changed, 137 insertions, 830 deletions

diff --git a/CHANGES b/CHANGES
index bc17c8da..2bf9dd00 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,18 @@
+	--- 9.9.1-P2 released ---
+
+3349.	[bug]		Change #3345 was incomplete. [RT #30233]
+
+3346.	[security]	Bad-cache data could be used before it was
+			initialized, causing an assert. [RT #30025]
+
+3345.	[bug]		Addressed race condition when removing the last item
+			or inserting the first item in an ISC_QUEUE.
+			[RT #29539]
+
+3342.	[bug]		Change #3314 broke saving of stub zones to disk
+			resulting in excessive cpu usage in some cases.
+			[RT #29952]
+
 	--- 9.9.1-P1 released ---
 
 3331.	[security]	dns_rdataslab_fromrdataset could produce bad
diff --git a/bin/tests/system/stub/tests.sh b/bin/tests/system/stub/tests.sh
index d61a2190..ec589c2c 100644
--- a/bin/tests/system/stub/tests.sh
+++ b/bin/tests/system/stub/tests.sh
@@ -21,14 +21,24 @@ SYSTEMTESTTOP=..
 . $SYSTEMTESTTOP/conf.sh
 
 status=0
+echo "I:check that the stub zone has been saved to disk"
+for i in 1 2 3 4 5 6 7 8 9 20
+do
+	[ -f ns3/child.example.st ] && break
+	sleep 1
+done
+[ -f ns3/child.example.st ] || { status=1;  echo "I:failed"; }
+
+for pass in 1 2
+do
 
-echo "I:trying an axfr that should be denied (NOTAUTH)"
+echo "I:trying an axfr that should be denied (NOTAUTH) (pass=$pass)"
 ret=0
-$DIG +tcp data.child.example. @10.53.0.3 axfr -p 5300 > dig.out.ns3 || ret=1
+$DIG +tcp child.example. @10.53.0.3 axfr -p 5300 > dig.out.ns3 || ret=1
 grep "; Transfer failed." dig.out.ns3 > /dev/null || ret=1
 [ $ret = 0 ] || { status=1;  echo "I:failed"; }
 
-echo "I:look for stub zone data without recursion (should not be found)"
+echo "I:look for stub zone data without recursion (should not be found) (pass=$pass)"
 for i in 1 2 3 4 5 6 7 8 9
 do
 	ret=0
@@ -41,11 +51,20 @@ done
 $PERL ../digcomp.pl knowngood.dig.out.norec dig.out.ns3 || ret=1
 [ $ret = 0 ] || { status=1;  echo "I:failed"; }
 
-echo "I:look for stub zone data with recursion (should be found)"
+echo "I:look for stub zone data with recursion (should be found) (pass=$pass)"
 ret=0
 $DIG +tcp data.child.example. @10.53.0.3 txt -p 5300 > dig.out.ns3 || ret=1
 $PERL ../digcomp.pl knowngood.dig.out.rec dig.out.ns3 || ret=1
 [ $ret = 0 ] || { status=1;  echo "I:failed"; }
 
+[ $pass = 1 ] && {
+	echo "I:stopping stub server"
+	$PERL $SYSTEMTESTTOP/stop.pl . ns3
+
+	echo "I:re-starting stub server"
+	$PERL $SYSTEMTESTTOP/start.pl --noclean --restart . ns3
+}
+done
+
 echo "I:exit status: $status"
 exit $status
diff --git a/contrib/zkt/doc/rfc5011.txt b/contrib/zkt/doc/rfc5011.txt
deleted file mode 100644
index 42235e97..00000000
--- a/contrib/zkt/doc/rfc5011.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. StJohns
-Request for Comments: 5011                                   Independent
-Category: Standards Track                                 September 2007
-
-
-        Automated Updates of DNS Security (DNSSEC) Trust Anchors
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document describes a means for automated, authenticated, and
-   authorized updating of DNSSEC "trust anchors".  The method provides
-   protection against N-1 key compromises of N keys in the trust point
-   key set.  Based on the trust established by the presence of a current
-   anchor, other anchors may be added at the same place in the
-   hierarchy, and, ultimately, supplant the existing anchor(s).
-
-   This mechanism will require changes to resolver management behavior
-   (but not resolver resolution behavior), and the addition of a single
-   flag bit to the DNSKEY record.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 1]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-      1.1. Compliance Nomenclature ....................................3
-   2. Theory of Operation .............................................3
-      2.1. Revocation .................................................4
-      2.2. Add Hold-Down ..............................................4
-      2.3. Active Refresh .............................................5
-      2.4. Resolver Parameters ........................................6
-           2.4.1. Add Hold-Down Time ..................................6
-           2.4.2. Remove Hold-Down Time ...............................6
-           2.4.3. Minimum Trust Anchors per Trust Point ...............6
-   3. Changes to DNSKEY RDATA Wire Format .............................6
-   4. State Table .....................................................6
-      4.1. Events .....................................................7
-      4.2. States .....................................................7
-   5. Trust Point Deletion ............................................8
-   6. Scenarios - Informative .........................................9
-      6.1. Adding a Trust Anchor ......................................9
-      6.2. Deleting a Trust Anchor ....................................9
-      6.3. Key Roll-Over .............................................10
-      6.4. Active Key Compromised ....................................10
-      6.5. Stand-by Key Compromised ..................................10
-      6.6. Trust Point Deletion ......................................10
-   7. IANA Considerations ............................................11
-   8. Security Considerations ........................................11
-      8.1. Key Ownership vs. Acceptance Policy .......................11
-      8.2. Multiple Key Compromise ...................................12
-      8.3. Dynamic Updates ...........................................12
-   9. Normative References ...........................................12
-   10. Informative References ........................................12
-
-1.  Introduction
-
-   As part of the reality of fielding DNSSEC (Domain Name System
-   Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
-   come to the realization that there will not be one signed name space,
-   but rather islands of signed name spaces each originating from
-   specific points (i.e., 'trust points') in the DNS tree.  Each of
-   those islands will be identified by the trust point name, and
-   validated by at least one associated public key.  For the purpose of
-   this document, we'll call the association of that name and a
-   particular key a 'trust anchor'.  A particular trust point can have
-   more than one key designated as a trust anchor.
-
-   For a DNSSEC-aware resolver to validate information in a DNSSEC
-   protected branch of the hierarchy, it must have knowledge of a trust
-   anchor applicable to that branch.  It may also have more than one
-
-
-
-StJohns                     Standards Track                     [Page 2]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   trust anchor for any given trust point.  Under current rules, a chain
-   of trust for DNSSEC-protected data that chains its way back to ANY
-   known trust anchor is considered 'secure'.
-
-   Because of the probable balkanization of the DNSSEC tree due to
-   signing voids at key locations, a resolver may need to know literally
-   thousands of trust anchors to perform its duties (e.g., consider an
-   unsigned ".COM").  Requiring the owner of the resolver to manually
-   manage these many relationships is problematic.  It's even more
-   problematic when considering the eventual requirement for key
-   replacement/update for a given trust anchor.  The mechanism described
-   herein won't help with the initial configuration of the trust anchors
-   in the resolvers, but should make trust point key
-   replacement/rollover more viable.
-
-   As mentioned above, this document describes a mechanism whereby a
-   resolver can update the trust anchors for a given trust point, mainly
-   without human intervention at the resolver.  There are some corner
-   cases discussed (e.g., multiple key compromise) that may require
-   manual intervention, but they should be few and far between.  This
-   document DOES NOT discuss the general problem of the initial
-   configuration of trust anchors for the resolver.
-
-1.1.  Compliance Nomenclature
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in BCP 14, [RFC2119].
-
-2.  Theory of Operation
-
-   The general concept of this mechanism is that existing trust anchors
-   can be used to authenticate new trust anchors at the same point in
-   the DNS hierarchy.  When a zone operator adds a new SEP key (i.e., a
-   DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
-   2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
-   validated by an existing trust anchor, then the resolver can add the
-   new key to its set of valid trust anchors for that trust point.
-
-   There are some issues with this approach that need to be mitigated.
-   For example, a compromise of one of the existing keys could allow an
-   attacker to add their own 'valid' data.  This implies a need for a
-   method to revoke an existing key regardless of whether or not that
-   key is compromised.  As another example, assuming a single key
-   compromise, we need to prevent an attacker from adding a new key and
-   revoking all the other old keys.
-
-
-
-
-
-StJohns                     Standards Track                     [Page 3]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-2.1.  Revocation
-
-   Assume two trust anchor keys A and B.  Assume that B has been
-   compromised.  Without a specific revocation bit, B could invalidate A
-   simply by sending out a signed trust point key set that didn't
-   contain A.  To fix this, we add a mechanism that requires knowledge
-   of the private key of a DNSKEY to revoke that DNSKEY.
-
-   A key is considered revoked when the resolver sees the key in a
-   self-signed RRSet and the key has the REVOKE bit (see Section 7
-   below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
-   NOT use this key as a trust anchor or for any other purpose except to
-   validate the RRSIG it signed over the DNSKEY RRSet specifically for
-   the purpose of validating the revocation.  Unlike the 'Add' operation
-   below, revocation is immediate and permanent upon receipt of a valid
-   revocation at the resolver.
-
-   A self-signed RRSet is a DNSKEY RRSet that contains the specific
-   DNSKEY and for which there is a corresponding validated RRSIG record.
-   It's not a special DNSKEY RRSet, just a way of describing the
-   validation requirements for that RRSet.
-
-   N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
-   than one without the bit set.  This affects the matching of a DNSKEY
-   to DS records in the parent [RFC3755], or the fingerprint stored at a
-   resolver used to configure a trust point.
-
-   In the given example, the attacker could revoke B because it has
-   knowledge of B's private key, but could not revoke A.
-
-2.2.  Add Hold-Down
-
-   Assume two trust point keys A and B.  Assume that B has been
-   compromised.  An attacker could generate and add a new trust anchor
-   key C (by adding C to the DNSKEY RRSet and signing it with B), and
-   then invalidate the compromised key.  This would result in both the
-   attacker and owner being able to sign data in the zone and have it
-   accepted as valid by resolvers.
-
-   To mitigate but not completely solve this problem, we add a hold-down
-   time to the addition of the trust anchor.  When the resolver sees a
-   new SEP key in a validated trust point DNSKEY RRSet, the resolver
-   starts an acceptance timer, and remembers all the keys that validated
-   the RRSet.  If the resolver ever sees the DNSKEY RRSet without the
-   new key but validly signed, it stops the acceptance process for that
-   key and resets the acceptance timer.  If all of the keys that were
-
-
-
-
-
-StJohns                     Standards Track                     [Page 4]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   originally used to validate this key are revoked prior to the timer
-   expiring, the resolver stops the acceptance process and resets the
-   timer.
-
-   Once the timer expires, the new key will be added as a trust anchor
-   the next time the validated RRSet with the new key is seen at the
-   resolver.  The resolver MUST NOT treat the new key as a trust anchor
-   until the hold-down time expires AND it has retrieved and validated a
-   DNSKEY RRSet after the hold-down time that contains the new key.
-
-   N.B.: Once the resolver has accepted a key as a trust anchor, the key
-   MUST be considered a valid trust anchor by that resolver until
-   explicitly revoked as described above.
-
-   In the given example, the zone owner can recover from a compromise by
-   revoking B and adding a new key D and signing the DNSKEY RRSet with
-   both A and B.
-
-   The reason this does not completely solve the problem has to do with
-   the distributed nature of DNS.  The resolver only knows what it sees.
-   A determined attacker who holds one compromised key could keep a
-   single resolver from realizing that the key had been compromised by
-   intercepting 'real' data from the originating zone and substituting
-   their own (e.g., using the example, signed only by B).  This is no
-   worse than the current situation assuming a compromised key.
-
-2.3.  Active Refresh
-
-   A resolver that has been configured for an automatic update of keys
-   from a particular trust point MUST query that trust point (e.g., do a
-   lookup for the DNSKEY RRSet and related RRSIG records) no less often
-   than the lesser of 15 days, half the original TTL for the DNSKEY
-   RRSet, or half the RRSIG expiration interval and no more often than
-   once per hour.  The expiration interval is the amount of time from
-   when the RRSIG was last retrieved until the expiration time in the
-   RRSIG.  That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
-   1/2*RRSigExpirationInterval))
-
-   If the query fails, the resolver MUST repeat the query until
-   satisfied no more often than once an hour and no less often than the
-   lesser of 1 day, 10% of the original TTL, or 10% of the original
-   expiration interval.  That is, retryTime = MAX (1 hour, MIN (1 day,
-   .1 * origTTL, .1 * expireInterval)).
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 5]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-2.4.  Resolver Parameters
-
-2.4.1.  Add Hold-Down Time
-
-   The add hold-down time is 30 days or the expiration time of the
-   original TTL of the first trust point DNSKEY RRSet that contained the
-   new key, whichever is greater.  This ensures that at least two
-   validated DNSKEY RRSets that contain the new key MUST be seen by the
-   resolver prior to the key's acceptance.
-
-2.4.2.  Remove Hold-Down Time
-
-   The remove hold-down time is 30 days.  This parameter is solely a key
-   management database bookeeping parameter.  Failure to remove
-   information about the state of defunct keys from the database will
-   not adversely impact the security of this protocol, but may end up
-   with a database cluttered with obsolete key information.
-
-2.4.3.  Minimum Trust Anchors per Trust Point
-
-   A compliant resolver MUST be able to manage at least five SEP keys
-   per trust point.
-
-3.  Changes to DNSKEY RDATA Wire Format
-
-   Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
-   If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
-   signed by the associated key, then the resolver MUST consider this
-   key permanently invalid for all purposes except for validating the
-   revocation.
-
-4.  State Table
-
-   The most important thing to understand is the resolver's view of any
-   key at a trust point.  The following state table describes this view
-   at various points in the key's lifetime.  The table is a normative
-   part of this specification.  The initial state of the key is 'Start'.
-   The resolver's view of the state of the key changes as various events
-   occur.
-
-   This is the state of a trust-point key as seen from the resolver.
-   The column on the left indicates the current state.  The header at
-   the top shows the next state.  The intersection of the two shows the
-   event that will cause the state to transition from the current state
-   to the next.
-
-
-
-
-
-
-StJohns                     Standards Track                     [Page 6]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-                             NEXT STATE
-           --------------------------------------------------
-    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
-   ----------------------------------------------------------
-   Start   |       |NewKey  |       |       |       |       |
-   ----------------------------------------------------------
-   AddPend |KeyRem |        |AddTime|       |       |       |
-   ----------------------------------------------------------
-   Valid   |       |        |       |KeyRem |Revbit |       |
-   ----------------------------------------------------------
-   Missing |       |        |KeyPres|       |Revbit |       |
-   ----------------------------------------------------------
-   Revoked |       |        |       |       |       |RemTime|
-   ----------------------------------------------------------
-   Removed |       |        |       |       |       |       |
-   ----------------------------------------------------------
-
-                           State Table
-
-4.1.  Events
-
-   NewKey   The resolver sees a valid DNSKEY RRSet with a new SEP key.
-            That key will become a new trust anchor for the named trust
-            point after it's been present in the RRSet for at least 'add
-            time'.
-
-   KeyPres  The key has returned to the valid DNSKEY RRSet.
-
-   KeyRem   The resolver sees a valid DNSKEY RRSet that does not contain
-            this key.
-
-   AddTime  The key has been in every valid DNSKEY RRSet seen for at
-            least the 'add time'.
-
-   RemTime  A revoked key has been missing from the trust-point DNSKEY
-            RRSet for sufficient time to be removed from the trust set.
-
-   RevBit   The key has appeared in the trust anchor DNSKEY RRSet with
-            its "REVOKED" bit set, and there is an RRSig over the DNSKEY
-            RRSet signed by this key.
-
-4.2.  States
-
-   Start    The key doesn't yet exist as a trust anchor at the resolver.
-            It may or may not exist at the zone server, but either
-            hasn't yet been seen at the resolver or was seen but was
-            absent from the last DNSKEY RRSet (e.g., KeyRem event).
-
-
-
-
-StJohns                     Standards Track                     [Page 7]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   AddPend  The key has been seen at the resolver, has its 'SEP' bit
-            set, and has been included in a validated DNSKEY RRSet.
-            There is a hold-down time for the key before it can be used
-            as a trust anchor.
-
-   Valid    The key has been seen at the resolver and has been included
-            in all validated DNSKEY RRSets from the time it was first
-            seen through the hold-down time.  It is now valid for
-            verifying RRSets that arrive after the hold-down time.
-            Clarification: The DNSKEY RRSet does not need to be
-            continuously present at the resolver (e.g., its TTL might
-            expire).  If the RRSet is seen and is validated (i.e.,
-            verifies against an existing trust anchor), this key MUST be
-            in the RRSet, otherwise a 'KeyRem' event is triggered.
-
-   Missing  This is an abnormal state.  The key remains a valid trust-
-            point key, but was not seen at the resolver in the last
-            validated DNSKEY RRSet.  This is an abnormal state because
-            the zone operator should be using the REVOKE bit prior to
-            removal.
-
-   Revoked  This is the state a key moves to once the resolver sees an
-            RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
-            contains this key with its REVOKE bit set to '1'.  Once in
-            this state, this key MUST permanently be considered invalid
-            as a trust anchor.
-
-   Removed  After a fairly long hold-down time, information about this
-            key may be purged from the resolver.  A key in the removed
-            state MUST NOT be considered a valid trust anchor.  (Note:
-            this state is more or less equivalent to the "Start" state,
-            except that it's bad practice to re-introduce previously
-            used keys -- think of this as the holding state for all the
-            old keys for which the resolver no longer needs to track
-            state.)
-
-5.  Trust Point Deletion
-
-   A trust point that has all of its trust anchors revoked is considered
-   deleted and is treated as if the trust point was never configured.
-   If there are no superior configured trust points, data at and below
-   the deleted trust point are considered insecure by the resolver.  If
-   there ARE superior configured trust points, data at and below the
-   deleted trust point are evaluated with respect to the superior trust
-   point(s).
-
-   Alternately, a trust point that is subordinate to another configured
-   trust point MAY be deleted by a resolver after 180 days, where such a
-
-
-
-StJohns                     Standards Track                     [Page 8]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   subordinate trust point validly chains to a superior trust point.
-   The decision to delete the subordinate trust anchor is a local
-   configuration decision.  Once the subordinate trust point is deleted,
-   validation of the subordinate zone is dependent on validating the
-   chain of trust to the superior trust point.
-
-6.  Scenarios - Informative
-
-   The suggested model for operation is to have one active key and one
-   stand-by key at each trust point.  The active key will be used to
-   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
-   RRSet, but the resolver will accept it as a trust anchor if/when it
-   sees the signature on the trust point DNSKEY RRSet.
-
-   Since the stand-by key is not in active signing use, the associated
-   private key may (and should) be provided with additional protections
-   not normally available to a key that must be used frequently (e.g.,
-   locked in a safe, split among many parties, etc).  Notionally, the
-   stand-by key should be less subject to compromise than an active key,
-   but that will be dependent on operational concerns not addressed
-   here.
-
-6.1.  Adding a Trust Anchor
-
-   Assume an existing trust anchor key 'A'.
-
-   1.  Generate a new key pair.
-
-   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
-       Key bits.
-
-   3.  Add the DNSKEY to the RRSet.
-
-   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
-       'A'.
-
-   5.  Wait for various resolvers' timers to go off and for them to
-       retrieve the new DNSKEY RRSet and signatures.
-
-   6.  The new trust anchor will be populated at the resolvers on the
-       schedule described by the state table and update algorithm -- see
-       Sections 2 and 4 above.
-
-6.2.  Deleting a Trust Anchor
-
-   Assume existing trust anchors 'A' and 'B' and that you want to revoke
-   and delete 'A'.
-
-
-
-
-StJohns                     Standards Track                     [Page 9]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   1.  Set the revocation bit on key 'A'.
-
-   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.  'A' is now revoked.
-       The operator should include the revoked 'A' in the RRSet for at
-       least the remove hold-down time, but then may remove it from the
-       DNSKEY RRSet.
-
-6.3.  Key Roll-Over
-
-   Assume existing keys A and B. 'A' is actively in use (i.e. has been
-   signing the DNSKEY RRSet).  'B' was the stand-by key. (i.e. has been
-   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
-   used to sign the RRSet).
-
-      1.  Generate a new key pair 'C'.
-      2.  Add 'C' to the DNSKEY RRSet.
-      3.  Set the revocation bit on key 'A'.
-      4.  Sign the RRSet with 'A' and 'B'.
-
-   'A' is now revoked, 'B' is now the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  The operator should include
-   the revoked 'A' in the RRSet for at least the remove hold-down time,
-   but may then remove it from the DNSKEY RRSet.
-
-6.4.  Active Key Compromised
-
-   This is the same as the mechanism for Key Roll-Over (Section 6.3)
-   above, assuming 'A' is the active key.
-
-6.5.  Stand-by Key Compromised
-
-   Using the same assumptions and naming conventions as Key Roll-Over
-   (Section 6.3) above:
-
-      1.  Generate a new key pair 'C'.
-      2.  Add 'C' to the DNSKEY RRSet.
-      3.  Set the revocation bit on key 'B'.
-      4.  Sign the RRSet with 'A' and 'B'.
-
-   'B' is now revoked, 'A' remains the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  'B' should continue to be
-   included in the RRSet for the remove hold-down time.
-
-6.6.  Trust Point Deletion
-
-   To delete a trust point that is subordinate to another configured
-   trust point (e.g., example.com to .com) requires some juggling of the
-   data.  The specific process is:
-
-
-
-StJohns                     Standards Track                    [Page 10]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-   1.  Generate a new DNSKEY and DS record and provide the DS record to
-       the parent along with DS records for the old keys.
-
-   2.  Once the parent has published the DSs, add the new DNSKEY to the
-       RRSet and revoke ALL of the old keys at the same time, while
-       signing the DNSKEY RRSet with all of the old and new keys.
-
-   3.  After 30 days, stop publishing the old, revoked keys and remove
-       any corresponding DS records in the parent.
-
-   Revoking the old trust-point keys at the same time as adding new keys
-   that chain to a superior trust prevents the resolver from adding the
-   new keys as trust anchors.  Adding DS records for the old keys avoids
-   a race condition where either the subordinate zone becomes unsecure
-   (because the trust point was deleted) or becomes bogus (because it
-   didn't chain to the superior zone).
-
-7.  IANA Considerations
-
-   The IANA has assigned a bit in the DNSKEY flags field (see Section 7
-   of [RFC4034]) for the REVOKE bit (8).
-
-8.  Security Considerations
-
-   In addition to the following sections, see also Theory of Operation
-   above (Section 2) and especially Section 2.2 for related discussions.
-
-   Security considerations for trust anchor rollover not specific to
-   this protocol are discussed in [RFC4986].
-
-8.1.  Key Ownership vs. Acceptance Policy
-
-   The reader should note that, while the zone owner is responsible for
-   creating and distributing keys, it's wholly the decision of the
-   resolver owner as to whether to accept such keys for the
-   authentication of the zone information.  This implies the decision to
-   update trust-anchor keys based on trusting a current trust-anchor key
-   is also the resolver owner's decision.
-
-   The resolver owner (and resolver implementers) MAY choose to permit
-   or prevent key status updates based on this mechanism for specific
-   trust points.  If they choose to prevent the automated updates, they
-   will need to establish a mechanism for manual or other out-of-band
-   updates, which are outside the scope of this document.
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 11]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-8.2.  Multiple Key Compromise
-
-   This scheme permits recovery as long as at least one valid trust-
-   anchor key remains uncompromised, e.g., if there are three keys, you
-   can recover if two of them are compromised.  The zone owner should
-   determine their own level of comfort with respect to the number of
-   active, valid trust anchors in a zone and should be prepared to
-   implement recovery procedures once they detect a compromise.  A
-   manual or other out-of-band update of all resolvers will be required
-   if all trust-anchor keys at a trust point are compromised.
-
-8.3.  Dynamic Updates
-
-   Allowing a resolver to update its trust anchor set based on in-band
-   key information is potentially less secure than a manual process.
-   However, given the nature of the DNS, the number of resolvers that
-   would require update if a trust anchor key were compromised, and the
-   lack of a standard management framework for DNS, this approach is no
-   worse than the existing situation.
-
-9.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-10.  Informative References
-
-   [RFC4986]  Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
-              "Requirements Related to DNS Security (DNSSEC) Trust
-              Anchor Rollover", RFC 4986, August 2007.
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 12]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Author's Address
-
-   Michael StJohns
-   Independent
-
-   EMail: mstjohns@comcast.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 13]
-
-RFC 5011                  Trust Anchor Update             September 2007
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2007).
-
-   This document is subject to the rights, licenses and restrictions
-   contained in BCP 78, and except as set forth therein, the authors
-   retain all their rights.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
-   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
-   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
-   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-   The IETF takes no position regarding the validity or scope of any
-   Intellectual Property Rights or other rights that might be claimed to
-   pertain to the implementation or use of the technology described in
-   this document or the extent to which any license under such rights
-   might or might not be available; nor does it represent that it has
-   made any independent effort to identify any such rights.  Information
-   on the procedures with respect to rights in RFC documents can be
-   found in BCP 78 and BCP 79.
-
-   Copies of IPR disclosures made to the IETF Secretariat and any
-   assurances of licenses to be made available, or the result of an
-   attempt made to obtain a general license or permission for the use of
-   such proprietary rights by implementers or users of this
-   specification can be obtained from the IETF on-line IPR repository at
-   http://www.ietf.org/ipr.
-
-   The IETF invites any interested party to bring to its attention any
-   copyrights, patents or patent applications, or other proprietary
-   rights that may cover technology that may be required to implement
-   this standard.  Please address the information to the IETF at
-   ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                     Standards Track                    [Page 14]
-
diff --git a/lib/dns/resolver.c b/lib/dns/resolver.c
index fb50360d..20b8de47 100644
--- a/lib/dns/resolver.c
+++ b/lib/dns/resolver.c
@@ -8448,6 +8448,7 @@ dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
 			goto cleanup;
 		bad->type = type;
 		bad->hashval = hashval;
+		bad->expire = *expire;
 		isc_buffer_init(&buffer, bad + 1, name->length);
 		dns_name_init(&bad->name, NULL);
 		dns_name_copy(name, &bad->name, &buffer);
@@ -8459,8 +8460,8 @@ dns_resolver_addbadcache(dns_resolver_t *resolver, dns_name_t *name,
 		if (resolver->badcount < resolver->badhash * 2 &&
 		    resolver->badhash > DNS_BADCACHE_SIZE)
 			resizehash(resolver, &now, ISC_FALSE);
-	}
-	bad->expire = *expire;
+	} else
+		bad->expire = *expire;
  cleanup:
 	UNLOCK(&resolver->lock);
 }
diff --git a/lib/dns/zone.c b/lib/dns/zone.c
index 4451dc8c..99b540be 100644
--- a/lib/dns/zone.c
+++ b/lib/dns/zone.c
@@ -8525,13 +8525,14 @@ zone_maintenance(dns_zone_t *zone) {
 	case dns_zone_slave:
 	case dns_zone_key:
 	case dns_zone_redirect:
+	case dns_zone_stub:
 		LOCK_ZONE(zone);
 		if (zone->masterfile != NULL &&
 		    isc_time_compare(&now, &zone->dumptime) >= 0 &&
 		    DNS_ZONE_FLAG(zone, DNS_ZONEFLG_LOADED) &&
 		    DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NEEDDUMP)) {
 			dumping = was_dumping(zone);
-		} else
+		} else 
 			dumping = ISC_TRUE;
 		UNLOCK_ZONE(zone);
 		if (!dumping) {
@@ -8918,7 +8919,7 @@ zone_dump(dns_zone_t *zone, isc_boolean_t compact) {
 		goto fail;
 	}
 
-	if (compact) {
+	if (compact && zone->type != dns_zone_stub) {
 		dns_zone_t *dummy = NULL;
 		LOCK_ZONE(zone);
 		zone_iattach(zone, &dummy);
@@ -9824,7 +9825,7 @@ stub_callback(isc_task_t *task, isc_event_t *event) {
 	dns_zone_t *zone = NULL;
 	char master[ISC_SOCKADDR_FORMATSIZE];
 	char source[ISC_SOCKADDR_FORMATSIZE];
-	isc_uint32_t nscnt, cnamecnt;
+	isc_uint32_t nscnt, cnamecnt, refresh, retry, expire;
 	isc_result_t result;
 	isc_time_t now;
 	isc_boolean_t exiting = ISC_FALSE;
@@ -9972,19 +9973,32 @@ stub_callback(isc_task_t *task, isc_event_t *event) {
 	ZONEDB_LOCK(&zone->dblock, isc_rwlocktype_write);
 	if (zone->db == NULL)
 		zone_attachdb(zone, stub->db);
+	result = zone_get_from_db(zone, zone->db, NULL, NULL, NULL, &refresh,
+				  &retry, &expire, NULL, NULL);
+	if (result == ISC_R_SUCCESS) {
+		zone->refresh = RANGE(refresh, zone->minrefresh,
+				      zone->maxrefresh);
+		zone->retry = RANGE(retry, zone->minretry, zone->maxretry);
+		zone->expire = RANGE(expire, zone->refresh + zone->retry,
+				     DNS_MAX_EXPIRE);
+		DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_HAVETIMERS);
+	}
 	ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_write);
 	dns_db_detach(&stub->db);
 
-	if (zone->masterfile != NULL)
-		zone_needdump(zone, 0);
-
 	dns_message_destroy(&msg);
 	isc_event_free(&event);
 	dns_request_destroy(&zone->request);
+
 	DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_REFRESH);
+	DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_LOADED);
 	DNS_ZONE_JITTER_ADD(&now, zone->refresh, &zone->refreshtime);
 	isc_interval_set(&i, zone->expire, 0);
 	DNS_ZONE_TIME_ADD(&now, zone->expire, &zone->expiretime);
+
+	if (zone->masterfile != NULL)
+		zone_needdump(zone, 0);
+
 	zone_settimer(zone, &now);
 	goto free_stub;
 
diff --git a/lib/isc/include/isc/queue.h b/lib/isc/include/isc/queue.h
index 5bf84c52..1bc9d5b4 100644
--- a/lib/isc/include/isc/queue.h
+++ b/lib/isc/include/isc/queue.h
@@ -14,12 +14,13 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id$ */
-
 /*
  * This is a generic implementation of a two-lock concurrent queue.
  * There are built-in mutex locks for the head and tail of the queue,
  * allowing elements to be safely added and removed at the same time.
+ *
+ * NULL is "end of list"
+ * -1 is "not linked"
  */
 
 #ifndef ISC_QUEUE_H
@@ -34,67 +35,111 @@
 #define ISC_QLINK_INSIST(x) (void)0
 #endif
 
-#define ISC_QLINK(type) struct { void *next; isc_boolean_t linked; }
+#define ISC_QLINK(type) struct { void *prev, *next; }
+
 #define ISC_QLINK_INIT(elt, link) \
 	do { \
-		(elt)->link.next = (void *)(-1); \
-		(elt)->link.linked = ISC_FALSE; \
-	} while (0)
-#define ISC_QLINK_LINKED(elt, link) ((elt)->link.linked)
+		(elt)->link.next = (elt)->link.prev = (void *)(-1); \
+	} while(0)
+
+#define ISC_QLINK_LINKED(elt, link) ((void*)(elt)->link.next != (void*)(-1))
 
 #define ISC_QUEUE(type) struct { \
-	type headnode; \
 	type *head, *tail; \
 	isc_mutex_t headlock, taillock; \
 }
 
 #define ISC_QUEUE_INIT(queue, link) \
 	do { \
-		isc_mutex_init(&(queue).headlock); \
 		isc_mutex_init(&(queue).taillock); \
-		(queue).head = (void *) &((queue).headnode); \
-		(queue).tail = (void *) &((queue).headnode); \
-		ISC_QLINK_INIT((queue).head, link); \
+		isc_mutex_init(&(queue).headlock); \
+		(queue).tail = (queue).head = NULL; \
 	} while (0)
 
-#define ISC_QUEUE_EMPTY(queue) ISC_TF((queue).head == (queue).tail)
+#define ISC_QUEUE_EMPTY(queue) ISC_TF((queue).head == NULL)
 
 #define ISC_QUEUE_DESTROY(queue) \
 	do { \
 		ISC_QLINK_INSIST(ISC_QUEUE_EMPTY(queue)); \
-		isc_mutex_destroy(&(queue).headlock); \
 		isc_mutex_destroy(&(queue).taillock); \
+		isc_mutex_destroy(&(queue).headlock); \
 	} while (0)
 
+/*
+ * queues are meant to separate the locks at either end.  For best effect, that
+ * means keeping the ends separate - i.e. non-empty queues work best.
+ *
+ * a push to an empty queue has to take the pop lock to update
+ * the pop side of the queue.
+ * Popping the last entry has to take the push lock to update
+ * the push side of the queue.
+ *
+ * The order is (pop, push), because a pop is presumably in the
+ * latency path and a push is when we're done.
+ *
+ * We do an MT hot test in push to see if we need both locks, so we can
+ * acquire them in order.  Hopefully that makes the case where we get
+ * the push lock and find we need the pop lock (and have to release it) rare.
+ *
+ * > 1 entry - no collision, push works on one end, pop on the other
+ *   0 entry - headlock race
+ *     pop wins - return(NULL), push adds new as both head/tail
+ *     push wins - updates head/tail, becomes 1 entry case.
+ *   1 entry - taillock race
+ *     pop wins - return(pop) sets head/tail NULL, becomes 0 entry case
+ *     push wins - updates {head,tail}->link.next, pop updates head
+ *                 with new ->link.next and doesn't update tail
+ *
+ */
 #define ISC_QUEUE_PUSH(queue, elt, link) \
 	do { \
+		isc_boolean_t headlocked = ISC_FALSE; \
 		ISC_QLINK_INSIST(!ISC_QLINK_LINKED(elt, link)); \
-		(elt)->link.next = (void *)(-1); \
+		if ((queue).head == NULL) { \
+			LOCK(&(queue).headlock); \
+			headlocked = ISC_TRUE; \
+		} \
 		LOCK(&(queue).taillock); \
-		(queue).tail->link.next = elt; \
-		(queue).tail = elt; \
+		if ((queue).tail == NULL && !headlocked) { \
+			UNLOCK(&(queue).taillock); \
+			LOCK(&(queue).headlock); \
+			LOCK(&(queue).taillock); \
+			headlocked = ISC_TRUE; \
+		} \
+		(elt)->link.prev = (queue).tail; \
+		(elt)->link.next = NULL; \
+		if ((queue).tail != NULL) \
+			(queue).tail->link.next = (elt); \
+		(queue).tail = (elt); \
 		UNLOCK(&(queue).taillock); \
-		(elt)->link.linked = ISC_TRUE; \
+		if (headlocked) { \
+			if ((queue).head == NULL) \
+				(queue).head = (elt); \
+			UNLOCK(&(queue).headlock); \
+		} \
 	} while (0)
 
 #define ISC_QUEUE_POP(queue, link, ret) \
 	do { \
 		LOCK(&(queue).headlock); \
-		ret = (queue).head->link.next; \
-		if (ret == (void *)(-1)) { \
-			UNLOCK(&(queue).headlock); \
-			ret = NULL; \
-		} else { \
-			(queue).head->link.next = ret->link.next; \
-			if (ret->link.next == (void *)(-1)) { \
+		ret = (queue).head; \
+		while (ret != NULL) { \
+			if (ret->link.next == NULL) { \
 				LOCK(&(queue).taillock); \
-				(queue).tail = (queue).head; \
+				if (ret->link.next == NULL) { \
+					(queue).head = (queue).tail = NULL; \
+					UNLOCK(&(queue).taillock); \
+					break; \
+				}\
 				UNLOCK(&(queue).taillock); \
 			} \
-			UNLOCK(&(queue).headlock); \
-			ret->link.next = (void *)(-1); \
-			ret->link.linked = ISC_FALSE; \
+			(queue).head = ret->link.next; \
+			(queue).head->link.prev = NULL; \
+			break; \
 		} \
-	} while (0)
+		UNLOCK(&(queue).headlock); \
+		if (ret != NULL) \
+			(ret)->link.next = (ret)->link.prev = (void *)(-1); \
+	} while(0)
 
 #endif /* ISC_QUEUE_H */
diff --git a/version b/version
index 692edbe7..7718a9e6 100644
--- a/version
+++ b/version
@@ -7,4 +7,4 @@ MAJORVER=9
 MINORVER=9
 PATCHVER=1
 RELEASETYPE=-P
-RELEASEVER=1
+RELEASEVER=2