<html><head></head><body><div><div><div class=""><div class=""><div class=""><div class=""><br></div></div><br><div class="sh-signature"><div class="gmail_signature"><br></div></div></div><br><div class="sh-quoted-content"><div class=""><div class="gmail_quote">On Wed, Oct 19, 2022 at 4:38 AM, Scott Morizot <span dir="ltr" class=""><<a href="mailto:tmorizot@gmail.com" target="_blank" class="">tmorizot@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div dir="ltr" class=""><div dir="ltr" class="">On Wed, Oct 19, 2022 at 5:11 AM Petr Špaček <<a href="mailto:pspacek@isc.org" target="_blank" rel="noopener noreferrer" class="">pspacek@<wbr>isc.<wbr>org</a>> wrote:<br></div><div class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Code is your guide :-)<br></blockquote><div class=""><br></div><div class="">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.<br></div></div></div></div></div></blockquote></div></div></div></div><div><div><br></div><div><br></div><div>Weeeeeell… I think that the way it *should* work is: When you need to understand how something works you read the fine RFCs… and when it doesn't work like that, you read the code and say "See, over here in line 42 of foozlewargh.c you are checking if bar <= 17, and you *should* be checking if bar == 17."<br></div><div><br></div><div>Yes, I know, I know… but I did say "the way it *should* work"...<br></div><div><br></div><div>W</div><div><br></div><div><br></div></div><div class=""><div class="sh-quoted-content"><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><div dir="ltr" class=""><div class="gmail_quote"><div class=""> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Now seriously: I don't think documenting it neither<br>
a) necessary<br>
b) good idea<br></blockquote><div class=""><br></div><div class="">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.<br></div><div class=""> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
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 class=""><br></div><div class="">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. <br></div><div class=""><br></div><div class="">So the controlling point from a DNSSEC perspective is the insecure status of <a href="http://fiscal.treasury.gov" target="_blank" rel="noopener noreferrer" class="">fiscal.<wbr>treasury.<wbr>gov</a>.<br></div><div class=""><br></div><div class="">DNSVIZ captures it. The red lines note that the RRSIGs for the entries in <a href="http://fiscal.treasury.gov" target="_blank" rel="noopener noreferrer" class="">fiscal.<wbr>treasury.<wbr>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" target="_blank" rel="noopener noreferrer" class="">fiscal.<wbr>treasury.<wbr>gov</a> becomes insecure unless a resolver has a trust anchor for a lower level zone.<br></div><div class=""><br></div><div class=""><a href="https://dnsviz.net/d/fiscal.treasury.gov/dnssec/" target="_blank" rel="noopener noreferrer" class="">https:/<wbr>/<wbr>dnsviz.<wbr>net/<wbr>d/<wbr>fiscal.<wbr>treasury.<wbr>gov/<wbr>dnssec/<wbr></a><br></div><div class=""><br></div><div class="">The DS query correctly validates the non-existence of a DS record in the secure parent zone, <a href="http://treasury.gov" target="_blank" rel="noopener noreferrer" class="">treasury.<wbr>gov</a>. They should clean up the <a href="http://fiscal.treasury.gov" target="_blank" rel="noopener noreferrer" class="">fiscal.<wbr>treasury.<wbr>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" target="_blank" rel="noopener noreferrer" class="">treasury.<wbr>gov</a> from .gov. But none of those items actually break anything.<br></div><div class=""><br></div><div class="">dig @<a href="http://ns1.treasury.gov" target="_blank" rel="noopener noreferrer" class="">ns1.<wbr>treasury.<wbr>gov</a> <a href="http://fiscal.treasury.gov" target="_blank" rel="noopener noreferrer" class="">fiscal.<wbr>treasury.<wbr>gov</a> ds +multiline +dnssec +norecurse<br><br>; <<>> DiG 9.16.28 <<>> @<a href="http://ns1.treasury.gov" target="_blank" rel="noopener noreferrer" class="">ns1.<wbr>treasury.<wbr>gov</a> <a href="http://fiscal.treasury.gov" target="_blank" rel="noopener noreferrer" class="">fiscal.<wbr>treasury.<wbr>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" target="_blank" rel="noopener noreferrer" class="">fiscal.<wbr>treasury.<wbr>gov</a>. IN DS<br><br>;; AUTHORITY SECTION:<br><a href="http://treasury.gov" target="_blank" rel="noopener noreferrer" class="">treasury.<wbr>gov</a>. 900 IN SOA <a href="http://ns1.treasury.gov" target="_blank" rel="noopener noreferrer" class="">ns1.<wbr>treasury.<wbr>gov</a>. <a href="http://ecb-hosting.fiscal.treasury.gov" target="_blank" rel="noopener noreferrer" class="">ecb-hosting.<wbr>fiscal.<wbr>treasury.<wbr>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" target="_blank" rel="noopener noreferrer" class="">treasury.<wbr>gov</a>. 900 IN RRSIG SOA 7 2 900 (<br> 20221023094202 20221016084202 3908 <a href="http://treasury.gov" target="_blank" rel="noopener noreferrer" class="">treasury.<wbr>gov</a>.<br> J0M3CKVGn+KAUhQ086q4tuAlA9HpoUQRVjfwP67wC/RO<br> HTvSldVFCnKEV0QfTBnb8Z+bCU421PtMTjeI66efgPrc<br> agp2BcggozZyMkonypTRJ4CW63JabXxy5RtSFq1jnTdf<br> zNz2TK+yhfelkV1e3FN4uJmT2rcwcaQToOEYCzM= )<br><a href="http://mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov" target="_blank" rel="noopener noreferrer" class="">mta7icve5v8c9rqj08ur3qeo9tpp6l6s.<wbr>treasury.<wbr>gov</a>. 900 IN NSEC3 1 0 1 16EBC108F10FE696 (<br> MTA7ICVE5V8C9RQJ08UR3QEO9TPP6L6T<br> NS RRSIG )<br><a href="http://mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov" target="_blank" rel="noopener noreferrer" class="">mta7icve5v8c9rqj08ur3qeo9tpp6l6s.<wbr>treasury.<wbr>gov</a>. 900 IN RRSIG NSEC3 7 3 900 (<br> 20221026090448 20221019080448 3908 <a href="http://treasury.gov" target="_blank" rel="noopener noreferrer" class="">treasury.<wbr>gov</a>.<br> ng8mTUN469dzduIYeUWNcVJJlnRLnH8C7OA5J3ysjk+8<br> X1yX0/CONnMmlztKL1zwCstgv6L9xr8aUJW9Z/Bn/CtI<br> whh9ymeJ0lXQzXzg6Fi7RmeSHl9Ecu1789FrbuPQF+tA<br> bwTcddJ29fDG9lgx4F8JvnzVxeHk4TqOh171Fhs= )<br></div><div class=""><br></div><div class=""><br></div></div></div>
<p class="">_______________________________________________
<br>
dns-operations mailing list
<br>
<a target="_blank" rel="noopener noreferrer" href="mailto:dns-operations@lists.dns-oarc.net" class="">dns-operations@<wbr>lists.<wbr>dns-oarc.<wbr>net</a>
<br>
<a target="_blank" rel="noopener noreferrer" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a></p></div></div></blockquote></div></div></div></div><div><br></div></div><div></div></div></body></html>