nonRD fix.

git-svn-id: file:///svn/unbound/trunk@786 be551aaa-1e26-0410-a405-d3ace91eadb9
This commit is contained in:
Wouter Wijngaards 2007-11-28 12:06:32 +00:00
parent 2c2eaecc6c
commit 9ade3e4811
3 changed files with 42 additions and 3 deletions

View file

@ -13,6 +13,10 @@
- nicer verbosity: 0 and 1 levels. - nicer verbosity: 0 and 1 levels.
- lower nonRDquery chance of eliciting wrongly typed validation - lower nonRDquery chance of eliciting wrongly typed validation
requiring message from the cache. 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 27 November 2007: Wouter
- per suggestion in rfc2308, replaced default max-ttl value with 1 day. - per suggestion in rfc2308, replaced default max-ttl value with 1 day.

View file

@ -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. This denies queries that are not authoritative, or version.bind, or any.
And thus prevents cache-snooping (denied hosts cannot make non-recursive And thus prevents cache-snooping (denied hosts cannot make non-recursive
queries and get answers from the cache). 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.

View file

@ -64,9 +64,24 @@ val_classify_response(uint16_t query_flags, struct query_info* qinf,
if(rcode == LDNS_RCODE_NXDOMAIN && rep->an_numrrsets == 0) if(rcode == LDNS_RCODE_NXDOMAIN && rep->an_numrrsets == 0)
return VAL_CLASS_NAMEERROR; return VAL_CLASS_NAMEERROR;
/* check for referral: nonRD query */ /* check for referral: nonRD query and it looks like a nodata */
if(!(query_flags&BIT_RD) && rep->an_numrrsets == 0) 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; 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 */ /* dump bad messages */
if(rcode != LDNS_RCODE_NOERROR) if(rcode != LDNS_RCODE_NOERROR)