Re: Confirm BIND is correctly validating dmdc.osd.mil
This could be a result of KeyTrap mitigations.The number of DS records is weird, but as long as there’s a valid path from root and no conflicting keytags, this looks fine to me.Ondrej--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 9. 8. 2024, at 20:56, John Thurston wrote: Our up-stream resolver (Akamai) is unable to validate scra.dmdc.osd.mil, 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. The nice dnsviz visualizer https://dnsviz.net/d/scra.dmdc.osd.mil/dnssec/ 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). My bench-check of the behavior of BIND appears correct to me, but I'm seeking confirmation. When I delv 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. 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 : ;; fetch: scra.dmdc.osd.mil/A ;; received packet from 96.7.136.4#53 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54760 ;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;scra.dmdc.osd.mil. IN A ;; ANSWER SECTION: ;scra.dmdc.osd.mil. 10 IN A 214.16.194.43 ;; validating scra.dmdc.osd.mil/A: starting ;; validating scra.dmdc.osd.mil/A: attempting insecurity proof ;; validating scra.dmdc.osd.mil/A: checking existence of DS at 'mil' ;; fetch: mil/DS ;; received packet from 96.7.136.4#53 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41961 ;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;mil. IN DS ;; ANSWER SECTION: ;mil. 86400 IN DS 16801 8 2 ( ; 49013E5D5ED406C25C5A3E7F67C7 ; 56E34C925342A34BD64D7427536C ; 366DF99A ) ;; validating mil/DS: starting ;; validating mil/DS: attempting insecurity proof ;; validating mil/DS: checking existence of DS at 'mil' ;; validating mil/DS: continuing validation would lead to deadlock: aborting validation ;; validating mil/DS: deadlock found (create_fetch) ;; no valid RRSIG resolving 'mil/DS/IN': 96.7.136.4#53 ;; validating scra.dmdc.osd.mil/A: in fetch_callback_ds ;; validating scra.dmdc.osd.mil/A: fetch_callback_ds: got SERVFAIL ;; broken trust chain resolving 'scra.dmdc.osd.mil/A/IN': 96.7.136.4#53 ;; resolution failed: broken trust chain -- -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this listISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Confirm BIND is correctly validating dmdc.osd.mil
Oh, duh. I had a momentary mental lapse, maybe just from looking through all the DS records. No, there's no issue with having a DS record published that points to a valid and visible DNSKEY that doesn't sign the DNSKEY RRSet as long as there's at least one RRSIG from a validated DS/DNSKEY match. I knew that. I think I even have an instance where circumstances required mre to implement that situation in one of the zones I administer. Sorry about that. I have no insight into Akamai's recursive name service implementation. I doubt it's the fact that both SHA-1 and SHA-256 DS records are present for the same key. That's still not especially uncommon today. They should just disregard the SHA-1 DS record in that case. My best guess remains that in their implementation they set some sort of upper boundary for the number of DS records they'll attempt to process and that boundary is too low. But that's purely a guess. The number of DS records in osd.mil for dmdc.osd.mil is probably the most I've personally seen. Since I can't poke the Akamai recursive name service myself, I have no way to dig any more. HTH, Scott On Fri, Aug 9, 2024 at 2:52 PM Scott Morizot wrote: > dmdc.osd.mil 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. > > 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 > osd.mil that point to DNSKEY records that are published in dmdc.osd.mil. > Those are 36244 and 33250. However, only 36244 is actually signing the > DNSKEY RRSet in dmdc.osd.mil. 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. > > 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. > > 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. > > Just my thoughts. Other than looking at the zone itself, I didn't do > anything to dig more deeply into them. > > HTH, > > Scott > > On Fri, Aug 9, 2024 at 1:56 PM John Thurston > wrote: > >> Our up-stream resolver (Akamai) is unable to validate scra.dmdc.osd.mil, >> 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. >> >> The nice dnsviz visualizer https://dnsviz.net/d/scra.dmdc.osd.mil/dnssec/ >> 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). >> >> My bench-check of the behavior of BIND appears correct to me, but I'm >> seeking confirmation. >> >> >> When I *delv* 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. >> >> 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 >> : >> >> ;; fetch: scra.dmdc.osd.mil/A >> ;; received packet from 96.7.136.4#53 >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54760 >> ;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> ;; QUESTION SECTION: >> ;scra.dmdc.osd.mil. IN A >> >> ;; ANSWER SECTION: >> ;scra.dmdc.osd.mil. 10 IN A 214.16.194.43 >> >> >> ;; validating scra.dmdc.osd.mil/A: starting >> ;; validating scra.dmdc.osd.mil/A: attempting insecurity proof >> ;; validating scra.dmdc.osd.mil/A: checking existence of DS at 'mil' >> ;; fetch: mil/DS >> ;; received packet from 96.7.136.4#53 >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41961 >> ;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 >> ;; QUESTION SECTION: >> ;mil. IN DS >> >> ;; ANSWER SECTION: >> ;mil. 86400 I
Re: Confirm BIND is correctly validating dmdc.osd.mil
dmdc.osd.mil 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. 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 osd.mil that point to DNSKEY records that are published in dmdc.osd.mil. Those are 36244 and 33250. However, only 36244 is actually signing the DNSKEY RRSet in dmdc.osd.mil. 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. 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. 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. Just my thoughts. Other than looking at the zone itself, I didn't do anything to dig more deeply into them. HTH, Scott On Fri, Aug 9, 2024 at 1:56 PM John Thurston wrote: > Our up-stream resolver (Akamai) is unable to validate scra.dmdc.osd.mil, > 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. > > The nice dnsviz visualizer https://dnsviz.net/d/scra.dmdc.osd.mil/dnssec/ > 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). > > My bench-check of the behavior of BIND appears correct to me, but I'm > seeking confirmation. > > > When I *delv* 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. > > 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 > : > > ;; fetch: scra.dmdc.osd.mil/A > ;; received packet from 96.7.136.4#53 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54760 > ;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;scra.dmdc.osd.mil. IN A > > ;; ANSWER SECTION: > ;scra.dmdc.osd.mil. 10 IN A 214.16.194.43 > > > ;; validating scra.dmdc.osd.mil/A: starting > ;; validating scra.dmdc.osd.mil/A: attempting insecurity proof > ;; validating scra.dmdc.osd.mil/A: checking existence of DS at 'mil' > ;; fetch: mil/DS > ;; received packet from 96.7.136.4#53 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41961 > ;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;mil. IN DS > > ;; ANSWER SECTION: > ;mil. 86400 IN DS 16801 8 2 ( > ; > 49013E5D5ED406C25C5A3E7F67C7 > ; > 56E34C925342A34BD64D7427536C > ; 366DF99A ) > > > ;; validating mil/DS: starting > ;; validating mil/DS: attempting insecurity proof > ;; validating mil/DS: checking existence of DS at 'mil' > ;; validating mil/DS: continuing validation would lead to deadlock: > aborting validation > ;; validating mil/DS: deadlock found (create_fetch) > ;; no valid RRSIG resolving 'mil/DS/IN': 96.7.136.4#53 > ;; validating scra.dmdc.osd.mil/A: in fetch_callback_ds > ;; validating scra.dmdc.osd.mil/A: fetch_callback_ds: got SERVFAIL > ;; broken trust chain resolving 'scra.dmdc.osd.mil/A/IN': 96.7.136.4#53 > ;; resolution failed: broken trust chain > > > -- > -- > Do things because you should, not just because you can. > > John Thurston907-465-8591john.thurs...@alaska.gov > Department of Administration > State of Alaska > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit
