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 0F6AC21F1C9 for ; Sun, 9 Feb 2014 04:23:37 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:46879 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 1WCTQ5-0007ak-Pj; Sun, 09 Feb 2014 12:23:33 +0000 Received: from archie.thekelleys.org.uk ([192.168.1.167]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1WCTQ5-00007g-5N; Sun, 09 Feb 2014 12:23:33 +0000 Message-ID: <52F77349.40305@thekelleys.org.uk> Date: Sun, 09 Feb 2014 12:23:37 +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> <52F2BA80.9010202@thekelleys.org.uk> <87iossvgw4.fsf@alrua-x1.kau.toke.dk> <52F369AA.5060809@thekelleys.org.uk> <8761osv78r.fsf@alrua-x1.kau.toke.dk> <52F371B3.5030406@thekelleys.org.uk> <87k3d8mna8.fsf@toke.dk> <52F3A3B2.8020201@thekelleys.org.uk> <87ppmw7ajj.fsf@toke.dk> In-Reply-To: <87ppmw7ajj.fsf@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: Sun, 09 Feb 2014 12:23:37 -0000 On 09/02/14 12:09, Toke Høiland-Jørgensen wrote: > > OK, so I've tried building dnsmasq on cerowrt, from git head. It seems > to have some trouble validating stuff: > > Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: forwarded mail2.tohojo.dk to 213.80.98.2 > Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2 > Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DS] tohojo.dk to 213.80.98.2 > Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DNSKEY] dk to 213.80.98.2 > Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: dnssec-query[DS] dk to 213.80.98.2 > Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: reply dk is BOGUS DS > Sun Feb 9 13:04:24 2014 daemon.info dnsmasq[6456]: validation result is BOGUS > > This is with dnssec-debug turned on. Hmm, that domain validates for me here. It probably makes sense to turn dnssec-debug _off_. One of the things it does is to set the Checking Disabled bit in queries upstream. I'm advised that this is not a good thing to do, since it means the upstream nameserver can return teh first data it finds, even if it doesn't resolve, whilst without CD, the it will keep trying other authoritative servers to get valid data. I don't understand the details, but that would seem applicable here. > > I'm not entirely sure how to go about debugging this, but FWIW this > works: > > $ dig +dnssec +sigchase mail2.tohojo.dk @213.80.98.2 > ...snip... > ;; WE HAVE MATERIAL, WE NOW DO VALIDATION > ;; VERIFYING DS RRset for dk. with DNSKEY:33655: success > ;; OK We found DNSKEY (or more) to validate the RRset > ;; Ok, find a Trusted Key in the DNSKEY RRset: 19036 > ;; VERIFYING DNSKEY RRset for . with DNSKEY:19036: success > > ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS > > > Whereas going through the dnsmasq server fails: > $ dig +dnssec +sigchase mail2.tohojo.dk @10.42.8.1 > ...snip... > ;; WE HAVE MATERIAL, WE NOW DO VALIDATION > ;; VERIFYING DS RRset for tohojo.dk. with DNSKEY:61294: success > ;; OK We found DNSKEY (or more) to validate the RRset > ;; Now, we are going to validate this DNSKEY by the DS > ;; OK a DS valids a DNSKEY in the RRset > ;; Now verify that this DNSKEY validates the DNSKEY RRset > ;; VERIFYING DNSKEY RRset for dk. with DNSKEY:26887: success > ;; OK this DNSKEY (validated by the DS) validates the RRset of the DNSKEYs, thus the DNSKEY validates the RRset > ;; Now, we want to validate the DS : recursive call > > > Launch a query to find a RRset of type DNSKEY for zone: . > > ;; DNSKEYset that signs the RRset to chase: > . 0 IN DNSKEY 256 3 8 AwEAAYRU41/8smgAvuSojEP4jaj5Yll7WPaUKpYvnz2pnX2VIvRn4jsy Jns80bloenG6X9ebJVy2CFtZQLKHP8DcKmIFotdgs2HolyocY1am/+33 4RtzusM2ojkhjn1FRGtuSE9s2TSz1ISv0yVnFyu+EP/ZkiWnDfWeVrJI SEWBEr4V > . 0 IN DNSKEY 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= > . 0 IN DNSKEY 256 3 8 AwEAAb8sU6pbYMWRbkRnEuEZw9NSir707TkOcF+UL1XiK4NDJOvXRyX1 95Am5dQ7bRnnuySZ3daf37vvjUUhuIWUAQ4stht8nJfYxVQXDYjSpGH5 I6Hf/0CZEoNP6cNvrQ7AFmKkmv00xWExKQjbvnRPI4bqpMwtHVzn6Wyb BZ6kuqED > > > > Launch a query to find a RRset of type RRSIG for zone: . > > ;; RRSIG for DNSKEY is missing to continue validation : FAILED > > > > Not really sure what to make of this? OK, you've got to the trust-anchor root keys which are hardwired in as part of the dnsmasq configuration. As such, Dnsmasq assumes they are valid and doesn't need RRSIGs to check their self-signing. As the signatures aren't known, they are not supplied with a query for DNSKEY of the root zone. That may be wrong. When providing trust anchors to eg BIND) is it possible/normal to provide the SIGS too? Cheers, Simon. > > -Toke >