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

[JINMEI Tatuya / 神明達哉]

At Wed, 20 Aug 2008 16:39:30 -0400,
"L. Gabriel Somlo" <gsomlo at gmail.com> wrote:

> Except, in the same file (rbtdb.c), on line 4814, we have
> 
> 	if ((options & DNS_DBADD_FORCE) != 0)
> 		trust = dns_trust_ultimate;
> 	else
> 		trust = newheader->trust;
> 
> Now, back to my original problem in resolver.c, where DNS_DBADD_FORCE
> is turned on for glue records received while executing the search
> algorithm... Why MUST such records overwrite otherwise valid cache
> data ?

Quick counter response: you're now changing the context.  In your very
original message:

: 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) ?

So the RR type in question should be A.  My response to that was based
on that context.  On the other hand, the code in resolver.c you
referenced is specifically limited to NS (and RRSIG covering NS)
RRsets:

			if (rdataset->trust == dns_trust_glue &&
			    (rdataset->type == dns_rdatatype_ns ||
			     (rdataset->type == dns_rdatatype_rrsig &&
			      rdataset->covers == dns_rdatatype_ns))) {
				/*
				 * If the trust level is 'dns_trust_glue'
				 * then we are adding data from a referral
				 * we got while executing the search algorithm.
				 * New referral data always takes precedence
				 * over the existing cache contents.
				 */
				options = DNS_DBADD_FORCE;
			} else

Now I'm feeling I don't understand your problem...are you simply
trying to identify a possible discrepancy between RFC2181 and the
implementation, or do you have any specific problem that the
implementation causes?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.