Confirm BIND is correctly validating dmdc.osd.mil

[John Thurston]

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 Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240809/b757f09d/attachment.htm>