In QPcache, there were two places that tried to upgrade the lock. In
clean_stale_header(), the code would try to upgrade the lock and cleanup
the header, and in qpzonode_release(), the tree lock would be optionally
upgraded, so we can cleanup the node directly if empty. These
optimizations are not needed and they have no effect on the performance.
The isc_queue_t was missing in the calculation of the required
padding size inside the qpcache bucket structure.
Merge branch 'ondrej/qpcache-fix-invalid-padding' into 'main'
See merge request isc-projects/bind9!10306
After a refactoring in 2e6107008dae09d32e3d34fb5423b3d78c4ff651 the
dst_key_free() call is invalid and can cause an assertion. Remove the
dst_key_free() call.
Merge branch 'aram/fix-ns_query-get_key-bug' into 'main'
See merge request isc-projects/bind9!10311
After a refactoring in 2e6107008dae09d32e3d34fb5423b3d78c4ff651 the
dst_key_free() call is invalid and can cause an assertion. Remove the
dst_key_free() call.
All DNSKEY keys are able to authenticate. The `DNS_KEYTYPE_NOAUTH` (and `DNS_KEYTYPE_NOCONF`) flags were defined for the KEY rdata type, and are not applicable to DNSKEY. Previously, however, because the DNSKEY implementation was built on top of KEY, the `_NOAUTH` flag prevented authentication in DNSKEYs as well. This has been corrected.
Closes#5240
Merge branch '5240-ignore-noauth-flag' into 'main'
See merge request isc-projects/bind9!10261
All DNSKEY keys are able to authenticate. The DNS_KEYTYPE_NOAUTH
(and DNS_KEYTYPE_NOCONF) flags were defined for the KEY rdata type,
and are not applicable to DNSKEY.
Previously, because the DNSKEY implementation was built on top of
KEY, the NOAUTH flag prevented authentication in DNSKEYs as well.
This has been corrected.
Use enums for DNS_KEYFLAG_, DNS_KEYTYPE_, DNS_KEYOWNER_, DNS_KEYALG_,
and DNS_KEYPROTO_ values.
Remove values that are never used.
Eliminate the obsolete DNS_KEYFLAG_SIGNATORYMASK. Instead, add three
more RESERVED bits for the key flag values that it covered but which
were never used.
This function was removed in 6217e434b57bd5d60ed69f792ae9a1a65a008f57 but not from the header file.
Merge branch 'matthijs-remove-unused-qpmulti-lockedread' into 'main'
See merge request isc-projects/bind9!10308
Replace the custom DNS server used in the "upforwd" system test with new
code based on the isctest.asyncserver module. The ans4 server currently
used in that test is a copy of bin/tests/system/ans.pl modified to
receive queries over UDP and TCP without ever responding to any of them.
Closes#5012
Merge branch '5012-upforwd-asyncserver' into 'main'
See merge request isc-projects/bind9!10283
Replace the custom DNS server used in the "upforwd" system test with new
code based on the isctest.asyncserver module. The ans4 server currently
used in that test is a copy of bin/tests/system/ans.pl modified to
receive queries over UDP and TCP without ever responding to any of them.
Dropping all incoming queries is a typical use case for a custom server
used in BIND 9 system tests. Add a response handler implementing that
behavior so that it can be reused.
Instead of requiring each class inheriting from ResponseHandler to
define its match() method, make the latter non-abstract and default to
returning True for all queries. This will reduce the amount of
boilerplate code in custom servers.
Previously, when queries were forwarded to a remote resolver, the CD (checking disabled) bit was used, which could lead to bogus data being retrieved that might have been corrected if validation had been permitted. The CD bit is now only used as a fallback if an initial query without CD fails. See #5132.
Merge branch '5132-cd-retry' into 'main'
See merge request isc-projects/bind9!10024
when sending a query to a forwarder for a name within a secure domain,
the first query is now sent with CD=0. when the forwarder itself
is validating, this will give it a chance to detect bogus data and
replace it with valid data before answering. this reduces our chances
of being stuck with data that can't be validated.
if the forwarder returns SERVFAIL to the initial query, the query
will be repeated with CD=1, to allow for the possibility that the
forwarder's validator is faulty or that the bogus answer is covered
by an NTA.
note: previously, CD=1 was only sent when the query name was in a
secure domain. today, validating servers have a trust anchor at the
root by default, so virtually all queries are in a secure domain.
therefore, the code has been simplified. as long as validation is
enabled, any forward query that receives a SERVFAIL response will be
retried with CD=1.
`dig` and `named` can now make requests with an EDNS `ZONEVERSION` option present.
Two new `named.conf` options have been added: `request-zoneversion` and
`provide-zoneversion`. `request-zoneversion` is `off` by default. `provide-zoneversion`
is `on` by default.
Closes#4767
Merge branch '4767-implement-zoneversion' into 'main'
See merge request isc-projects/bind9!9103
This can be set at the option, view and server levels and causes
named to add an EDNS ZONEVERSION option to requests. Replies are
logged to the 'zoneversion' category.
If there was an EDNS ZONEVERSION option in the DNS request and the
answer was from a zone, return the zone's serial and number of
labels excluding the root label with the type set to 0 (ZONE-SERIAL).
After !9950, respdiff's maximal disagreement percentage needs to be
adjusted as target disagreements between the tested version of the
"main" branch and the reference one jumped for the respdiff,
respdiff:asan, and respdiff:tsan jobs from on average 0.07% to 0.16% and
from 0.12% to 0.17% for the respdiff-third-party job.
In !9950, we concluded setting MAX_DISAGREEMENTS_PERCENTAGE to double
the average disagreement percentage works fine in the CI.
Merge branch 'mnowak/more-lenient-respdiff-limits' into 'main'
See merge request isc-projects/bind9!10293
After !9950, respdiff's maximal disagreement percentage needs to be
adjusted as target disagreements between the tested version of the
"main" branch and the reference one jumped for the respdiff,
respdiff:asan, and respdiff:tsan jobs from on average 0.07% to 0.16% and
from 0.12% to 0.17% for the respdiff-third-party job.
In !9950, we concluded setting MAX_DISAGREEMENTS_PERCENTAGE to double
the average disagreement percentage works fine in the CI.
Call `dns_adbname_ref` before calling `dns_resolver_createfetch` to
ensure `adbname->name` remains stable for the life of the fetch.
Closes#5239
Merge branch '5239-fix-adb-reference-counting' into 'main'
See merge request isc-projects/bind9!10290
When searching through a DNSKEY or KEY rrset for the key matching a particular algorithm and ID, it's a waste of time to convert every key into a `dst_key` object; it's faster to compute the key ID from the rdata, then do the full key conversion after determining that we've found the right key. This optimization was already used in the validator, but it's been refactored for code clarity, and is now also used in query.c and message.c.
Merge branch 'each-refactor-key-search' into 'main'
See merge request isc-projects/bind9!10258
when searching a DNSKEY or KEY rrset for the key that matches
a particular algorithm and ID, it's a waste of time to convert
every key into a dst_key object; it's faster to compute the key
ID by checksumming the region, and then only do the full key
conversion once we know we've found the correct key.
this optimization was already in use in the validator, but it's
been refactored for code clarity, and is now also used in query.c
and message.c.
dns_zonekey_iszonekey() was the only function defined in the
dns_zonekey module, and was only called from one place. it
makes more sense to group this with dns_dnssec functions.
This merge request resolves some performance regressions introduced
with the change from isc_symtab_t to isc_hashmap_t.
The key improvements are:
1. Using a faster hash function than both isc_hashmap_t and
isc_symtab_t. The previous implementation used SipHash, but the
hashflood resistance properties of SipHash are unneeded for config
parsing.
2. Shrinking the initial size of the isc_hashmap_t used inside
isc_symtab_t. Symtab is mainly used for config parsing, and the
when used that way it will have between 1 and 50 keys, but the
previous implementation initialized a map with 128 slots.
By initializing a smaller map, we speed up mallocs and optimize for
the typical case of few config keys.
3. Slight optimization of the string matching in the hashmap, so that
the tail is handled in a single load + comparison, instead of byte
by byte.
Of the three improvements, this is the least important.
Merge branch 'alessio/fxhash-symtab' into 'main'
See merge request isc-projects/bind9!10204
This merge request resolves some performance regressions introduced
with the change from isc_symtab_t to isc_hashmap_t.
The key improvements are:
1. Using a faster hash function than both isc_hashmap_t and
isc_symtab_t. The previous implementation used SipHash, but the
hashflood resistance properties of SipHash are unneeded for config
parsing.
2. Shrinking the initial size of the isc_hashmap_t used inside
isc_symtab_t. Symtab is mainly used for config parsing, and the
when used that way it will have between 1 and ~50 keys, but the
previous implementation initialized a map with 128 slots.
By initializing a smaller map, we speed up mallocs and optimize for
the typical case of few config keys.
3. Slight optimization of the string matching in the hashmap, so that
the tail is handled in a single load + comparison, instead of byte
by byte.
Of the three improvements, this is the least important.
The following small issues related to `dnssec-policy` have been fixed:
- In some cases the key manager inside BIND 9 could run every hour, while it could have run less often.
- While `CDS` and `CDNSKEY` records will be removed correctly from the zone when the corresponding `DS` record needs to be updated, the expected timing metadata when this will happen was never set.
- There were a couple of cases where the safety intervals are added inappropriately, delaying key rollovers longer than necessary.
- If you have identical `keys` in your `dnssec-policy`, they may be retired inappropriately. Note that having keys with identical properties is discouraged in all cases.
Closes#5242
Merge branch '5242-several-keymgr-issues' into 'main'
See merge request isc-projects/bind9!10251
The dnssec-keygen command for the ZSK generation for the zone
multisigner-model2.kasp was wrong (no ZSK was generated in the setup
script, but when 'named' is started, the missing ZSK was created
anyway by 'dnssec-policy'.
Only set the next time the keymgr should run if the value is non zero.
Otherwise we default back to one hour. This may happen if there is one
or more key with an unlimited lifetime.
The keymgr never set the expected timing metadata when CDS/CDNSKEY
records for the corresponding key will be removed from the zone. This
is not troublesome, as key states dictate when this happens, but with
the new pytest we use the timing metadata to determine if the CDS and/or
CDNSKEY for the given key needs to be published.
There are a couple of cases where the safety intervals are added
inappropriately:
1. When setting the PublishCDS/SyncPublish timing metadata, we don't
need to add the publish-safety value if we are calculating the time
when the zone is completely signed for the first time. This value
is for when the DNSKEY has been published and we add a safety
interval before considering the DNSKEY omnipresent.
2. The retire-safety value should only be added to ZSK rollovers if
there is an actual rollover happening, similar to adding the sign
delay.
3. The retire-safety value should only be added to KSK rollovers if
there is an actual rollover happening. We consider the new DS
omnipresent a bit later, so that we are forced to keep the old DS
a bit longer.
While converting the kasp system test to pytest, I encountered a small
bug in the keymgr code. We retire keys when there is more than one
key matching a 'keys' line from the dnssec-policy. But if there are
multiple identical 'keys' lines, as is the case for the test zone
'checkds-doubleksk.kasp', we retire one of the two keys that have the
same properties.
Fix this by checking if there are double matches. This is not fool proof
because there may be many keys for a few identical 'keys' lines, but it
is good enough for now. In practice it makes no sense to have a policy
that dictates multiple keys with identical properties.
Raw integer pointers were being used for the validator's nvalidations
and nfails values but the memory holding them could be freed before
they ceased to be used. Use reference counted counters instead.
Closes#5239
Merge branch '5239-use-counter-for-nvalidations-and-nfailss' into 'main'
See merge request isc-projects/bind9!10248
The fetch context that held these values could be freed while there
were still active pointers to the memory. Using a reference counted
pointer avoids this.
