change_directory() now lives in libisccfg. when it was moved,
the logging behavior changed: previously it had been logged
by named only, in the general logging category, and without the
named.conf filename and line number. it was not logged by
named-checkconf. this behavior has now been restored.
Since the zone now has a reference to their respective configuration
tree, `rndc showzone` can be used for any zones (including those
defined in namedconf), without `allow-new-zones` being enabled.
Add a test for this.
The test is part of the addzone suite because showzone used to be
related to addzone, but this could be moved elsewhere in the future
if more specific tests are needed for showzone.
Since the `file` property of cfg_obj_t can now be null (instead of
"none"), cfg_obj_t would take a fallback flow where the line was not
logged. This fixes it.
Also, add the log line when parser_complain is called and `file` is null
(which might happend when parsing buffer only) to also include the line
number.
- several functions that can no longer fail have been changed to
type void, and unnecessary 'cleanup' sections were removed
- renamed cfg_create_obj() to cfg_obj_create(), and cfg_create_tuple()
to cfg_tuple_create(), to match typical nomenclature.
- fixed a memory leak bug, in which an element could be removed
from a list in delete_zoneconf() without being freed. this has
been addressed by adding a cfg_list_unlink() function.
list elements are now allocated based on the list they will
be stored in, using the same mctx.
- the cfg_parser_create() and cfg_parser_destroy() calls are no
longer used outside parser.c, so they are now static functions
- cfg_parser_attach(), cfg_parser_reset(), and cfg_parser_setflags()
are no longer used at all, and have been removed.
- cfg_parser_mapadd() has been renamed for clarity to cfg_map_add().
Instead of (1) allocating a parser, (2) parsing a file/buffer then (3)
freeing the parser, the parser is now internally created/destroyed from
within the `cfg_parse_*` functions. This simplifies a lot the use cases,
especially around the error cases where the parser needs to be freed in
a cleanup goto.
The only trick was the parser callback mechanism, which would previously
have been set up between steps 1 and 2. Since it's never been used for
any purpose other than the "directory" option, the chdir call has now
been moved inside the parser and the generic callback mechanism has been
removed, replacing CFG_CLAUSEFLAG_CALLBACK with CFG_CLAUSEFLAG_CHDIR.
when configuring a zone, we can now save the zone's configuration
object in the zone itself by calling dns_zone_setcfg(). this can
then be used by "rndc showzone" to print the zone's configuration,
which is simpler than searching for it using the new-zones
configuration, and allows it to work even if "allow-new-zones"
is disabled.
Remove all global cfg_parser objects as well as shared parsers between
views to dynamically add zones. Instead, parser are transirently created
whenever needed.
Remove the global named defaults parser. Instead, a parser is created
during the execution time of named_config_parsedefaults(). This
simplifies the API (no parser to pass around) and the life-cycle of the
default configuration tree (it doesn't depends on a parser instance).
cfg_obj_t doesn't store a pointer to its a parser context anymore,
and does not depend on the parser's lifecycle. Instead, it stores a
reference to its own memory context (and in principle, each node
could have different memory context). This also slightly simplifies
the _destroy API as there is no need to pass a context through it
anymore.
Add a TCP connection handler, IgnoreAllConnections that allows
establishing TCP connection but not reading anything from it.
This re-uses the horrible hack from ConnectionReset handler and might
break at any point in the future.
See the comments and e407888507 for more
details.
When generating a new key, dnssec-keygen checks for possible
key ID collisions with existing keys. The dnssec.c:findmatchingkeys()
function, which is supposed to get the list of the existing keys,
fails to do that for the existing KEY rrtype keys (i.e. generated
using 'dnssec-keygen -T KEY') because it doesn't pass down to the
dst_key_fromnamedfile() -> dst_key_read_public() functions the type
of the keys it's interested in. Fix the issue by introducing a new
function parameter which tells in which type of keys the caller is
currently interested in.
Unify the names of autouse module-wide fixtures that perform
after_servers_start() setup. The consistent naming doesn't just help
readability, but also makes it simpler for the vulture exception (since
it doesn't properly deal with autouse fixtures).
Replace the autouse fixtures which were only used to change the initial
server configuration into proper bootstrap() functions. This gets rid of
an extraneous reconfigure.
In the tests_validation_many_anchors.py, split the fixture into a proper
bootstrap() and a separate test for checking the expected log lines for
the ignored keys. Previously, the test was broken - it should check for
all the messages being present in the log, and some of the keys are
actually initial-key rather than static-key. This has been fixed in the
parametrized test.
During the system test execution, allow use of module-specific
bootstrap() function in addition to the setup.sh script which this
function should ultimately replace.
The purpose of bootstrap() is two-fold. First, it can execute any
commands needed to create the initial conditions for the test, such as
creating key materials, manipulating files etc. Second, it should return
any test-specific template values as a dictionary. Those will be used to
render the jinja2 templates.
if a zone reload is already in progress when 'rndc reload <zone>' is
run, currently the message returned in "zone reload queued", which
is correct, but it's identical to the message returned when a reload
was *not* in progress, so the user can't easily tell what happened.
a user could reload a zone twice and not realize that only one
reload actually took place.
this has been addressed by changing the message returned to
"zone reload was already queued".
a new result code ISC_R_LOADING has been added to signal this
condition, taking the place of ISC_R_RELOAD, which was obsolete
and has been removed.
One of the synthrecord system tests uses a test function to generate an
expected name based on some randomly generated IPv6 (using Hypothesis).
Turns out the test function generating the name didn't handle the case
where the label which encodes the IPv6 could have a leading or trailing
'-' character. (The plugin needs to add a leading or trailing 0 so as
not to break IDN compatibility.)
the comments in the bind.keys file were outdated; the file now only
exists to be converted into bind.keys.h and compiled into named and
delv.
some tests also referenced it, and have been cleaned up, since
the keys in it are already built into named.
You should not use dnssec-importkey to import DNSKEY records from
other providers (for example when setting up multi-signer).
Clarify this in the manpage.
With the collision avoidance on, some of the tests would occasionally
fail. None of the tests using keyfromlabel are revoking the keys so it
should be safe to disable it.
With the code handling the "tkey-gssapi-credential" statement removed,
the named_tkeyctx_fromconfig() function can no longer fail. Update its
return type to void and revise its only call site accordingly. Clean up
the function's documentation. Declare the 's' helper variable only in
the scope it is used in to improve readability.
Since the "tkey-gssapi-credential" statement has been previously
deprecated, mark it as ancient and remove all code related to it:
- The code processing the "tkey-gssapi-credential" statement in the
configuration is the only user of the dst_gssapi_acquirecred() and
dst_gssapi_releasecred() functions, so remove them along with their
static helper functions and a backup definition of the
GSS_KRB5_MECHANISM macro.
- When calling gss_accept_sec_context(), pass GSS_C_NO_CREDENTIAL
instead of the credential acquired by gss_acquire_cred().
(Previously, NULL was passed when "tkey-gssapi-credential" was not
specified. Kerberos headers define GSS_C_NO_CREDENTIAL as
(gss_cred_id_t) 0, so the logic was effectively the same, but using
the GSS_C_NO_CREDENTIAL macro is more appropriate.) This renders
the 'cred' parameter for dst_gssapi_acceptctx() redundant, so remove
it from the prototype of the latter. (Contrary to what the
documentation for dst_gssapi_acceptctx() claims,
dst_gssapi_releasecred() does not need to subsequently be called to
free the GSS-API context; a dst_gssapi_deletectx() call in
gssapi_destroy() takes care of that when the dynamically generated
TSIG key is destroyed.)
- Remove the 'gsscred' member from struct dns_tkeyctx, along with its
related dns_gss_cred_id_t typedef.
Update the relevant sections of the ARM and code comments accordingly.
This makes the "tkey-gssapi-keytab" statement the only way to set up
GSS-TSIG in named.
Remove redundant code from bin/named/tkeyconf.c while at it.
Since the "tkey-gssapi-credential" statement is now deprecated and is
about to be removed, migrate the only system test using it ("nsupdate")
to "tkey-gssapi-keytab".
Currently, the GSS-TSIG parts of the "nsupdate" system test require
properly setting up a combination of:
- "tkey-gssapi-credential" statements in named.conf files,
- the KRB5_KTNAME environment variable.
Specifically, this configuration causes named startup to include
acquiring the credential that GSS-API is allowed to match keys against
from a keytab file specified by the KRB5_KTNAME environment variable.
By contrast, the revised configuration uses the "tkey-gssapi-keytab"
statement, which makes GSS-API match keys against any credential present
in the specified keytab file.
Since both keytabs in question (ns9/dns.keytab, ns10/dns.keytab) only
contain a single credential, the two configurations are functionally
equivalent, with the revised one being significantly more readable and
simpler to prepare.
bin/tests/system/synthrecord/tests_synthrecord.py imports hypothesis
before importing isctest.hypothesis, which causes the "synthrecord"
system test to fail on platforms on which the Hypothesis module is not
available. Reorganize Python imports in tests_synthrecord.py to fix the
above issue and also to make it more in line with other similar test
scripts.
The type `ns_pluginregister_ctx_t` was initially added to pass plugin
contextual data when the plugin is registered, but this is also now
passed into `plugin_check`. Furthermore, those various data are not
specific to the registration in particular. Rename the type into
`ns_pluginctx_t` for clarity.
The "origin" parameter for synthrecord is now mandatory for reverse
zones, but when configured in a non-reverse zone, it will default to
the zone name.
the plugin's operating mode is now determined automatically
from the zone name: if the name ends in "ip6.arpa" or "in-addr.arpa",
then the plugin is in reverse mode, otherwise forward.
Add system tests for the dynamically synthesized record plugin. This
covers the various cases the plugin should handle: generating a PTR
record only when (1) no answer is found locally and (2) the IP address
extracted from the query name is part of an allowed network. This also
covered the cases of forward synthesized records; answering a A/AAAA/ANY
query from a PTR address when this match the prefix, ACL and origin.
Add a BIND9 plugin which, in "reverse" mode, enables the server to build
a synthesized response to a PTR query when the PTR record requested is
not found in the zone. (The plugin won't be called for names below a
delegation point, because it couldn't know whether a name actually
exists within the delegation.)
The dynamically-built name is constructed from a static prefix (passed
as a plugin parameter), the IP address (extracted from the query name)
and a suffx (also passed as a plugin parameter). An "allow-synth"
address-match list is used to limit the network addresses for which
the plugin may generate responses.
The plugin can also be used in "forward" mode, to build synthesized
A/AAAA records from names using the same format as he dynamically-built
PTR names, if the query name and type are not found in the zone.
The same parameters are used when the plugin is in forward mode:
the plugin will react and answer a query if the name matches the
configured prefix and origin, and encodes an IP address that is
within "allow-synth".
This commit introduces a new type, ns_pluginregister_ctx_t,
which is passed to plugin_check() and plugin_register() in place of the
'source' parameter. The source value is now just part of the structure,
which also holds a pointer to the zone origin if the plugin is loaded at
a zone level.
This provides more contextual information, enabling the plugin to make
specific configuration decisions based on the name of the zone for which
it is loaded.
It's also flexible if more contextual data are needed in the future:
add a new field to ns_pluginregister_ctx_t, and new plugins can use
it without affecting compatibility with existing plugins.
In named_config_parsefile(), when checking the validity of
named.conf, the checking of plugin correctness was deliberately
postponed until the plugin is loaded and registered. However,
when the plugin was registered, the checking was never actually
done: the plugin_register() implementation was called, but
plugin_check() was not.
This made it necessary to duplicate the correctness checking in both
functions, so that both named-checkconf and named could catch errors.
That should not be required.
ns_plugin_register() now calls the check function before the register
function, and aborts if either one fails. ns_plugin_check() calls only
the check function. ns_plugin_check() is used by named-checkconf, and
ns_plugin_register() is used by named. (Note: this design has a
side effect that a call to ns_plugin_register() will result in the
plugin parameters being parsed twice at registration time.)
ns_plugin_check() now takes an additional argument for the hook
source: zone or view.
Adds a log-based test ensuring that when a reconfiguration fails inside
the view configuration, the newly created view are always detached
before the exclusive mode is ended.
When a re-configuration fails, `apply_configuration` flows jump to a
cleanup label and, at some point, leave the exclusive mode and cleanup
the viewlist. It looks fine as the viewlist is at this point only
locally known (if this is a configuration failure, this is the new view
list, if this is a success, this is the old list which has been swapped
out from the production list during the exclusive mode).
However, the view and zone initialization code enqueues job callbacks,
for instance from `dns_zone_setsigninginterval` (but there are others
cases) which will be called for the new views and zones after the
exclusive mode is over.
Depending where the configuration fails, those views and zones can be
half-configured, for instance a view might have an unfrozen resolver.
Hence, leaving the exclusive mode before cleaning up those views ans
zones will immediately called the previously enqueued callbacks and lead
to this reconfiguration-failure crash stack:
```
isc_assertion_failed
dns_resolver_createfetch
do_keyfetch
isc__async_cb
...
uv_run
loop_thread
thread_body
thread_run
start_thread
...
```
To avoid the problem, the views are now cleaned up before leaving the
exclusive mode (which also clean up the zones and enqueued callbacks).
As context, the bug was introduced by !10910 which moved the creation
(not configuration) of the view outsides of the exclusive mode. This is
a safe move (as at this point, the newly view are only known locally by
`apply_configuration`) but the re-order was wrong regarding the point
where the exclusive mode was ended (before the change, the exclusive
mode as always ended before the new view are detached).
