[DNSOP] Re: ordering of RRSets in the answer section of a DNS response

[Petr Špaček <[e-mail]>]

On 16. 01. 26 12:22, Philip Homburg wrote:
>> Can stubs just ignore CNAMEs and just extract addresses from A and
>> AAAA records found in the answer section?
>>
>> Assuming that the internal stub interfaces eventually discard CNAME
>> data anyway, that would actually result in a simplified implementation.
>>
>> The current code with CNAME matching allows the upstream server to
>> include unrelated addresses in the answer section that will be
>> ignored.  Retaining this behavior, while relaxing the CNAME ordering,
>> requires quite a bit of extra complexity in stubs.
> 
> There is a problem with that if the stub relies on a DNSSEC validating proxy
> (or if the stub has a DNSSEC validator that just implements the specs.)
> 
> As far as I know, DNSSEC requires the validator to validate every RRset in
> the answer and authority sections. It also requires the validator to
> verify that there is proof of NXDOMAIN or NODATA. However, there doesn't
> seem any requirement that the validator removes unwanted data.
> 
> That means that an attacker can insert extra RRsets and the stub resolver
> believes it is secure because it is behind a DNSSEC validator. So at
> the moment, the only option for the sub resolver is to follow the CNAME
> chain.

I agree extra RRs are allowed, but I think they must be authentic. So 
the worst attacker can do is to add RRs which are 'DNSSEC secure' into 
the answer.

(To make it absolutely clear: Content of Additional section is not 
DNSSEC validated, so picking up RRs from there is risky.)

-- 
Petr Špaček