Let's make sure we first check if the OPT was lost in the reply, before we accept a reply as successful and use it for
verifying the current feature level.
When we restart a DNS transaction, remove all connections to any auxiliary DNSSEC transactions, after all we might
acquire completely different data this time, requiring different auxiliary DNSSEC transactions.
If we receive a reply that lacks the OPT RR, then this is reason to downgrade what was verified before, as it's
apparently no longer true, and the previous OPT RR we saw was only superficially OK.
Similar, if we realize that RRSIGs are not augmented, then also downgrade the feature level that was verified, as
DNSSEC is after all not supported. This check is in particular necessary, as we might notice the fact that RRSIG is not
augmented only very late, when verifying the root domain.
Also, when verifying a successful response, actually take in consideration that it might have been reported already
that RRSIG or OPT are missing in the response.
This adds logic to downgrade the feature level more aggressively when we have reason to. Specifically:
- When we get a response packet that lacks an OPT RR for a query that had it. If so, downgrade immediately to UDP mode,
i.e. don't generate EDNS0 packets anymore.
- When we get a response which we are sure should be signed, but lacks RRSIG RRs, we downgrade to EDNS0 mode, i.e.
below DO mode, since DO is apparently not really supported.
This should increase compatibility with servers that generate non-sensical responses if they messages with OPT RRs and
suchlike, for example the situation described here:
https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2014-November/000376.html
This also changes the downgrade code to explain in a debug log message why a specific downgrade happened.
This validates OPT RRs more rigorously, before honouring them: if we any of the following condition holds, we'll ignore
them:
a) Multiple OPT RRs in the same message
b) OPT RR not owned by the root domain
c) OPT RR in the wrong section (Belkin routers do this)
d) OPT RR contain rfc6975 algorithm data (Belkin routers do this)
e) OPT version is not 0
f) OPT payload doesn't add up with the lengths
Note that d) may be an indication that the server just blindly copied OPT data from the response into the reply.
RFC6975 data is only supposed to be included in queries, and we do so. It's not supposed to be included in responses
(and the RFC is very clear on that). Hence if we get it back in a reply, then the server probably just copied the OPT
RR.
This new test case tries to resolve a couple of known domains, to verify the validation results. It talks to resolved
via the bus, thus comprehensively testing the whole shebang.
Of course, it requires network connectivity and a DNSSEC capable DNS server, hence this is a manual test.
This fills in the last few gaps:
- When checking if a domain is non-existing, also check that no wildcard for it exists
- Ensure we don't base "covering" tests on NSEC RRs from a parent zone
- Refuse to accept expanded wildcard NSEC RRs for absence proofs.
empty non-terminals generally lack NSEC RRs, which means we can deduce their existance only from the fact that there
are other RRs that contain them in their suffix. Specifically, the NSEC proof for NODATA on ENTs works by sending the
NSEC whose next name is a suffix of the queried name to the client. Use this information properly.
Having this information available is useful when we need to check whether various RRs are suitable for proofs. This
information is stored in the RRs as number of labels to skip from the beginning of the owner name to reach the
synthesizing source/signer. Simple accessor calls are then added to retrieve the signer/source from the RR using this
information.
This also moves validation of a a number of RRSIG parameters into a new call dnssec_rrsig_prepare() that as side-effect
initializes the two numeric values.
When proving NODATA DS lookups we need to insist on looking at the parent zone's NSEC RR, not the child zone's.
When proving any other NODATA lookups we need to insist on looking at the child zone's NSEC RR, not the parent's.
Fixes:
==1== by 0x23E44C: remove_marked_symlinks_fd (install.c:453)
==1== by 0x23E256: remove_marked_symlinks_fd (install.c:405)
==1== by 0x23E630: remove_marked_symlinks (install.c:494)
==1== by 0x2427A0: unit_file_disable (install.c:1876)
==1== by 0x18A633: method_disable_unit_files_generic (dbus-manager.c:1760)
==1== by 0x18A6CA: method_disable_unit_files (dbus-manager.c:1768)
==1== by 0x1D8146: method_callbacks_run (bus-objects.c:420)
==1== by 0x1DA9D8: object_find_and_run (bus-objects.c:1257)
==1== by 0x1DB01A: bus_process_object (bus-objects.c:1373)
==1==
==1== 228 (48 direct, 180 indirect) bytes in 2 blocks are definitely lost in loss record 8 of 14
==1== at 0x4C2BBCF: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1== by 0x4C2DE2F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1== by 0x23DA60: unit_file_changes_add (install.c:233)
==1== by 0x23DDB2: create_symlink (install.c:298)
==1== by 0x240C5C: install_info_symlink_wants (install.c:1328)
==1== by 0x240FC8: install_info_apply (install.c:1384)
==1== by 0x241211: install_context_apply (install.c:1439)
==1== by 0x242563: unit_file_enable (install.c:1830)
==1== by 0x18A06E: method_enable_unit_files_generic (dbus-manager.c:1650)
==1== by 0x18A141: method_enable_unit_files (dbus-manager.c:1660)
==1== by 0x1D8146: method_callbacks_run (bus-objects.c:420)
==1== by 0x1DA9D8: object_find_and_run (bus-objects.c:1257)
==1==
==1== 467 (144 direct, 323 indirect) bytes in 3 blocks are definitely lost in loss record 9 of 14
==1== at 0x4C2DD9F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1== by 0x23DA60: unit_file_changes_add (install.c:233)
==1== by 0x23DE97: create_symlink (install.c:320)
==1== by 0x242CFC: unit_file_set_default (install.c:1951)
==1== by 0x18A881: method_set_default_target (dbus-manager.c:1802)
==1== by 0x1D8146: method_callbacks_run (bus-objects.c:420)
==1== by 0x1DA9D8: object_find_and_run (bus-objects.c:1257)
==1== by 0x1DB01A: bus_process_object (bus-objects.c:1373)
==1== by 0x259143: process_message (sd-bus.c:2567)
==1== by 0x259326: process_running (sd-bus.c:2609)
==1== by 0x259BDC: bus_process_internal (sd-bus.c:2798)
==1== by 0x259CAD: sd_bus_process (sd-bus.c:2817)
==1==
==1== LEAK SUMMARY:
==1== definitely lost: 216 bytes in 6 blocks
==1== indirectly lost: 560 bytes in 14 blocks
==1== possibly lost: 0 bytes in 0 blocks
==1== still reachable: 65,536 bytes in 5 blocks
==1== suppressed: 0 bytes in 0 blocks
==1== Reachable blocks (those to which a pointer was found) are not shown.
==1== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1==
Fixes:
==1== HEAP SUMMARY:
==1== in use at exit: 67,182 bytes in 91 blocks
==1== total heap usage: 70,485 allocs, 70,394 frees, 42,184,635 bytes
allocated
==1==
==1== 5,742 (696 direct, 5,046 indirect) bytes in 29 blocks are
definitely lost in loss record 4 of 7
==1== at 0x4C2DD9F: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1== by 0x21ADDD: realloc_multiply (alloc-util.h:67)
==1== by 0x21BFB0: strv_push (strv.c:448)
==1== by 0x21C245: strv_consume (strv.c:520)
==1== by 0x21C33C: strv_extend (strv.c:559)
==1== by 0x278AD7: unit_write_drop_in (unit.c:3352)
==1== by 0x278EEB: unit_write_drop_in_private (unit.c:3403)
==1== by 0x190C21: bus_service_set_transient_property
(dbus-service.c:254)
==1== by 0x190DBC: bus_service_set_property (dbus-service.c:284)
==1== by 0x18F00E: bus_unit_set_properties (dbus-unit.c:1226)
==1== by 0x186F6A: transient_unit_from_message (dbus-manager.c:683)
==1== by 0x1872B7: method_start_transient_unit (dbus-manager.c:763)
==1==
==1== LEAK SUMMARY:
==1== definitely lost: 696 bytes in 29 blocks
==1== indirectly lost: 5,046 bytes in 58 blocks
==1== possibly lost: 0 bytes in 0 blocks
==1== still reachable: 61,440 bytes in 4 blocks
==1== suppressed: 0 bytes in 0 blocks
If a unit was pulled by a Wants= dependency but its unit file was not
present then we logged this as an error.
However Wants= might be used to configure a soft/optional dependency
on another unit, ie. start an optional service only if it's installed
otherwise simply skip it. In this case emitting an error doesn't look
appropriate.
But it's still an error if the optional dependency exists but its
activation fails for any reasons.
==1== HEAP SUMMARY:
==1== in use at exit: 61,728 bytes in 22 blocks
==1== total heap usage: 258,122 allocs, 258,100 frees, 78,219,628
bytes allocated
==1==
==1== 16 bytes in 1 blocks are definitely lost in loss record 1 of 6
==1== at 0x4C2BBCF: malloc (vg_replace_malloc.c:299)
==1== by 0x1E350E: memdup (alloc-util.c:34)
==1== by 0x135AFB: memdup_multiply (alloc-util.h:74)
==1== by 0x140F97: manager_set_default_rlimits (manager.c:2929)
==1== by 0x1303DA: manager_set_defaults (main.c:737)
==1== by 0x133A02: main (main.c:1718)
==1==
==1== 272 bytes in 17 blocks are definitely lost in loss record 2 of 6
==1== at 0x4C2BBCF: malloc (vg_replace_malloc.c:299)
==1== by 0x1E350E: memdup (alloc-util.c:34)
==1== by 0x135AFB: memdup_multiply (alloc-util.h:74)
==1== by 0x140F97: manager_set_default_rlimits (manager.c:2929)
==1== by 0x1303DA: manager_set_defaults (main.c:737)
==1== by 0x13480D: main (main.c:1828)
==1==
==1== LEAK SUMMARY:
==1== definitely lost: 288 bytes in 18 blocks
==1== indirectly lost: 0 bytes in 0 blocks
==1== possibly lost: 0 bytes in 0 blocks
==1== still reachable: 61,440 bytes in 4 blocks
==1== suppressed: 0 bytes in 0 blocks
==1== Reachable blocks (those to which a pointer was found) are not
shown.
==1== To see them, rerun with: --leak-check=full --show-leak-kinds=all
When a unit was started with "systemctl --user" and it failed, error
messages is printed as "systemctl status". But it should be "systemctl
--user status".
In contrast to ascii_strcasecmp_nn() it takes two character buffers with their individual length. It will then compare
the buffers up the smaller size of the two buffers, and finally the length themselves.
Properly handle RRs that begin with an asterisk label. These are the unexpanded forms of wildcard domains and appear in
NSEC RRs for example. We need to make sure we handle the signatures of these RRs properly, since they mostly are
considered normal RRs, except that the RRSIG labels counter is one off for them, as the asterisk label is always
excluded of the signature.
