From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 50E8B21F18A for ; Wed, 5 Feb 2014 12:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 57C2815DAA; Wed, 5 Feb 2014 21:09:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1391630946; bh=zp/xI9/i+7w0cQ2a6lUAHZklLK9HjeSWWyrHtOpetFg=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=aTT5bfsHMHHUUyMHjBc8lYFaKrogwn7KxVFZRwx2EgMvs6hWUzvv3q+5WWB7/5D+Y N1YjvWuM3SD1/oSjYkmGSYbxjqW/sEEHhMBE1XKYBR6q3F/Ogo9I+OCKlc2dI3iucv sdm7UwXw+zi6NQfiJpHSNLpCwOV9L2anm4sjaGXw= From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Simon Kelley References: <87a9e6xcae.fsf@alrua-x1.kau.toke.dk> <87ob2lmqny.fsf@toke.dk> <52F29645.6010001@thekelleys.org.uk> Date: Wed, 05 Feb 2014 21:09:04 +0100 In-Reply-To: <52F29645.6010001@thekelleys.org.uk> (Simon Kelley's message of "Wed, 05 Feb 2014 19:51:33 +0000") Message-ID: <874n4dwcdb.fsf@alrua-x1.kau.toke.dk> Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" 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 20:09:41 -0000 --=-=-= Content-Type: text/plain 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?). > It does two things, the results of which are not externally obvious. > > 1) It sets the cd (checking disabled) bit in upstream queries, so that > it's possible to check that invalid data is identified, rather than > just getting a SERVFAIL from the upstream server. > > 2) It suppresses SERVFAIL as the reply to queries whose answer doesn't > verify, for similar reasons. Right; I was assuming it would increase the log output, similar to dig +trace or something... -Toke --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJS8ppgAAoJEENeEGz1+utPRQgH+weZ828omF+2AWDpGqULSBe3 l2L4WuCcIDPZPd9FbWHh9kwtdKU8/E74mxQsmjgbTLnWEQRmTs1KZ7KyDgycSpUz yRO+g+1y+U2lsjZRQD/7m1P2aIDmcd678sFtXi7ED0/xs56Huej/thpIj85CM1oW pyqd7O+mKffd4NgE5gRHxc0TRycotDqv432uQLYtexlpDl9P3oxFAaVcH0KiZBmE LhW3b+LrzspY87vBIN9mgDXxNptz9yvo7KpQ8iFjqklRc8RNm+eEI/OPeMBgz58F vo/NpIMUjLqHpYVycO43JNrCHcDXG9wn6ez8oQxpmiZSEA6NRzHYS+e5lDzvoIk= =wRuX -----END PGP SIGNATURE----- --=-=-=--