why do glue records *always* *have* to overwrite the cache ?

[JINMEI Tatuya / 神明達哉]

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.