<div dir="ltr"><a href="http://dmdc.osd.mil">dmdc.osd.mil</a> is ... a bit of a mess. However, sha-1 DS records remain present and I doubt whatever Akamai's recursive service is doing is choking on those.<div><br></div><div>I note (and confirmed with my own manual queries) that amid all the DS records that don't point to anything, there are two SHA-256 DS records in <a href="http://osd.mil">osd.mil</a> that point to DNSKEY records that are published in <a href="http://dmdc.osd.mil">dmdc.osd.mil</a>. Those are 36244 and 33250. However, only 36244 is actually signing the DNSKEY RRSet in <a href="http://dmdc.osd.mil">dmdc.osd.mil</a>. In theory, the validator would check each DS record to see if it points to a DNSKEY record that signs the DNSKEY RRSet. But I can see a validator matching a DS record to a DNSKEY and confirming the DNSKEY did not sign the record set and treating the delegation as bogus. Honestly, I don't recall what the standard says in a situation like that. It's been too long since I stepped through it and I didn't go check. But that is certainly unusual.</div><div><br></div><div>Or it may just be that Akamai has a boundary set to limit how many DS records it checks and the delegation has hit that limit. That's a *lot* of extra DS records. I actually have DS records in the public parent for some of my work zones that don't appear to point to anything since they point to a KSK in an internal version of the delegated zone. So having some DS records that don't appear to point to anything doesn't bother me. But that's a lot more than you normally see. It wouldn't be an unusual boundary condition. I imagine BIND also has a boundary of some sort set, though I didn't look for one in the code.</div><div><br></div><div>Those seem more likely to me than simply failing because of the SHA-1 DS records. It's a lot simpler just to ignore them when there's a SHA-256 DS record present and that seems to be what most implementations do.</div><div><br></div><div>Just my thoughts. Other than looking at the zone itself, I didn't do anything to dig more deeply into them.</div><div><br></div><div>HTH,</div><div><br></div><div>Scott</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 9, 2024 at 1:56 PM John Thurston <<a href="mailto:john.thurston@alaska.gov">john.thurston@alaska.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Our up-stream resolver (Akamai) is unable to validate
<a href="http://scra.dmdc.osd.mil" target="_blank">scra.dmdc.osd.mil</a>, when my 9.18.28 BIND resolver is able to. I
think my BIND server is doing it correctly, and the Akamai
resolver is not.<br>
</p>
<p>The nice dnsviz visualizer
<a href="https://dnsviz.net/d/scra.dmdc.osd.mil/dnssec/" target="_blank">https://dnsviz.net/d/scra.dmdc.osd.mil/dnssec/</a> leads me to suspect
that Akamai is choking on the presence of the SHA-1 records
(rather than ignoring them and accepting the SHA-256 records).</p>
<p>My bench-check of the behavior of BIND appears correct to me, but
I'm seeking confirmation.</p>
<p><br>
</p>
<p>When I <i>delv</i> locally for that A-record, I find a CNAME,
another CNAME, and an A. My BIND resolver is able to validate all
of the responses.</p>
<p>When I ask the Akamai resolver, it chokes. Unfortunately, I can't
offer the query for anyone else to try, because AFAIK Akamai
doesn't have a publicly-accessible resolver. But this is what I
get when I +mtrace +vtrace :<br>
</p>
<p>
</p><blockquote type="cite">;; fetch: <a href="http://scra.dmdc.osd.mil/A" target="_blank">scra.dmdc.osd.mil/A</a><br>
;; received packet from 96.7.136.4#53<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
54760<br>
;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0,
ADDITIONAL: 0<br>
;; QUESTION SECTION:<br>
;<a href="http://scra.dmdc.osd.mil" target="_blank">scra.dmdc.osd.mil</a>. IN A<br>
<br>
;; ANSWER SECTION:<br>
;<a href="http://scra.dmdc.osd.mil" target="_blank">scra.dmdc.osd.mil</a>. 10 IN A 214.16.194.43<br>
<br>
<br>
;; validating <a href="http://scra.dmdc.osd.mil/A" target="_blank">scra.dmdc.osd.mil/A</a>: starting<br>
;; validating <a href="http://scra.dmdc.osd.mil/A" target="_blank">scra.dmdc.osd.mil/A</a>: attempting insecurity proof<br>
;; validating <a href="http://scra.dmdc.osd.mil/A" target="_blank">scra.dmdc.osd.mil/A</a>: checking existence of DS at
'mil'<br>
;; fetch: mil/DS<br>
;; received packet from 96.7.136.4#53<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
41961<br>
;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0,
ADDITIONAL: 0<br>
;; QUESTION SECTION:<br>
;mil. IN DS<br>
<br>
;; ANSWER SECTION:<br>
;mil. 86400 IN DS 16801 8 2 (<br>
;
49013E5D5ED406C25C5A3E7F67C7<br>
;
56E34C925342A34BD64D7427536C<br>
; 366DF99A )<br>
<br>
<br>
;; validating mil/DS: starting<br>
;; validating mil/DS: attempting insecurity proof<br>
;; validating mil/DS: checking existence of DS at 'mil'<br>
;; validating mil/DS: continuing validation would lead to
deadlock: aborting validation<br>
;; validating mil/DS: deadlock found (create_fetch)<br>
;; no valid RRSIG resolving 'mil/DS/IN': 96.7.136.4#53<br>
;; validating <a href="http://scra.dmdc.osd.mil/A" target="_blank">scra.dmdc.osd.mil/A</a>: in fetch_callback_ds<br>
;; validating <a href="http://scra.dmdc.osd.mil/A" target="_blank">scra.dmdc.osd.mil/A</a>: fetch_callback_ds: got
SERVFAIL<br>
;; broken trust chain resolving '<a href="http://scra.dmdc.osd.mil/A/IN" target="_blank">scra.dmdc.osd.mil/A/IN</a>':
96.7.136.4#53<br>
;; resolution failed: broken trust chain<br>
</blockquote>
<p></p>
<p><br>
</p>
<pre cols="72">--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a href="mailto:John.Thurston@alaska.gov" target="_blank">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
</div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>