From 73f4d29ef46f9bbcb104b3dd54393c702848a0ab Mon Sep 17 00:00:00 2001 From: Bob Halley Date: Sat, 10 Apr 1999 00:37:31 +0000 Subject: [PATCH] add --- doc/design/ncache | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 doc/design/ncache diff --git a/doc/design/ncache b/doc/design/ncache new file mode 100644 index 0000000000..7bb59ac7ec --- /dev/null +++ b/doc/design/ncache @@ -0,0 +1,34 @@ + +Negative Caching + + +The non-DNSSEC case is pretty easy. + + foundname = soa name + rdataset = soa + node = NULL + +DNSSEC complicates things a lot, because we have to return one or more NXT +records (if we have them) as proof. Another tricky bit here is that we may +have an NXT record so we know the answer is NODATA, but we don't have the SOA +so we can't make a NODATA response that a non-DNSSEC-aware server could +cache. Life would sure be easier if we knew if the client understood DNSSEC. +Not sure what to do in this case. Probably return delegation to force client +to ask authority. + + +Perhaps we should just create some kind of meta-rdata, the "negative cache +rdata type"? + +Or maybe something like: + +dns_rdataset_ncachefirst() +dns_rdataset_ncachenext() +dns_rdataset_ncachecurrent() + +dns_db_ncachenew(db, type) /* type can be any */ +dns_db_ncachesoa(name, rdataset) +dns_db_ncachenxt(name, rdataset) +dns_db_ncacheadd(db, name, version) + +Ick. I favor the former.