The echo_*() and cat_*() functions in bin/tests/system/conf.sh.common
call the "read" builtin command without specifying the field separator
to use. This results in leading whitespace getting stripped from each
line of the texts passed to those functions, which mangles e.g. pytest
output, hindering test failure troubleshooting.
Address by setting IFS to an empty value for the "read" calls used in
the aforementioned helper functions.
(cherry picked from commit fb87022115)
The bin/tests/system/start.pl script truncates the named.run file for a
given named instance unless it is invoked with the --restart
command-line option. Ever since Python-based tests were introduced,
bin/tests/system/run.sh may start named instances used by a given system
test multiple times within a single run, causing the
bin/tests/system/start.pl script to truncate some of the log files
written during the test. This makes troubleshooting certain test
failures hard or even impossible.
Fix by calling bin/tests/system/start.pl with the --restart command-line
option for every start_servers() invocation except the first one.
(cherry picked from commit 65abbca79b)
dns_dlzcreate() fails to free the memory allocated for dlzname
when an error occurs.
Free dlzname's memory (acquired earlier with isc_mem_strdup())
by calling isc_mem_free() before returning an error code.
(cherry picked from commit 4a6c66288f)
When failure is expected, the `rndc` command in the catz system test
is being called directly instead of using a function, i.e.:
$RNDC -c ../common/rndc.conf -s 10.53.0.2 -p 9953 reconfig \
> /dev/null 2>&1 && ret=1
... instead of:
rndccmd 10.53.0.2 reconfig && ret=1
This is done to suppress messages like "lt-rndc: 'reconfig' failed:
failure" appearing in the message log of the test, because failure
is actually expected, and the appearance of that message can be
confusing.
The port value used in this case is not correct, making the
`rndc reload` command to fail. This error was not detected earlier
only because the failure of the command is actually expected, but
the failure happens for a "wrong" reason, and the test still passes.
Fix the error by using the existing variable instead of the fixed
number.
(cherry picked from commit 5f9d4b5db4)
Test the view reverting code by introducing a faulty dlz configuration
in named.conf and using `rndc reconfig` to check if named handles the
situation correctly.
We use "dlz" because the dlz processing code is located in an ideal
place in the view configuration function for the test to cover the
view reverting code.
This test is specifically added to the catz system test to additionally
cover the catz reconfiguration during the mentioned failed
reconfiguration attempt.
(cherry picked from commit 62337d433f)
When a zone is being configured with a new view, the catalog zones
structure will also be linked to that view. Later on, in case of some
error, should the zone be reverted to the previous view, the link
between the catalog zones structure and the view won't be reverted.
Change the dns_zone_setviewrevert() function so it calls
dns_zone_catz_enable() during a zone revert, which will reset the
link between `catzs` and view.
(cherry picked from commit 2fd967136a)
Separate the locked parts of dns_zone_catz_enable() and
dns_zone_catz_disable() functions into static functions. This will
let us perform those tasks from the other parts of the module while
the zone is locked, avoiding one pair of additional unlocking and
locking operations.
(cherry picked from commit 6b937ed5f6)
If a view configuration error occurs during a named reconfiguration
procedure, BIND can end up having twin views (old and new), with some
zones and internal structures attached to the old one, and others
attached to the new one, which essentially creates chaos.
Implement some additional view reverting mechanisms to avoid the
situation described above:
1. Revert rpz configuration.
2. Revert catz configuration.
3. Revert zones to view attachments.
(cherry picked from commit 3697560f04)
We started with compilation of _all_ 9.17.z notes into one file:
$ ls *.17*.rst | sort -V | xargs cat > notes-9.18.0.rst
Then removed removed duplicate extra copyright headers:
$ grep -v '^\.\. [^_]' notes-9.18.0.rst > notes-9.18.0.rst.copy
$ grep -v '^\.\.$' notes-9.18.0.rst.copy > notes-9.18.0.rst
$ vim notes-9.17.0.rst notes-9.18.0.rst
Next step was to find notes referencing the changes which were
backported to 9.16.25 and remove these. Duplicites were checked
by diffing corresponding texts in 9.16 and 9.17, and it revealed that
some backports were either partial, or code was backported but the
release note was lost in 9.16 branch. In that case we did not
re-introduce the relnote and considered it also duplicate.
Most notable cases of "missing in 9.16 relnote but in fact fixed"
were notes for CVE-2020-8616 and CVE-2020-8617.
These were accidentally omitted from 9.16 release docs, and we are going
to fix it in separate MR !5722.
Further removals include:
- Security issue #2787: The bug was introduced & fixed in 9.17.z,
so there is no need to tell about it to people upgrading to 9.18.0.
- Bugfix !3135: Backported but with unclear reference in relnotes.
- Bugfix !3137: Backported but with unclear reference in relnotes.
- Bugfix #2460: Introduced & fixed in 9.17.z.
- Bugfix #2504: The bug was introduced & fixed in 9.17.z.
- Bugfix #2562: Introduced & fixed in 9.17.z.
- Bugfix #2917: Introduced & fixed in 9.17.z
- Bugfix #3040: Introduced & fixed in 9.17.z.
- Bugfix #3062: Introduced & fixed in 9.17.z.
- Change #4: Introduced & "finished" in 9.17.z.
- Change #1610: Introduced & reverted in 9.17.z.
- Change #1958: No user visible impact.
- Change #2016: No user visible impact.
- Change #2022: No user visible impact.
- Change #2264: Affects a feature introduced only to 9.17 branch.
- Change #2401: No user visible impact.
- Known issue about libuv: Got fixed later in the cycle.
- Known issue about port clash: It is now config error.
Then tweaking started to clarify meaning of various notes to people
upgrading from 9.16.
While doing so, bugfix #2927 was omited because the change just makes
9.18 SERVFAIL faster than 9.16, so even though it is technically bugfix
it is so minor that it is not worth bragging about in release notes.
TLS/DoT/DoH features were summarized from many independent
notes into one giant note per feature.
All notes were rearranged according to their "perceived priority".
There were three RFCs listed in list of "RFCs we implement" but missing
in the ARM.
Command to compare lists in the two documents:
diff <(grep -o '^ RFC[0-9]\+' doc/misc/rfc-compliance | sed -e 's/[^0-9]//g' | sort -n) <(grep '^:rfc:`' doc/arm/general.rst | sed -e 's/^.*`\([0-9]*\)`.*$/\1/' | sort -n)
Supported Platforms section is now really only about platforms and not
libraries. Libraries were moved to the Building BIND section.
We now have section for required libraries, and second with optional
features. Wordy explanations were taken verbatim from the original
README.md.
Converted using pandoc 2.14.2-9 on Arch Linux:
$ pandoc --shift-heading-level-by=-1 -f markdown -t rst README.md > doc/arm/build.rst
Plus hand-edit to remove sections other than Building BIND 9, remove
misindentation in section headers, and add a standard copyright header.
Converted using pandoc 2.14.2-9 on Arch Linux:
$ pandoc -f markdown -t rst PLATFORMS.md > PLATFORMS.rst
The pandoc-generated copyright header was subsequently replaced with
usual one for .rst files.
On some systems, the glibc can return 0 instead of cache-line size to
indicate the cache line sizes cannot be determined. This is comment
from glibc source code:
/* In general we cannot determine these values. Therefore we
return zero which indicates that no information is
available. */
As the goal of the check is to determine whether the L1 cache line size
is still 64 and we would use this value in case the sysconf() call is
not available, we can also ignore the invalid values returned by the
sysconf() call.
As far as I can tell, it is some leftover from the times when Sphinx
docs were introduced (commit 9fb6d11abb).
It seems like it is not referenced from anywhere.
Extend the error message displayed when support for DNS over HTTPS is
requested but libnghttp2 is unavailable at build time, in order to help
the user find a way out of such a situation.
The terms "DNS over HTTPS" and "DNS over TLS" should be hyphenated when
they are used as adjectives and non-hyphenated otherwise. Ensure all
occurrences of these terms in the source tree follow the above rule.
(CHANGES and release notes are intentionally left intact.)
Tweak a related ARM snippet, fixing a typo in the process.
