nonRD fix.

git-svn-id: file:///svn/unbound/trunk@786 be551aaa-1e26-0410-a405-d3ace91eadb9

diff --git a/doc/Changelog b/doc/Changelog
index 6b33330b57fa5f1ce933a716f033a1b72b2406c6..18099a46186b46786bbb3380671b81a452202dab 100644 (file)
--- a/doc/Changelog
+++ b/doc/Changelog
@@ -13,6 +13,10 @@
        - nicer verbosity: 0 and 1 levels.
        - lower nonRDquery chance of eliciting wrongly typed validation
          requiring message from the cache.
+       - fix for nonRDquery validation typing; nodata is detected when
+         SOA record in auth section (all validation-requiring nodata messages
+         have a SOA record in authority, so this is OK for the validator),
+         and NS record is needed to be a referral.
 
 27 November 2007: Wouter
        - per suggestion in rfc2308, replaced default max-ttl value with 1 day.

diff --git a/doc/requirements.txt b/doc/requirements.txt
index f124a384a6da4812f44543939c364b25f58f1412..6e260ecc916c1ae78cd253561cb97a2b5d9ee89a 100644 (file)
--- a/doc/requirements.txt
+++ b/doc/requirements.txt
@@ -180,3 +180,23 @@ o the access control denies queries before any other processing.
   This denies queries that are not authoritative, or version.bind, or any.
   And thus prevents cache-snooping (denied hosts cannot make non-recursive
   queries and get answers from the cache).
+
+o If a client makes a query without RD bit, in the case of a returned 
+  message from cache which is:
+       answer section: empty
+       auth section: NS record present, no SOA record, no DS record, 
+               maybe NSEC or NSEC3 records present.
+       additional: A records or other relevant records.
+  A SOA record would indicate that this was a NODATA answer.
+  A DS records would indicate a referral.
+  Absence of NS record would indicate a NODATA answer as well.
+
+  Then the receiver does not know whether this was a referral
+  with attempt at no-DS proof) or a nodata answer with attempt
+  at no-data proof. It could be determined by attempting to prove
+  either condition; and looking if only one is valid, but both 
+  proofs could be valid, or neither could be valid, which creates
+  doubt. This case is validated by unbound as a 'referral' which
+  ascertains that RRSIGs are OK (and not omitted), but does not
+  check NSEC/NSEC3. 
+

diff --git a/validator/val_utils.c b/validator/val_utils.c
index 5f29ed9bf7f74e82176b82d77b3cfadf2242b09b..17ab3d356fc55855f7300efd83619b9b3d77ea82 100644 (file)
--- a/validator/val_utils.c
+++ b/validator/val_utils.c
@@ -64,9 +64,24 @@ val_classify_response(uint16_t query_flags, struct query_info* qinf,
        if(rcode == LDNS_RCODE_NXDOMAIN && rep->an_numrrsets == 0)
                return VAL_CLASS_NAMEERROR;
 
-       /* check for referral: nonRD query */
-       if(!(query_flags&BIT_RD) && rep->an_numrrsets == 0)
-               return VAL_CLASS_REFERRAL;
+       /* check for referral: nonRD query and it looks like a nodata */
+       if(!(query_flags&BIT_RD) && rep->an_numrrsets == 0 &&
+               rcode == LDNS_RCODE_NOERROR) {
+               /* SOA record in auth indicates it is NODATA instead.
+                * All validation requiring NODATA messages have SOA in 
+                * authority section. */
+               /* uses fact that answer section is empty */
+               int saw_ns = 0;
+               for(i=0; i<rep->ns_numrrsets; i++) {
+                       if(ntohs(rep->rrsets[i]->rk.type) == LDNS_RR_TYPE_SOA)
+                               return VAL_CLASS_NODATA;
+                       if(ntohs(rep->rrsets[i]->rk.type) == LDNS_RR_TYPE_DS)
+                               return VAL_CLASS_REFERRAL;
+                       if(ntohs(rep->rrsets[i]->rk.type) == LDNS_RR_TYPE_NS)
+                               saw_ns = 1;
+               }
+               return saw_ns?VAL_CLASS_REFERRAL:VAL_CLASS_NODATA;
+       }
        
        /* dump bad messages */
        if(rcode != LDNS_RCODE_NOERROR)