Understanding "removing extraneous answer RRset" behavior

Trey Duskin trey at treyd.us
Sun Dec 29 18:04:51 UTC 2019


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' (hosted in Route53):
   - test CNAME to 'test.local.example.com'
   - outbound resolver rule for 'local.example.com' to point to unbound

'local.example.com' is the domain for the unbound server (pfsense)
   - local-data for 'test.local.example.com. A '
   - forward-zone domain override configured for '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' I will only get the
CNAME answer back.  However, if I query the AWS resolver for '
test.aws.example.com' I get back the CNAME and the A record with the
correct answer ''.  Using packet captures, when I query unbound
for 'test.aws.example.com', I can confirm unbound goes out to the AWS
resolver, the AWS resolver queries unbound for '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:

"info: sanitize: removing extraneous answer RRset: test.local.example.com.

I found the part of the code that outputs this message (
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' called 'google' and
pointed it to '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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20191229/fff19150/attachment.htm>

More information about the Unbound-users mailing list