why do glue records *always* *have* to overwrite the cache ?
JINMEI Tatuya / 神明達哉
Jinmei_Tatuya at isc.org
Mon Aug 11 21:46:11 UTC 2008
At Sun, 10 Aug 2008 19:19:18 -0400,
"Gabriel Somlo" <gsomlo at gmail.com> wrote:
>
> Simple question, like the subject says. If I have www.foo.com in my
> cache as 1.2.3.4, and I get a (faked) response saying "to find
> out abc123.foo.com go ask www.foo.com at 5.6.7.8", why do I
> *absolutely* *have to* overwrite what I already know (1.2.3.4) with
> what's in the glue record (5.6.7.8) ?
>
> If the cached entry conflicts with the contents of the glue record,
> there's obviously something fishy, and even rfc 2181 says I should
> not overwrite my cache if its contents came from an authoritative
> server
> Everyone seems to take it for granted that "glue records must overwrite
> the cache", even bind-9.5.1b1/lib/dns/resolver.c, line 4106 explicitly
> forces the glue data to take precedence over existing cache contents.
Did you actually confirm this behavior? As far as I understand the
code (and I actually checked the behavior previously) BIND9 doesn't
replace an authoritative RRset with a glue. Or in other words, it
strictly follows the rule of RFC2181.
Codewise, what should be referred to is line 4944 (9.5.1b1) of
lib/dns/rbtdb.c rather than resolver.c:
* Trying to add an rdataset with lower trust to a cache DB
* has no effect, provided that the cache data isn't stale.
*/
if (rbtversion == NULL && trust < header->trust &&
(header->rdh_ttl > now || header_nx)) {
free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
if (addedrdataset != NULL)
bind_rdataset(rbtdb, rbtnode, header, now,
addedrdataset);
return (DNS_R_UNCHANGED);
}
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
More information about the bind-users
mailing list