On Wed, Oct 19, 2022 at 5:11 AM Petr Špaček <pspa...@isc.org> wrote:
> Code is your guide :-) > Agreed. Any time I have a need to drill down and understand exactly what is happening and source code is available, that is always where I look first. > Now seriously: I don't think documenting it neither > a) necessary > b) good idea > Comments in the code are always helpful. ;-) But yes, beyond that trying to capture specific mechanisms rather than what is being accomplished in the documentation is often counter-productive. > It can change between versions, and we certainly do not want people to > depend on particular behavior. We want people to follow protocol! > Yep. And in this instance, I haven't found the protocol standard ambiguous. Once the chain of trust is broken through a valid insecure delegation, it can only be reestablished by a trust anchor for a zone farther down the hierarchy. In earlier days, before the root zone was signed or when there were gaps in the chain, such lower level trust anchors were more common for early adopters. These days, people mostly just use the root trust anchor so once there's a point where the chain of trust shifts to insecure it remains insecure for everyone for subsequent delegations. A DS record can only establish a secure delegation when placed in a secure zone. Putting one in an insecure zone does nothing for the security status of the delegated zone. A resolver would require a trust anchor for it to establish security. So the controlling point from a DNSSEC perspective is the insecure status of fiscal.treasury.gov. DNSVIZ captures it. The red lines note that the RRSIGs for the entries in fiscal.treasury.gov are no good. (I have no insight into why they are being generated, but it's likely a misconfiguration somewhere.) But the records themselves, like the delegation, are clearly marked insecure. At that juncture, everything below fiscal.treasury.gov becomes insecure unless a resolver has a trust anchor for a lower level zone. https://dnsviz.net/d/fiscal.treasury.gov/dnssec/ The DS query correctly validates the non-existence of a DS record in the secure parent zone, treasury.gov. They should clean up the fiscal.treasury.gov zone and fix whatever is generating the spurious and invalid DNSSEC records in it. But the presence of those records should have no impact on validation since the zone itself is insecure. They also really should migrate at least to algorithm 8 and remove the SHA-1 DS record for treasury.gov from .gov. But none of those items actually break anything. dig @ns1.treasury.gov fiscal.treasury.gov ds +multiline +dnssec +norecurse ; <<>> DiG 9.16.28 <<>> @ns1.treasury.gov fiscal.treasury.gov ds +multiline +dnssec +norecurse ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10792 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;fiscal.treasury.gov. IN DS ;; AUTHORITY SECTION: treasury.gov. 900 IN SOA ns1.treasury.gov. ecb-hosting.fiscal.treasury.gov. ( 2001180551 ; serial 3600 ; refresh (1 hour) 900 ; retry (15 minutes) 1209600 ; expire (2 weeks) 900 ; minimum (15 minutes) ) treasury.gov. 900 IN RRSIG SOA 7 2 900 ( 20221023094202 20221016084202 3908 treasury.gov. J0M3CKVGn+KAUhQ086q4tuAlA9HpoUQRVjfwP67wC/RO HTvSldVFCnKEV0QfTBnb8Z+bCU421PtMTjeI66efgPrc agp2BcggozZyMkonypTRJ4CW63JabXxy5RtSFq1jnTdf zNz2TK+yhfelkV1e3FN4uJmT2rcwcaQToOEYCzM= ) mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN NSEC3 1 0 1 16EBC108F10FE696 ( MTA7ICVE5V8C9RQJ08UR3QEO9TPP6L6T NS RRSIG ) mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN RRSIG NSEC3 7 3 900 ( 20221026090448 20221019080448 3908 treasury.gov. ng8mTUN469dzduIYeUWNcVJJlnRLnH8C7OA5J3ysjk+8 X1yX0/CONnMmlztKL1zwCstgv6L9xr8aUJW9Z/Bn/CtI whh9ymeJ0lXQzXzg6Fi7RmeSHl9Ecu1789FrbuPQF+tA bwTcddJ29fDG9lgx4F8JvnzVxeHk4TqOh171Fhs= )
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations