<div dir="ltr"><div><div><div><div>Hello all,<br><br></div>I've encountered an interesting situation resolving a response from a DNSSEC signed zone, <a href="http://osd.mil">osd.mil</a>. That zone has a child zone, <a href="http://dmdc.osd.mil">dmdc.osd.mil</a>, 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.<br>
<br></div>The child zone, <a href="http://dmdc.osd.mil">dmdc.osd.mil</a>, is not signed and there's an insecure delegation (no DS record) breaking the chain of trust from <a href="http://osd.mil">osd.mil</a> to <a href="http://dmdc.osd.mil">dmdc.osd.mil</a>. 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.<br>
<br></div>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 <a href="http://osd.mil">osd.mil</a> authoritative nameservers directly (with DO bit on and recursion not requested) for the <a href="http://dmdc.osd.mil">dmdc.osd.mil</a> 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 <a href="http://osd.mil">osd.mil</a> all return authoritative responses.<br>
<br>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.<br>
<br></div><div>One of the queries in question below for reference.<br><br></div><div>Thanks,<br><br></div><div>Scott<br><br> dig @<a href="http://dns-pub-f1-u.pentagon.mil">dns-pub-f1-u.pentagon.mil</a> <a href="http://dmdc.osd.mil">dmdc.osd.mil</a> ds +dnssec +bufsize=1280 +norecurse<br>
<br>; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> @<a href="http://dns-pub-f1-u.pentagon.mil">dns-pub-f1-u.pentagon.mil</a> <a href="http://dmdc.osd.mil">dmdc.osd.mil</a> ds +dnssec +bufsize=1280 +norecurse<br>
; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14321<br>;; flags: qr ra; 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://dmdc.osd.mil">dmdc.osd.mil</a>. IN DS<br><br>;; AUTHORITY SECTION:<br><a href="http://osd.mil">osd.mil</a>. 703 IN SOA <a href="http://dns-mas-a1-t.pentagon.mil">dns-mas-a1-t.pentagon.mil</a>. <a href="http://sysadmin.pentagon.mil">sysadmin.pentagon.mil</a>. 2006102673 900 90 2592000 3600<br>
<a href="http://osd.mil">osd.mil</a>. 703 IN RRSIG SOA 8 2 43200 20131215124220 20131115114220 62418 <a href="http://osd.mil">osd.mil</a>. mKQjR5b1jNijj7GMHooi2E0RJprGg4JP3cKCnQxiNoFKleSTlRqzYe95 SDVskwpfqLfH/7rWtDEz0lpHpbEXYMoVBERWr8rQGN0/e2IbLA+ld9sp ZdfwKyk9UT00LqnYExL64ukCtRPWyOLdqxJAxFBFF+9XiZnBYnGgSpTc IZw=<br>
<a href="http://JABIIA1AIIOUSA03INL8GARQSAC7L3T5.osd.mil">JABIIA1AIIOUSA03INL8GARQSAC7L3T5.osd.mil</a>. 703 IN RRSIG NSEC3 8 3 3600 20131210152956 20131110143531 62418 <a href="http://osd.mil">osd.mil</a>. VWLHyQeuzgsgg2/5QPAqeJo4cMNiggcF0Ix0iCvIq954zm2gLUD7wcG/ ///pbw/bJ8F0EijHtKHiKtPCa2vbKyWyIw1+rTJlkTeUKNi6QDh97eU9 mxgivnmjLroBAYYwgK7DYcWoUdaMOrKMo74d0wbGuvGHmcIFcGUjrE0T mx8=<br>
<a href="http://JABIIA1AIIOUSA03INL8GARQSAC7L3T5.osd.mil">JABIIA1AIIOUSA03INL8GARQSAC7L3T5.osd.mil</a>. 703 IN NSEC3 1 0 10 EE17BF354BB45091DD358E6D6E05 JAHGJ96SAT40MNK4N62VOS92780B0CDK NS<br><br>;; Query time: 66 msec<br>
;; SERVER: 199.252.47.11#53(199.252.47.11)<br>;; WHEN: Fri Nov 15 17:08:48 2013<br>;; MSG SIZE rcvd: 530<br><br></div></div>