9.3.0rc2, the ad bit, and dnssec-must-be-secure

[Wesley Griffin]

To start, I'm using 9.3.0rc2 on FreeBSD 4.8. The full conf files are
available here <http://www.netsec.tislabs.com/conf/benedict/>. You can
also query benedict.netsec.tislabs.com. directly if you want to see any
of this "live".

benedict.netsec.tislabs.com. is configured as a security-aware resolver.
I believe I'm using that term correctly: benedict has only localhost and
0.0.127.in-addr.arpa configured as zones and it forwards the reverse for
the subnet to the authoritative server.

I have 'dnssec-enable yes' and 'dnssec-must-be-secure
netsec.tislabs.com. yes' and have the trusted key for
netsec.tislabs.com. configured in the named.conf file.

Finally, I have a secure delegation, dyn.netsec.tislabs.com. that is
signed as well. This delegation is being served from the same set of
authoritative servers. For the really curious, this zone is accepting
SIG(0) dynamic updates from dhcp clients and resigning the zone on the
fly. Pretty cool :)

First, what does dnssec-must-be-secure actually do? The ARM says that
named will only accept answers if they are secure, and if no, normal
dnssec validation applies. What part of named and accept from where? And
shouldn't named be performing dnssec validation if I have a trusted key
configured?

Here's why I ask. I'm using a hacked version of dnsspoof from dsniff
that spoofs away (returns NXDOMAIN replies) to DS and DNSKEY queries,
and spoofs a configured IP address for A queries. From another
nameserver configured exactly like benedict (just inside the firewall so
that dnsspoof can work) I query for 'www.netsec.tislabs.com. in a' while
spoofing from a machine on the same hub. Predictably I get back SERVFAIL
and no answer. I query for 'www.netsec.tislabs.com. in a' with CD=1 and
get back the spoofed answer.

If I take out dnssec-must-be-secure I get the same behavior. I guess I
was expecting to not get anything back from the resolver if
dnssec-must-be-secure was enabled unless the answer validated. But CD=1
seems to trump that. I have a feeling I'm just no understanding this
option :)

Next, I'm curious how named decides to set the AD bit in its replies.
When I query @benedict for 'www.netsec.tislabs.com. in a' the reply does
not have the AD bit set. When I query @benedict for
'www.netsec.tislabs.com. in a' with the DO bit set, the reply does have
the AD bit set:

; <<>> DiG 9.3.0rc2 <<>> @localhost www.netsec.tislabs.com. in a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59456
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0
 
;; QUESTION SECTION:
;www.netsec.tislabs.com.        IN A

and:

; <<>> DiG 9.3.0rc2 <<>> @localhost www.netsec.tislabs.com. in a +dnssec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49449
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.netsec.tislabs.com.        IN A

I should mention that the first reply (DO=0) has the NS for
netsec.tislabs.com. in the authority section, while the second reply
(DO=1) does not.

When I query @benedict for 'active.dyn.netsec.tislabs.com. in a' without
the DO bit set, the reply does have the AD bit set and this confuses me:

; <<>> DiG 9.3.0rc2 <<>> @localhost active.dyn.netsec.tislabs.com. in a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26327
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
;; QUESTION SECTION:
;active.dyn.netsec.tislabs.com. IN A

This reply also does not have anything in the authority section. So the
only difference between the first reply (www.netsec.tislabs.com. DO=0)
and the second reply (active.dyn.netsec.tislabs.com. DO=0) is that the
authority section in the first reply has the NS for netsec.tislabs.com.
while there is no NS for dyn.netsec.tislabs.com. in the second reply.

But the second reply has the AD bit set, while the first does not (even
though DO=0 in both queries). Is this because of the inclusion of the NS
RRs? Looking at protocol-06, Section 3.2.3, the "name server side SHOULD
set the AD bit if and only if the resolver side considers all RRsets in
the Answer section and any relevant negative response RRs in the
Authority section to be authentic." So is the resolver not considering
the NS RRs in the authority section authentic?

Other that that everything else works.

-- 
Wesley Griffin <wgriffin at sparta.com>