BIND DNSSEC-Validation issue sceggs.nsw.edu.au

Tue Sep 13 06:57:21 UTC 2011

On 09/12/11 22:12, Neil wrote:
> Hi BIND Users
> I am currently trialing Bind v9.8.1 and have come across a issue with 1
> particular domain.
> For some reason when I query the below domain on bind resolver-cache
> nothing gets returned.?
> dig @<server> sceggs.nsw.edu.au ns
> The debug logs show
> 13-Sep-2011 10:11:27.272 query-errors: debug 1: client
> 203.134.1.70#10309: view host_resolver_trusted: query failed (SERVFAIL)
> for sceggs.nsw.edu.au/IN/NS at query.c:6195
> 13-Sep-2011 10:11:27.272 query-errors: debug 2: fetch completed at
> resolver.c:3160 for sceggs.nsw.edu.au/NS in 30.000122: timed out/success
> [domain:sceggs.nsw.edu.au,referral:0,restart:7,qrysent:7,timeout:6,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
> named.conf has the below settings for dnssec
> dnssec-enable yes;
> dnssec-validation auto;
> Even with the below and managed-keys still does not work
> dnssec-enable yes;
> dnssec-validation yes;
> The only way a result is given is to turn off dnssec-validation then it
> works!
> "dnssec-validation no;"
> Only then a result is given for the query. The domain is in the AU space
> which is not
> currently signed. So I don't know why this would affect sec-validation
> and the queried domain?
> Also noticed its happening in 9.7.2-P3
> Any ideas why this is happening and how to fix it without loosing
> dnssec-validation?
> Does anyone else have the same issue with the above scenario?

A quick glance shows two problems:

1. The three authoritative DNS servers for sceggs.nsw.edu.au are 
dns1.sceggs.nsw.edu.au, dns2.sceggs.nsw.edu.au, and ns2.netstrategy.net. 
  dns1.sceggs.. and dns2.sceggs.. have no glue records in their parent zone.

2. ns2.netstrategy.net has glue in the parent, but it's the WRONG glue, 
and it points to a server that doesn't respond.

All three servers for the zone are effectively glue-less.  How cute.

I can consistently make the queries work properly, even with 
dnssec-validation set to 'yes', by flushing the cache, doing a priming 
query for ns2.netstrategy.net, and THEN querying for 'sceggs.nsw.edu.au 
ns'.  I can also make it consistently fail by flushing the cache and 
then only querying for 'sceggs.nsw.edu.au ns'.

As to why it only happens when dnssec-validation is turned on: It 
appears that BIND continues to use the broken glue record address for 
ns2.netstrategy.net when querying for the sceggs.nsw.edu.au zone, even 
after it receives an authoritative, but unsigned, response with the 
correct A for ns2.netstrategy.net (see the end of this message).  This 
behavior only occurs when dnssec-validation is turned on, not when it is 
turned off.  It's possible that the presence of the glue record in a 
signed zone (even though the glue record itself is not signed) takes 
precedence over the same A record in the authoritative zone.  However, 
that doesn't seem right to me.

Definitely, the zone delegation is seriously broken, due to issues #1 
and #2.  However, BIND's behavior doesn't seem right to me when 
validation is turned on.  Given the 'insecure' (in DNSSEC parlance) 
status of glue records, it seems to make sense to trust authoritative 
records over glue.  marka, do you know why BIND is doing this?

michael

dnscap output below.  Note that the server continues to query 
203.22.128.6 even after it receives an authoritative answer showing 
203.19.73.24 is the address for ns2.netstrategy.ne.

[121] 2011-09-13 06:41:43.429408 [#11 em0 0] \
         [139.130.4.5].53 [10.33.22.1].58454  \
         dns QUERY,NOERROR,40967,qr|aa|cd \
         1 ns2.netstrategy.net,IN,AAAA 0 \
         1 
netstrategy.net,IN,SOA,3600,ns2.netstrategy.net,helpdesk.netstrategy.net,584,3600,600,1209600,86400 
\
         1 .,CLASS4096,OPT,32768,[0]
[182] 2011-09-13 06:41:43.429473 [#12 em0 0] \
         [139.130.4.5].53 [10.33.22.1].52414  \
         dns QUERY,NOERROR,42323,qr|aa|cd \
         1 ns2.netstrategy.net,IN,A \
         1 ns2.netstrategy.net,IN,A,86400,203.19.73.241 \
         3 netstrategy.net,IN,NS,86400,ns2.netstrategy.net \
         netstrategy.net,IN,NS,86400,ns1.telstra.net \
         netstrategy.net,IN,NS,86400,ns3.netstrategy.net \
         3 ns1.telstra.net,IN,A,3600,139.130.4.5 \
         ns3.netstrategy.net,IN,A,86400,203.19.73.242 \
         .,CLASS4096,OPT,32768,[0]
[74] 2011-09-13 06:41:45.576191 [#13 em0 0] \
         [10.33.22.1].53097 [203.22.128.6].53  \
         dns QUERY,NOERROR,60640,cd \
         1 sceggs.nsw.edu.au,IN,NS 0 0 \
         1 .,CLASS512,OPT,32768,[0]
[63] 2011-09-13 06:41:48.386073 [#14 em0 0] \
         [10.33.22.1].51867 [203.22.128.6].53  \
         dns QUERY,NOERROR,5198 \
         1 sceggs.nsw.edu.au,IN,NS 0 0 0
[63] 2011-09-13 06:41:51.596035 [#15 em0 0] \
         [10.33.22.1].63212 [203.22.128.6].53  \
         dns QUERY,NOERROR,25663 \
         1 sceggs.nsw.edu.au,IN,NS 0 0 0
[63] 2011-09-13 06:41:58.005930 [#16 em0 0] \
         [10.33.22.1].62111 [203.22.128.6].53  \
         dns QUERY,NOERROR,36882 \
         1 sceggs.nsw.edu.au,IN,NS 0 0 0
[63] 2011-09-13 06:42:08.015611 [#17 em0 0] \
         [10.33.22.1].63580 [203.22.128.6].53  \
         dns QUERY,NOERROR,36886 \
         1 sceggs.nsw.edu.au,IN,NS 0 0 0