Commit Graph
42640 Commits
Author SHA1 Message Date
Colin Vidal 148a6abbc2 introduce isc_cfgmgr_foreachnodes
isc_cfgmgr_foreachnodes/foreachproperties enable to list each direct
sub-nodes/properties form within a node.

This is needed in general, and will make it easier to have a dump API
which also will be needed to make materialization testing easier.

The implementation is not great because it's likely slow (lot of LMDB
lookups and string manipulation). But at least it enables to expose the
API so we can built up on top of it, and come back to a better
implementation later.
2025-02-24 10:35:39 +01:00
Colin Vidal 80f5981de0 work in progress: Removal of nextlcause/newclause and list
newclause/nextclause API are removed as well as IDs in paths
list are removed
renaming clause->node for clarity.
2025-02-24 10:35:39 +01:00
Colin Vidal 34f9de111a Removal of builtin and inheritance
Builtin and inheritance code are removed. The way it will work now will
be specific to options, view and zone clauses. Materialization will be
used. In otherwords, 3 versions of the config co-exists:

- the builtin (the one hard-coded)
- the user (the one coming from named.conf)
- the running

The running configuration is a copy of the builtin one, and on top of
that, a copy of the user one overriding values already existing from the
builtin one. Then, each modifications applied override it.

In order to keep things simple initially, the next changes will be:

- removal of lists: the API feels brittle, it's non deterministic order
  (might be problematic), it enforces a size of values to 511 bytes, and
  it's very specific to LMDB implementation. The better approach will
  need to be found later.

- removal of "repeatable clauses" this concepts was to be able to
  iterate over views and zones, but it forces to have random IDs
  generated for clause names, which make materialization over-complex.
  (i.e. the ID for a clause "x" in the builtin wouldn't be the same in
  user or running, and would force some cotortions).

Short term: removal of newclause/nextclause, this will also break
validation. This will need to be addressed. Probably by having an extra
LMDB DB which tells the list of top-level keys from a given prefix, so
we would be able to quickly jump from one clause to another.
2025-02-24 10:35:39 +01:00
Colin Vidal 1667c015f2 revisit of builtin mode -- wip it broke part of the dump 2025-02-24 10:35:39 +01:00
Colin Vidal 0427fa417a Introduce isc_cfgmgr_dump
cfgmgr can dump its configuration. It needs to have a configuration
format (passed to isc_cfgmgr_init, also used by the validator) and a
isc_cfgmgr_dumpcfg_t struct which contains various function pointers to
dump the various clauses and properties.
2025-02-24 10:35:39 +01:00
Colin Vidal c2fe3853ef Introduce cfgmgr validator
Add validator support. The validator takes a "tree"-ish structure
describing the configuration model, composed of clauses (repeatable or
not) and properties (mandatory or not, as well as their types).

The validator walk in this structure and check for each clause if it
exists, if it is repeated (and allowed or not), if the mandatory
properties are present and what's their type.

What is not handled by the validator (and probably okay) are
non-described properties and non-described clauses (so it is possible to
add more which is not in the configuration file).
2025-02-24 10:35:39 +01:00
Colin Vidal cb07b3a8e9 Unit tests covering builtin mode
Add unit test for builtin mode logic as well as few tidy-up in the code
(adding some assertions and API documentation), in particular, to make
it clear that builtin-mode is tight to an opened clause, so it must be
set to a currently opened clause.
2025-02-24 10:35:39 +01:00
Colin Vidal 39af40afcb cfgmgr recursively lookup in parent clauses
In order to implement a generic inheritance mechanism of values,
isc_cfgmgr_getval attempts to lookup for the given name in the parent
clauses if the value is not found in the current clause.

This also introduce the notion of "builtin" mode, which enable to prefix
the builtin configuration (bin/named/config.c) with "default.", and
handle it as a specific case when the parent is a top-level clause,
effectively enabling to also support inheritance of options values to
the builtin-ones.
2025-02-24 10:35:39 +01:00
Colin Vidal d18899b589 Make cfgmgr DB optionally persistent
Environment variable NAMED_CFGMGR_PERSIST being set enable to keep LMDB
DB created by cfgmgr. For now usecase is only for debugging (i.e.
inspecting what has been actually written in the DB).
2025-02-24 10:35:39 +01:00
Colin Vidal 80e7c8bcb1 Memory tidy-up
- pack the cfgmgr type enum, so it likely takes 1 byte rather than 4
  bytes

- when putting a string in LMDB, let's allocate only the size of type +
  strlen(string) + 1, instead of the size of the whole cfgmgr_val_t +
  strlen(string) + 1. It needs a special threatment when reading, but
  probably worth it considering cfgmgr_val_t is not tiny (and will
  likely grows up)
