zonemaster icon indicating copy to clipboard operation
zonemaster copied to clipboard
verified publisher icon zonemaster

Update DNSSEC05

Open mattias-p opened this issue 3 years ago • 6 comments

The next time we make an update to DNSSEC05 we should also fix this:

  • The tag NO_RESPONSE_DNSKEY should be renamed to NO_VALID_DNSKEY. This is because the current tag name indicates that no response was received but its semantics also include situations where response with a badly broken DNSKEY is received.

mattias-p avatar Mar 17 '22 17:03 mattias-p

We could find another name, but "NO_VALID_DNSKEY" gives the impression that there are DNSKEY, but no valid ones. When the test case is updated to match the test case template, a new must anyway be given. Or maybe the test case should ignore the non-presence.

matsduf avatar Mar 25 '22 12:03 matsduf

We could find another name, but "NO_VALID_DNSKEY" gives the impression that there are DNSKEY, but no valid ones. When the test case is updated to match the test case template, a new must anyway be given. Or maybe the test case should ignore the non-presence.

Let's keep the discussion in #1044.

mattias-p avatar Mar 25 '22 16:03 mattias-p

We should have one test case that reports any issue to reach the DNSKEY, not multiple test cases. Preliminary I do not think it should be this test case.

matsduf avatar Mar 25 '22 16:03 matsduf

Another issue I found with this Test Case: it outputs redundant messages because it loops over name servers and instantly outputs messages for each DNSKEY record found. Instead, the results should be grouped by keytag before being outputted. See the specification here.

There are three name servers for "afnic.fr", so the same messages are repeated three times. Note that this is with IPv6 queries off. If enabled, the number of messages doubles.

$ zonemaster-cli --show-testcase --test dnssec/dnssec05 afnic.fr --level INFO --raw --no-ipv6
   0.00 INFO      UNSPECIFIED    GLOBAL_VERSION   version=v4.6.2
   0.59 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=53080
   0.59 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=14322
   0.59 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=32064
   0.59 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=14322
   0.59 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=32064
   0.59 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=53080
   0.60 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=14322
   0.60 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=32064
   0.60 INFO      DNSSEC05       ALGORITHM_OK   algo_descr=ECDSA Curve P-256 with SHA-256; algo_num=13; keytag=53080

tgreenx avatar May 11 '23 16:05 tgreenx

Another issue I found with this Test Case [ ... ]

@mattias-p @matsduf Should I create a separate issue for this? I'm not sure of the state of this issue.

tgreenx avatar May 11 '23 16:05 tgreenx

Another issue I found with this Test Case: it outputs redundant messages because it loops over name servers and instantly outputs messages for each DNSKEY record found. Instead, the results should be grouped by keytag before being outputted. See the specification here.

Yes, it is a know issue. The specification should be rewritten. When it is rewritten it should be considered what messages it output.

matsduf avatar May 12 '23 09:05 matsduf