Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC.

[Simon Kelley <simon@thekelleys.org.uk>]

On 05/02/14 20:09, Toke Høiland-Jørgensen wrote:
> Simon Kelley <simon@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[8595]: query[PTR] 62.75.115.213.in-addr.arpa from 127.0.0.1
> dnsmasq[8595]: forwarded 62.75.115.213.in-addr.arpa to 127.0.0.1
> dnsmasq[8595]: validation result is INSECURE
> dnsmasq[8595]: reply 213.115.75.62 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 
62.75.115.213.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 
62.75.115.213.in-addr.arpa has been parsed into the triple
(213.115.75.62, static-213-115-75-62.sme.bredbandsbolaget.se, 
reverse-mapping)
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.

Cheers,

Simon.