WEBDIENSTE/unbound
1
0
Fork 0
mirror of https://github.com/NLnetLabs/unbound.git synced 2026-09-05 17:37:42 +02:00
Code Issues Packages Projects Releases Wiki Activity

nonRD fix.

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files
doc/Changelog
+4
View File
@@ -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.
doc/requirements.txt
+20
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.
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.
validator/val_utils.c
+18 -3
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)
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)