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

["Mehmed Kahrić"]

Hi Petr,

Yes, unbound package is part of base/plus repo in RHEL 6 and 7 in version
1.4.20 and in EPEL el6 in version 1.5.1, but all with same typo...

Regards, Mehmed

On Tue, September 29, 2015 10:45, Petr Spacek via Unbound-users wrote:
> 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
>