Re: [dnsext] draft-ietf-dnsext-rfc3597-bis-00

[Florian Weimer <[e-mail]>]

* Matthew Dempsky:

> On Mon, Oct 5, 2009 at 12:09 PM, Florian Weimer <[e-mail]> wrote:
>> * Matthew Dempsky:
>>> E.g., if a DNAME-ignorant cache receives a response with a
>>> DNAME record and a synthesized CNAME record in response to an A-type
>>> query, is it allowed to cache the DNAME record still?
>>
>> It should not be returned to the client in response to a subsequent
>> query for the DNAME record at its owner name.
>
> What's your reasoning for this?

Mainly the observation that it would deliver incomplete RRsets for
RRSIG queries today if we didn't have DO.  Future interesting records
could show similar behavior.

>>> If an AAAA-ignorant cache receives a response with AAAA glue
>>> records, is it allowed to cache the AAAA record still?
>>
>> No, certainly not.  This touches forgery resilience, too.
>
> Your wording implies there are reasons other than forgery resilience
> that the AAAA glue records should be discarded.  Is this the same as
> the DNAME case, or are there additional reasons here?

You don't really know to which section the additional data is related,
and if the RRset is complete (as in the RRSIG case).

>> it can't be promoted to an answer section,
>
> In practice, additional section records are regularly promoted to the
> answer section.  E.g., A and AAAA records returned in the additional
> section in response to an MX or SRV query.

Let's just say that BIND is buggy in this regard, okay?

>> and section 8 of RFC 3597 states that no additional section
>> processing is to be performed for unknown records, so you won't see it
>> there, either.
>
> This seems irrelevant to me: the issue I was suggesting isn't whether
> an unknown record causes additional section processing or not, but
> whether an unknown record type is added because of additional section
> processing.

You need two records to end up with additional section processing, so
it's at best unclear to me if this applies or not.

> Maybe you're assuming a cache that goes to extra effort to associate
> additional section records with the answer/authority records that were
> processed to add them?

I'm worried about BIND 8 style caches which pass through unchecked
information of unknown provence, causing correctness issues further
downstream.