<div dir="ltr"><div dir="ltr">On Wed, Oct 19, 2022 at 5:11 AM Petr Špaček <<a href="mailto:pspacek@isc.org">pspacek@isc.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Code is your guide :-)<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Now seriously: I don't think documenting it neither<br>
a) necessary<br>
b) good idea<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It can change between versions, and we certainly do not want people to <br>
depend on particular behavior. We want people to follow protocol!<br></blockquote><div><br></div><div>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. </div><div><br></div><div>So the controlling point from a DNSSEC perspective is the insecure status of <a href="http://fiscal.treasury.gov">fiscal.treasury.gov</a>.</div><div><br></div><div>DNSVIZ captures it. The red lines note that the RRSIGs for the entries in <a href="http://fiscal.treasury.gov">fiscal.treasury.gov</a> 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 <a href="http://fiscal.treasury.gov">fiscal.treasury.gov</a> becomes insecure unless a resolver has a trust anchor for a lower level zone.</div><div><br></div><div><a href="https://dnsviz.net/d/fiscal.treasury.gov/dnssec/">https://dnsviz.net/d/fiscal.treasury.gov/dnssec/</a><br></div><div><br></div><div>The DS query correctly validates the non-existence of a DS record in the secure parent zone, <a href="http://treasury.gov">treasury.gov</a>. They should clean up the <a href="http://fiscal.treasury.gov">fiscal.treasury.gov</a> 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 <a href="http://treasury.gov">treasury.gov</a> from .gov. But none of those items actually break anything.</div><div><br></div><div>dig @<a href="http://ns1.treasury.gov">ns1.treasury.gov</a> <a href="http://fiscal.treasury.gov">fiscal.treasury.gov</a> ds +multiline +dnssec +norecurse<br><br>; <<>> DiG 9.16.28 <<>> @<a href="http://ns1.treasury.gov">ns1.treasury.gov</a> <a href="http://fiscal.treasury.gov">fiscal.treasury.gov</a> ds +multiline +dnssec +norecurse<br>; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10792<br>;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1<br><br>;; OPT PSEUDOSECTION:<br>; EDNS: version: 0, flags: do; udp: 4096<br>;; QUESTION SECTION:<br>;<a href="http://fiscal.treasury.gov">fiscal.treasury.gov</a>. IN DS<br><br>;; AUTHORITY SECTION:<br><a href="http://treasury.gov">treasury.gov</a>. 900 IN SOA <a href="http://ns1.treasury.gov">ns1.treasury.gov</a>. <a href="http://ecb-hosting.fiscal.treasury.gov">ecb-hosting.fiscal.treasury.gov</a>. (<br> 2001180551 ; serial<br> 3600 ; refresh (1 hour)<br> 900 ; retry (15 minutes)<br> 1209600 ; expire (2 weeks)<br> 900 ; minimum (15 minutes)<br> )<br><a href="http://treasury.gov">treasury.gov</a>. 900 IN RRSIG SOA 7 2 900 (<br> 20221023094202 20221016084202 3908 <a href="http://treasury.gov">treasury.gov</a>.<br> J0M3CKVGn+KAUhQ086q4tuAlA9HpoUQRVjfwP67wC/RO<br> HTvSldVFCnKEV0QfTBnb8Z+bCU421PtMTjeI66efgPrc<br> agp2BcggozZyMkonypTRJ4CW63JabXxy5RtSFq1jnTdf<br> zNz2TK+yhfelkV1e3FN4uJmT2rcwcaQToOEYCzM= )<br><a href="http://mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov">mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov</a>. 900 IN NSEC3 1 0 1 16EBC108F10FE696 (<br> MTA7ICVE5V8C9RQJ08UR3QEO9TPP6L6T<br> NS RRSIG )<br><a href="http://mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov">mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov</a>. 900 IN RRSIG NSEC3 7 3 900 (<br> 20221026090448 20221019080448 3908 <a href="http://treasury.gov">treasury.gov</a>.<br> ng8mTUN469dzduIYeUWNcVJJlnRLnH8C7OA5J3ysjk+8<br> X1yX0/CONnMmlztKL1zwCstgv6L9xr8aUJW9Z/Bn/CtI<br> whh9ymeJ0lXQzXzg6Fi7RmeSHl9Ecu1789FrbuPQF+tA<br> bwTcddJ29fDG9lgx4F8JvnzVxeHk4TqOh171Fhs= )<br></div><div><br></div><div><br></div></div></div>