that uses NSEC3, named would use a uninitialised
pointer if it needed to skip a NSEC3 record because
it didn't match the selected NSEC3PARAM record for
zone. [RT# 21868]
memory conditions. Without this fix a DNS cache DB or
ADB could incorrectly stay in an over memory state,
effectively refusing further caching, which
subsequently made a BIND 9 caching server unworkable.
This fix prevents this problem from happening by
polling the state of the memory context, rather than
making a copy of the state, which appeared to cause
a race. This is a "workaround" in that it doesn't
solve the possible race per se, but several experiments
proved this change solves the symptom. Also, the
polling overhead hasn't been reported to be an issue.
This bug should only affect a caching server that
specifies a finite max-cache-size. It's also quite
likely that the bug happens only when enabling threads,
but it's not confirmed yet. [RT #21818]
support for addzone/delzone feature (see change
#2930). Removed "new-zone-file" option, replaced
with "allow-new-zones (yes|no)". The new-zone-file
for each view is now created automatically, with
a filename generated from a hash of the view name.
It is no longer necessary to "include" the
new-zone-file in named.conf; this happens
automatically. Zones that were not added via
"rndc addzone" can no longer be removed with
"rndc delzone". [RT #19447]
allow dynamic addition and deletion of zones.
To enable this feature, specify a "new-zone-file"
option at the view or options level in named.conf.
Zone configuration information for the new zones
will be written into that file. To make the new
zones persist after a restart, "include" the file
into named.conf in the appropriate view. (Note:
This feature is not yet documented, and its syntax
is expected to change.) [RT #19447]
- added LRU expiration for generated TSIGs
- added the ability to use a non-default realm
- added new "realm" keyword in nsupdate
- limited lifetime of generated keys to 1 hour
or the lifetime of the context (whichever is
smaller)
[RT #19737]
could be incorrectly marked as insecure instead of
secure leading to negative proofs failing. This was
a unintended outcome from change 2890. [RT# 21392]
