In message <CAFy81rkC29S=uwuvc5jyydbjl_un8oggtmo6wwrydvzx+no...@mail.gmail.com>, Timothy Morizot writes: > 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.
Because too many authoritative servers are broken. > 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 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