2025-02-24 10:35:39 +01:00
Colin Vidal 349103f89c explicit transaction commit and rollback API 2025-02-24 10:35:39 +01:00
Colin Vidal 26fa21865c Revert "Copy raw OpenLDAP LMDB files"
This reverts commit 3929cbfe15.
2025-02-24 10:35:39 +01:00
Colin Vidal 58cabd2692 Revert "Various changes to integrate LMDB source files"
This reverts commit 0b5611bda7.
2025-02-24 10:35:39 +01:00
Colin Vidal e54ef084fe Various changes to integrate LMDB source files
- revert previous changes from configure.ac script in order to re-use
  the existing logic, as well as the gitlab ci flag which check build
  with two combinations.

- Conditionally build LMDB source code based on HAVE_LMDB. So if
  --without-lmdb is used, HAVE_LMDB won't be set and LMDB source code
  will be compiled and included in libisc. This enable code using LMDB
  to link no matter LMDB is OS-provided or not.

- Regarding the LMDB headers, and in order to make future LMDB update
  easier, all original OpenLDAP code is wrapped under
  lib/isc/openldap-lmdb including the headers. This avoid extra
  changes (putting aside liscence header) to mdb.c to find out its
  headers. The counter-part is the relative inclusion of this header
  from isc/lmdb.h header, but it's probably a good idea to not make
  this header public anyway.

- update LMDB license to add BIND9 SPDX headers but mentioning LMDB
  lisence
2025-02-24 10:35:39 +01:00
Colin Vidal 6f009af254 Copy raw OpenLDAP LMDB files 2025-02-24 10:35:39 +01:00
Evan HuntandColin Vidal 8957aa17a4 fixup! Makes LMDB a mandatory dependency 2025-02-24 10:35:39 +01:00
Colin Vidal 58224c138a fixup! Introduction of cfgmgr 2025-02-24 10:35:39 +01:00
Colin Vidal 80ec37daa0 fixup! Introduction of cfgmgr 2025-02-24 10:35:39 +01:00
Colin Vidal 3dd72f1e80 Move LMDB common definitions in a dedicated header
As several places uses custom LMDB macros, this centralize those
definitions inside a dedicated `lib/isc/include/isc/lmdb.h` header
file, so future uses cases not DNS-centrics could fit into there as
well.

MDB_CREATE is removed as well because:

- it was useless (it's needed only for named DB, which is not the case
  for all use case so far)

- it was used in `mdb_env_open` which is not expecting this flag: it
  should be passed (if needed) to `mdb_dbi_open`. It was likely
  ignored so far.
2025-02-24 10:35:38 +01:00
Colin Vidal f3387b8239 Makes LMDB a mandatory dependency 2025-02-24 10:34:44 +01:00
Colin Vidal eaee2de235 Add implementation doc 2025-02-24 10:33:02 +01:00
Colin Vidal 05173d890a fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal 9d780dfc33 fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal 30183e8906 fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal b394519999 fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal da16cba48a fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal 5c072afe1a fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal 7b7cdc2d6d fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal a401952850 fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal af27114a70 fixup! Introduction of cfgmgr 2025-02-24 10:33:02 +01:00
Colin Vidal e4b110559f Introduction of cfgmgr
Few points to note (and possibly discuss):

- cfgmgr is build on top of LMDB, as it brings transaction (and so
  thread safe) support out of the box

- LMDB keys are build in a way that we can support repeatable (see
  https://pad.isc.org/p/cfgmgr-proposal-v2 even if most of it is
  outdated, the section 2.0.2 about the way it's build is still
  relevant, otherwise I hope the code changes here are clear enough)

- Each thread own its own cfgmgr context (which basically means LMDB
  transaction, and where the API points to inside the configuration)

