[Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.
simon at thekelleys.org.uk
Wed Feb 5 17:26:08 EST 2014
On 05/02/14 20:09, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon at thekelleys.org.uk> writes:
>> Same CPU architecture as the working systems, or different?
> Sorry, I meant that the package signatures for the OBS Arch packages are
> failing, not the DNSSEC signatures...
>> That's expected for 1) queries answered from local configuration
>> (/etc/hosts etc) 2) queries answered with data from DHCP (this is
>> probably not relevant) 3) queries answered from the cache. The
>> verification result is stored in the cache and not repeated.
>> The log gives the source of the data, so these should be identifiable.
> Well turning log-queries back on, this is the first one (seems to be the
> second query performed):
> dnsmasq: query[PTR] 126.96.36.199.in-addr.arpa from 127.0.0.1
> dnsmasq: forwarded 188.8.131.52.in-addr.arpa to 127.0.0.1
> dnsmasq: validation result is INSECURE
> dnsmasq: reply 184.108.40.206 is static-213-115-75-62.sme.bredbandsbolaget.se
> Don't see anything preceded by dnssec-query for any in-addr.arpa queries
> before that (assuming the cache is not stored between restarts?).
That's straightforward. Dnsmasq gets a query for
220.127.116.11.in-addr.arpa, sends it upstream, gets an answer which
isn't signed, and determines that it's insecure, then returns the
answer. The last line is as it is because a PTR RR for
18.104.22.168.in-addr.arpa has been parsed into the triple
for storage in the dnsmasq cache, which is not a general RR cache, but a
cache of domain-names against IP addresses, with some extensions for
CNAMEs, and now more extensions for DNSKEYs DSs and RRSIGs.
More information about the Cerowrt-devel