From: Wouter Wijngaards <wouter@nlnetlabs.nl>
Date: Wed, 28 Nov 2007 12:06:32 +0000 (+0000)
Subject: nonRD fix.
X-Git-Tag: release-0.8~1
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9ade3e4811d246e636f63cb436ffbb3e8f4eddee;p=thirdparty%2Funbound.git

nonRD fix.


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

diff --git a/doc/Changelog b/doc/Changelog
index 6b33330b5..18099a461 100644
--- 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 f124a384a..6e260ecc9 100644
--- 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 5f29ed9bf..17ab3d356 100644
--- 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)