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 >
