A record from cache for request that resolved to (some) CNAMEs

[Petr Spacek]

On 23.9.2015 11:44, Mehmed Kahric via Unbound-users wrote:
> Hi to all,
> 
> 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.

Petr Spacek @ Red Hat

> I reported this bug on bugzilla.redhat.com.
> Please double-check the config, do not make the mistake I did.
> 
> Regards, Mehmed
> 
> 
> On Tue, September 22, 2015 10:22, W.C.A. Wijngaards via Unbound-users wrote:
> Hi Mehmed,
> 
> On 21/09/15 13:17, Mehmed Kahric via Unbound-users wrote:
>>>> Hi,
>>>>
>>>> I have a similar issue as reported in Bug 669.
>>>>
>>>> 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).
> 
> Best regards,
>    Wouter
> 
> 
>>>>
>>>> --- C:\Users\Moi>dig www.sensoray.com @192.168.10.14
>>>>
>>>> ; <<>> DiG 9.10.2-P3 <<>> www.sensoray.com @192.168.10.14 ;; global
>>>> options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
>>>> NOERROR, id: 38559 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1,
>>>> AUTHORITY: 0, ADDITIONAL: 1
>>>>
>>>> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;;
>>>> QUESTION SECTION: ;www.sensoray.com.              IN      A
>>>>
>>>> ;; ANSWER SECTION: www.sensoray.com.       5433    IN      CNAME
>>>> sensoray.com.
>>>>
>>>> ;; Query time: 218 msec ;; SERVER: 192.168.10.14#53(192.168.10.14)
>>>> ;; WHEN: Fri Sep 18 11:13:30 Central Europe Daylight Time 2015 ;;
>>>> MSG SIZE  rcvd: 59
>>>>
>>>> C:\Users\Moi>dig sensoray.com @192.168.10.14
>>>>
>>>> ; <<>> DiG 9.10.2-P3 <<>> sensoray.com @192.168.10.14 ;; global
>>>> options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
>>>> NOERROR, id: 5722 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0,
>>>> AUTHORITY: 0, ADDITIONAL: 1
>>>>
>>>> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;;
>>>> QUESTION SECTION: ;sensoray.com.                  IN      A
>>>>
>>>> ;; Query time: 31 msec ;; SERVER: 192.168.10.14#53(192.168.10.14)
>>>> ;; WHEN: Fri Sep 18 11:13:37 Central Europe Daylight Time 2015 ;;
>>>> MSG SIZE  rcvd: 41
>>>>
>>>> ---
>>>>
>>>>
>>>> Regards, Mehmed