From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id D1F9921F18A for ; Wed, 5 Feb 2014 14:26:09 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:41349 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WBAv1-0002vj-Hr; Wed, 05 Feb 2014 22:26:07 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1WBAv0-0002ti-OB; Wed, 05 Feb 2014 22:26:06 +0000 Message-ID: <52F2BA80.9010202@thekelleys.org.uk> Date: Wed, 05 Feb 2014 22:26:08 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= References: <87a9e6xcae.fsf@alrua-x1.kau.toke.dk> <87ob2lmqny.fsf@toke.dk> <52F29645.6010001@thekelleys.org.uk> <874n4dwcdb.fsf@alrua-x1.kau.toke.dk> In-Reply-To: <874n4dwcdb.fsf@alrua-x1.kau.toke.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC. X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:26:10 -0000 On 05/02/14 20:09, Toke Høiland-Jørgensen wrote: > Simon Kelley 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.