- In order to avoid allocations everytime we get/set a value (as well
  as few other operations) a single buffer is pre-allocated per-thread
  and per-transaction. Now, few internal helper functions directly use
  it (instead or, let's say, work on a parameter) and this might be
  confusing and error prone, I'm happy to change that if it is a
  worry.

- The data type which can be read/wrote from cfgmgr is not exhaustive,
  more data type will be added (i.e. duration type, uint64 if needed,
  etc.)

- This current implementation does not support inheritance (i.e. a
  non-specified view option won't use the option one). It's something
  we need to discuss, I see some options that could be put on top of
  that's here.

- The "default" values, however, should be fine out-of-the-box: I
  think the default configuration in bin/named/config.c can be
  parse/"added" in cfgmgr first then user one on top of that (because
  writting an existing value override it). Obviously there would be
  no-way to "go back" to the default config only, but I don't see such
  use case in existing code. Even if we'd need such thing, that would
  be quite invasive and a full config reload would be advisable. (so
  we could add an API to entirely drop the cfgmgr data and start from
  scratch. But I don't see such use case right now anyway, so it's not
  there)

- I hope the things a user of cfgmgr must know should be clearly
   explained in the cfgmgr.h file (if it's not the case, then I need
   to fix it -- That said I'll likely re-work the doc anyway).

- I initially implemented a mechanism which would dynamically re-size
  key buffers in case keys are very long, but I remove this as LMDB
  doesn't supports key more than 511 bytes anyway. Instead I made
  assertions every time we build a key to make sure we don't exceed
  this value.
2025-02-24 10:33:02 +01:00
Ondřej Surý 6e0c1f151c chg: dev: Move the library initialization and shutdown to executables
Instead of relying on unreliable order of execution of the library
constructors and destructors, move them to individual binaries.  The
advantage is that the execution time and order will remain constant and
will not depend on the dynamic load dependency solver.

Merge branch 'ondrej/move-the-constructors-destructors-to-binaries' into 'main'

See merge request isc-projects/bind9!10069
2025-02-22 18:06:21 +00:00
Ondřej Surý e99627a006 Suppressing memory leaks produced by clang LeakSanitizer
Previously, we were suppressing only the memory leaks in the GCC
LeakSanitizer job, but those suppression are also needed by the Clang.
2025-02-22 18:17:18 +01:00
Ondřej Surý 4917ffa61b Explicitly create and shutdown the call_rcu_thread
As the default_call_rcu_thread can't be forced to flush all the work
during the executable shutdown, create one call_rcu_thread explicitly
and assign it to the all created threads.

This allows this explicit call_rcu_thread to be unassociated from the
main thread and freed before the executable destructor exits.
2025-02-22 16:19:01 +01:00
Ondřej Surý f5c204ac3e Move the library init and shutdown to executables
Instead of relying on unreliable order of execution of the library
constructors and destructors, move them to individual binaries.  The
advantage is that the execution time and order will remain constant and
will not depend on the dynamic load dependency solver.

This requires more work, but that was mitigated by a simple requirement,
any executable using libisc and libdns, must include <isc/lib.h> and
<dns/lib.h> respectively (in this particular order).  In turn, these two
headers must not be included from within any library as they contain
inlined functions marked with constructor/destructor attributes.
2025-02-22 16:19:00 +01:00
Ondřej Surý 5d0c347e75 fix:usr: Dump the active resolver fetches from dns_resolver_dumpfetches()
Previously, active resolver fetches were only dumped when the `fetches-per-zone` configuration option was enabled. Now, active resolver fetches are dumped along with the number of `clients-per-server` counters per resolver fetch.

Merge branch 'ondrej/make-dns_resolver_dumpfetches-dump-fetches' into 'main'

See merge request isc-projects/bind9!10107
2025-02-21 21:26:18 +00:00
Ondřej Surý c6b0368b21 Dump the fetches from dns_resolver_dumpfetches()
Previously, the dns_resolver_dumpfetches() would go over the fetch
counters.  Alas, because of the earlier optimization, the fetch counters
would be increased only when fetches-per-zone was not 0, otherwise the
whole counting was skipped for performance reasons.

Instead of using the auxiliary fetch counters hash table, use the real
hash table that stores the fetch contexts to dump the ongoing fetches to
the recursing file.

Additionally print more information about the fetch context like start
and expiry times, number of fetch responses, number of queries and count
of allowed and dropped fetches.
2025-02-21 22:25:43 +01:00
Ondřej Surý 479c366c2b fix:usr: Fix the data race causing a permanent active client increase
Previously, a data race could cause a newly created fetch context for a new client to be used
before it had been fully initialized, which would cause the query to become stuck; queries for the same
data would be either paused indefinitely or dropped because of
the `clients-per-query` limit. This has been fixed.

Closes #5053

Merge branch '5053-fetch-context-create-data-race' into 'main'

See merge request isc-projects/bind9!10146
2025-02-21 21:24:56 +00:00
Ondřej Surý cf078fadeb Fix the fetch context hash table lock ordering
The order of the fetch context hash table rwlock and the individual
fetch context was reversed when calling the release_fctx() function.
This was causing a problem when iterating the hash table, and thus the
ordering has been corrected in a way that the hash table rwlock is now
always locked on the outside and the fctx lock is the interior lock.
2025-02-21 22:05:43 +01:00
Ondřej Surý b9e3cd5d2a Add isc_timer_running() function to check status of timer
In the next commit, we need to know whether the timer has been started
or stopped.  Add isc_timer_running() function that returns true if the
timer has been started.
2025-02-21 22:05:43 +01:00
Michał Kępień e127ba0041 chg: doc: Update Sphinx and sphinx_rtd_theme
Update Sphinx-related Python packages to their current versions pulled
in by "pip install sphinx-rtd-theme" run in a fresh virtual environment.

Merge branch 'michal/update-sphinx-and-sphinx_rtd_theme' into 'main'

See merge request isc-projects/bind9!10138
2025-02-21 13:47:08 +00:00
Michał Kępień eae270cc32 Update Sphinx and sphinx_rtd_theme
Update Sphinx-related Python packages to their current versions pulled
in by "pip install sphinx-rtd-theme" run in a fresh virtual environment.
2025-02-21 14:41:25 +01:00
Arаm Sаrgsyаn 5ba811bea2 fix: usr: Fix RPZ race condition during a reconfiguration
With RPZ in use, `named` could terminate unexpectedly because of a race condition when a reconfiguration command was received using `rndc`. This has been fixed.

Closes #5146

Merge branch '5146-rpz-reconfig-bug-fix' into 'main'

See merge request isc-projects/bind9!10079
2025-02-21 11:45:00 +00:00
Aram Sargsyan 3ea2fbc238 Fix RPZ bug when resuming a query during a reconfiguration
After a reconfiguration the old view can be left without a valid
'rpzs' member, because when the RPZ is not changed during the named
reconfiguration 'rpzs' "migrate" from the old view into the new
view, so when a query resumes it can find that 'qctx->view->rpzs'
is NULL which query_resume() currently doesn't expect to happen if
it's recursing and 'qctx->rpz_st' is not NULL.

Fix the issue by adding a NULL-check. In order to not split the log
message to two different log messages depending on whether
'qctx->view->rpzs' is NULL or not, change the message to not log
the RPZ policy's "version" which is just a runtime counter and is
most likely not very useful for the users.
2025-02-21 11:10:15 +00:00
Ondřej Surý 7471ef5e1a chg:nil: Cleanup the isc_counter unit
The isc_counter_create() doesn't need the return value (it was always
ISC_R_SUCCESS), use the macros to implement the reference counting,
little style cleanup, and expand the unit test.

Merge branch 'ondrej/cleanup-isc_counter-unit' into 'main'

See merge request isc-projects/bind9!10126
2025-02-21 09:51:49 +00:00
Ondřej Surý 77ec2a6c22 Cleanup the isc_counter unit
The isc_counter_create() doesn't need the return value (it was always
ISC_R_SUCCESS), use the macros to implement the reference counting,
little style cleanup, and expand the unit test.
2025-02-21 09:51:42 +00:00
Mark Andrews f0785fedf1 fix: usr: Remove NSEC/DS/NSEC3 RRSIG check from dns_message_parse
Previously, when parsing responses, named incorrectly rejected responses without matching RRSIG records for NSEC/DS/NSEC3 records in the authority section. This rejection, if appropriate, should have been left for the validator to determine and has been fixed.

Closes #5185

Merge branch '5185-remove-rrsig-check-from-dns_message_parse' into 'main'

See merge request isc-projects/bind9!10125
2025-02-21 02:57:46 +00:00
Mark Andrews 4271d93f00 Check insecure response with missing RRSIG in authority
This scenario should succeed but wasn't due rejection of the
message at the message parsing stage.
2025-02-20 20:31:07 +00:00
Mark Andrews 83159d0a54 Remove check for missing RRSIG records from getsection
Checking whether the authority section is properly signed should
be left to the validator.  Checking in getsection (dns_message_parse)
was way too early and resulted in resolution failures of lookups
that should have otherwise succeeded.
2025-02-20 20:31:07 +00:00
Arаm Sаrgsyаn d78ebff861 fix: usr: Implement sig0key-checks-limit and sig0message-checks-limit
Previously a hard-coded limitation of maximum two key or message
verification checks were introduced when checking the message's
SIG(0) signature. It was done in order to protect against possible
DoS attacks. The logic behind choosing the number 2 was that more
than a single key should only be required during key rotations, and
in that case two keys are enough. But later it became apparent that
there are other use cases too where even more keys are required, see
issue number #5050 in GitLab.

This change introduces two new configuration options for the views,
`sig0key-checks-limit` and `sig0message-checks-limit`, which define how
many keys are allowed to be checked to find a matching key, and how
many message verifications are allowed to take place once a matching
key has been found. The latter protects against expensive cryptographic
operations when there are keys with colliding tags and algorithm
numbers, with default being 2, and the former protects against a bit
less expensive key parsing operations and defaults to 16.

Closes #5050

Merge branch '5050-sig0-let-considering-more-than-two-keys' into 'main'

See merge request isc-projects/bind9!9967
2025-02-20 14:24:17 +00:00