[dns-operations] dmdc.osd.mil and osd.mil

[Timothy Morizot]

Hello all,

I've encountered an interesting situation resolving a response from a
DNSSEC signed zone, osd.mil. That zone has a child zone, dmdc.osd.mil,
whose records started validating as bogus at work. Not sure when. Was
notified last week and took a quick glance, but didn't have the opportunity
to dig into it until today.

The child zone, dmdc.osd.mil, is not signed and there's an insecure
delegation (no DS record) breaking the chain of trust from osd.mil to
dmdc.osd.mil. As I worked through logs,  I figured out responses from the
child were validating as bogus because the absence of a DS record in the
parent couldn't be validated. And that was odd, because manual digs to the
parent with the DO bit set confirmed the presence of the appropriate signed
NSEC3 records.

Finally I realized I was getting a SERVFAIL response when querying our
caching nameservers for the DS record even with the CD bit set. Validation
was failing because the validation process was never passed the response to
the DS query. So I kept digging and discovered that when I queried all
three osd.mil authoritative nameservers directly (with DO bit on and
recursion not requested) for the dmdc.osd.mil DS record, I received a
non-authoritative no data response (curiously also with the ra flag set).
That's a strange response from an authoritative nameserver serving a
signed, secure zone. I confirmed that a number of other authoritative
nameservers returned an authoritative nodata response for a DS query for an
insecure delegation from a signed zone. And it's just that one query that
returns a non-authoritative response. The query for the SOA and NS records
for osd.mil all return authoritative responses.

I confirmed that BIND and Unbound (both the ODVR instances and my own
personal installations) as well as Google Public DNS had no problem using
the lame responses to validate the non-existence of a DS record. (We use
Secure64 DNS Caches at work.) I can certainly report it as a bug if it is
one, but first I would like to understand the reasoning behind accepting a
non-authoritative response from purportedly authoritative nameservers and
using it to perform validation.

One of the queries in question below for reference.

Thanks,

Scott

 dig @dns-pub-f1-u.pentagon.mil dmdc.osd.mil ds +dnssec +bufsize=1280
+norecurse

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> @
dns-pub-f1-u.pentagon.mil dmdc.osd.mil ds +dnssec +bufsize=1280 +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14321
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dmdc.osd.mil.                  IN      DS

;; AUTHORITY SECTION:
osd.mil.                703     IN      SOA     dns-mas-a1-t.pentagon.mil.
sysadmin.pentagon.mil. 2006102673 900 90 2592000 3600
osd.mil.                703     IN      RRSIG   SOA 8 2 43200
20131215124220 20131115114220 62418 osd.mil.
mKQjR5b1jNijj7GMHooi2E0RJprGg4JP3cKCnQxiNoFKleSTlRqzYe95
SDVskwpfqLfH/7rWtDEz0lpHpbEXYMoVBERWr8rQGN0/e2IbLA+ld9sp
ZdfwKyk9UT00LqnYExL64ukCtRPWyOLdqxJAxFBFF+9XiZnBYnGgSpTc IZw=
JABIIA1AIIOUSA03INL8GARQSAC7L3T5.osd.mil. 703 IN RRSIG NSEC3 8 3 3600
20131210152956 20131110143531 62418 osd.mil.
VWLHyQeuzgsgg2/5QPAqeJo4cMNiggcF0Ix0iCvIq954zm2gLUD7wcG/
///pbw/bJ8F0EijHtKHiKtPCa2vbKyWyIw1+rTJlkTeUKNi6QDh97eU9
mxgivnmjLroBAYYwgK7DYcWoUdaMOrKMo74d0wbGuvGHmcIFcGUjrE0T mx8=
JABIIA1AIIOUSA03INL8GARQSAC7L3T5.osd.mil. 703 IN NSEC3 1 0 10
EE17BF354BB45091DD358E6D6E05 JAHGJ96SAT40MNK4N62VOS92780B0CDK NS

;; Query time: 66 msec
;; SERVER: 199.252.47.11#53(199.252.47.11)
;; WHEN: Fri Nov 15 17:08:48 2013
;; MSG SIZE  rcvd: 530
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131115/41ba5bf8/attachment.html>