[dns-operations] dmdc.osd.mil and osd.mil
marka at isc.org
Sat Nov 16 01:24:54 UTC 2013
In message <CAFy81rkC29S=uWuVC5JyYDBJL_UN8OgGtMo6wwRYDVZX+NoPJA at 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.
> dig @dns-pub-f1-u.pentagon.mil dmdc.osd.mil ds +dnssec +bufsize=1280
> ; <<>> 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.
> ZdfwKyk9UT00LqnYExL64ukCtRPWyOLdqxJAxFBFF+9XiZnBYnGgSpTc IZw=
> JABIIA1AIIOUSA03INL8GARQSAC7L3T5.osd.mil. 703 IN RRSIG NSEC3 8 3 3600
> 20131210152956 20131110143531 62418 osd.mil.
> mxgivnmjLroBAYYwgK7DYcWoUdaMOrKMo74d0wbGuvGHmcIFcGUjrE0T mx8=
> JABIIA1AIIOUSA03INL8GARQSAC7L3T5.osd.mil. 703 IN NSEC3 1 0 10
> EE17BF354BB45091DD358E6D6E05 JAHGJ96SAT40MNK4N62VOS92780B0CDK NS
> ;; Query time: 66 msec
> ;; SERVER: 220.127.116.11#53(18.104.22.168)
> ;; 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: marka at isc.org
More information about the dns-operations