Understanding "removing extraneous answer RRset" behavior

[Wouter Wijngaards]

Hi Trey,

On 12/29/19 7:04 PM, Trey Duskin via unbound-users wrote:
> Hello,
> 
> I am trying to understand the behavior of unbound and why it sometimes
> removes the "A" answer that comes back with a query for a CNAME.  My
> setup is as follows:
> 
> 'aws.example.com <http://aws.example.com>' (hosted in Route53):
>    - test CNAME to 'test.local.example.com <http://test.local.example.com>'
>    - outbound resolver rule for 'local.example.com
> <http://local.example.com>' to point to unbound server
> 
> 'local.example.com <http://local.example.com>' is the domain for the
> unbound server (pfsense)
>    - local-data for 'test.local.example.com
> <http://test.local.example.com>. A 172.21.0.252 ' 
>    - forward-zone domain override configured for 'aws.example.com
> <http://aws.example.com>' to point to inbound resolver in AWS
> 
> There is a site-to-site VPN between my network and AWS
> 
> Whenever I query unbound for 'test.aws.example.com
> <http://test.aws.example.com>' I will only get the CNAME answer back. 
> However, if I query the AWS resolver for 'test.aws.example.com
> <http://test.aws.example.com>' I get back the CNAME and the A record
> with the correct answer '172.21.0.252'.  Using packet captures, when I
> query unbound for 'test.aws.example.com <http://test.aws.example.com>',
> I can confirm unbound goes out to the AWS resolver, the AWS resolver
> queries unbound for 'test.local.example.com
> <http://test.local.example.com>', unbound replies, and then AWS replies
> to unbound with the correct answer of both the CNAME and the A record. 
> However, the internal client using unbound as its resolver only gets the
> CNAME.
> 
> If I look in the query logs in unbound, I see this message:

It is removing the A record because it intends to look it up separately.
 In its own query for the A record.  Unbound chases the parts of the
CNAME piece by piece for security reasons.  It looks like a query for
google resolves fine, if that is where you point the CNAME, but if the
CNAME is pointing to the test.local.example.com. name, then the query
for the A record at the test.local.example.com. name is not answered by
the upstream that unbound is trying to get the answer from.

The fix would be for the upstream to answer for the A record.  Not just
attach that A record to the CNAME.  But also answer for the A record
when queried directly.  Then unbound, when chasing the parts of the
chain of CNAME indirections, can find the information that it needs.

The security reason is to prevent cache poisoning.  If unbound did not
do it, it would open up issues around false answers bypassing ID value
checks and ending up in the cache.

Best regards, Wouter

> 
> "info: sanitize: removing extraneous answer RRset:
> test.local.example.com <http://test.local.example.com>. A IN"
> 
> I found the part of the code that outputs this message
> (https://github.com/NLnetLabs/unbound/blob/master/iterator/iter_scrub.c#L699-L708)
> and the comments indicate that removing any answers that don't have the
> same domain name as the query is on purpose.  If so, why is that?  As an
> experiment, I added in a CNAME in 'aws.example.com
> <http://aws.example.com>' called 'google' and pointed it to
> 'www.google.com <http://www.google.com>' and that doesn't have this
> problem, but the domain name is clearly different, so if this on purpose
> I'm not sure why this worked but a CNAME that points to unbound
> local-data doesn't work.
> 
> As for why I'm contorting myself for all this, I'm trying to change the
> domain of the unbound box (and all its clients) but some clients still
> use old fully-qualified names, and I want to provide backward
> compatibility. I have a (not great) work around but I'm trying to
> understand this behavior.
> 
> Thanks in advance for any help provided.
> 
> - treyd
> 
> 
> 
> 
> 
> _______________________________________________
> unbound-users mailing list
> unbound-users at lists.nlnetlabs.nl
> https://lists.nlnetlabs.nl/mailman/listinfo/unbound-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20200106/4e05bfe1/attachment.bin>