For some (one for now) CNAMEs we have a empty A record answer from
Unbound. Proper answer came from remote DNS as showed in Unbound log and
tcpdump.
Identical issue came from both us Unbound instances:
- CentOS 6, Unbound 1.5.1 from EPEL, configured as recursive caching with
forward-zone;
- CentOS 7, Unbound 1.4.20 from base, configured as authoritative,
validating, recursive caching.
Log from first Unbound instance (with verbosity level 4) and from tcpdump
is in attachment, and dig from client (with output) is:
For some (one for now) CNAMEs we have a empty A record answer from
Unbound. Proper answer came from remote DNS as showed in Unbound
log and tcpdump. Identical issue came from both us Unbound
instances: - CentOS 6, Unbound 1.5.1 from EPEL, configured as
recursive caching with forward-zone; - CentOS 7, Unbound 1.4.20
from base, configured as authoritative, validating, recursive
caching.
Log from first Unbound instance (with verbosity level 4) and from
tcpdump is in attachment, and dig from client (with output) is:
What happens is the query for www.sensoray.com gives a CNAME to
sensoray.com and an A record. But when queried specifically for the
sensoray.com name the A record does not exist, the A record in the
CNAME answer was a lie!
You can test this yourself, with dig sensoray.com @8.8.8.8 and this
returns no A record. (according to the verbosity 4 logs you give)
The A record is inserted in the same way some cache-poisoning attacks
work. The cache-poisoning attack mitigations in unbound remove it.
(and unbound logs that it is scrubbed out of the answer).
FYI, Red Hat Enterprise Linux 6 and 7, and derivatives (I checked CentOS,
Oracle (Enterprise) Linux, and Scientific Linux), as well as EPEL for el5
and el6 (epel7 does not have unbound package yet) have wrong (mistyped)
private-address for a link-local range (192.254.0.0/16 instead of
169.254.0.0/16) in unbound.conf.
I reported this bug on bugzilla.redhat.com.
Please double-check the config, do not make the mistake I did.
FYI, Red Hat Enterprise Linux 6 and 7, and derivatives (I checked CentOS,
Oracle (Enterprise) Linux, and Scientific Linux), as well as EPEL for el5
and el6 (epel7 does not have unbound package yet) have wrong (mistyped)
private-address for a link-local range (192.254.0.0/16 instead of
169.254.0.0/16) in unbound.conf.
BTW unbound package is part of vanilla RHEL 7, so it does not need to be in
EPEL. Use 'yum install' as usual and it should just work.