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 26A6221F214 for ; Sun, 9 Feb 2014 12:59:46 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:47420 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 1WCbTa-0001qm-Rh; Sun, 09 Feb 2014 20:59:43 +0000 Received: from spike.thekelleys.org.uk ([192.168.0.193]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1WCbTZ-0004zV-2N; Sun, 09 Feb 2014 20:59:41 +0000 Message-ID: <52F7EC3C.4060505@thekelleys.org.uk> Date: Sun, 09 Feb 2014 20:59:40 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20120726 Icedove/3.0.11 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> <52F77349.40305@thekelleys.org.uk> <87lhxk78pa.fsf@toke.dk> In-Reply-To: <87lhxk78pa.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 20:59:46 -0000 On 09/02/14 12:48, Toke Høiland-Jørgensen wrote: > Simon Kelley writes: > >> 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. > > Well, turning off dnssec-debug just means I have no name resolution for > such domains: > > $ dig +dnssec +sigchase mail2.tohojo.dk @10.42.8.1 :( > ;; NO ANSWERS: no more > We want to prove the non-existence of a type of rdata 1 or of the zone: > ;; nothing in authority section : impossible to validate the non-existence : FAILED > > ;; Impossible to verify the Non-existence, the NSEC RRset can't be validated: FAILED > > $ host mail2.tohojo.dk 10.42.8.1 > Using domain server: > Name: 10.42.8.1 > Address: 10.42.8.1#53 > Aliases: > > Host mail2.tohojo.dk not found: 3(NXDOMAIN) > > > And the dnsmasq logs: > > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: query[A] mail2.tohojo.dk from 10.42.8.106 > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: forwarded mail2.tohojo.dk to 213.80.98.3 > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: forwarded mail2.tohojo.dk to 213.80.98.2 > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2 > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: dnssec-query[DS] tohojo.dk to 213.80.98.2 > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: dnssec-query[DNSKEY] dk to 213.80.98.2 > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: dnssec-query[DS] dk to 213.80.98.2 > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: reply dk is BOGUS DS > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: validation result is BOGUS > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: reply mail2.tohojo.dk is 144.76.141.112 > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: query[A] mail2.tohojo.dk from 10.42.8.106 > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: forwarded mail2.tohojo.dk to 213.80.98.2 > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: dnssec-query[DNSKEY] tohojo.dk to 213.80.98.2 > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: dnssec-query[DS] tohojo.dk to 213.80.98.2 > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: dnssec-query[DNSKEY] dk to 213.80.98.2 > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: dnssec-query[DS] dk to 213.80.98.2 > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: reply dk is BOGUS DS > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: validation result is BOGUS > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: reply mail2.tohojo.dk is 144.76.141.112 > > It works on my other machine that's not running on cerowrt; so perhaps > it's something architecture-specific? It's possible, indeed that's happened during testing. Dave, could you talk me through getting the latest dnsmasq package on the 3800 you gave me? Note that here, the inception time for the signature of the DS is 20140208022128, UTC ie late yesterday. Are you sure your clock is correct, time and _date_? Please clould you post the result of running dig @213.80.98.2 +dnssec ds dk just to check you're getting the same data. 213.80.98.2 won't talk to me. > > > > Interestingly, after failing a DNSSEC resolution, dnsmasq then tries to > append the configured domain: > > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: query[A] mail2.tohojo.dk.karlstad.toke.dk from 10.42.8.106 > Sun Feb 9 13:45:32 2014 daemon.info dnsmasq[6698]: config mail2.tohojo.dk.karlstad.toke.dk is NXDOMAIN > > This is probably not desirable? That's not dnsmasq, it's the resolver in 10.42.8.106, probably because /etc/resolv.conf has a search path configured and the wrong value for ndots. See man resolv.conf for details. > >> 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? > > I suppose it does (?). The file usually supplied with BIND is available here: > > http://ftp.isc.org/isc/bind9/keys/9.8/ OK, so they're not hardwiring them either. Maybe the special-case processing in dnsmasq that stops queries for DNSKEYS which are known locally is not the right thing to do. Cheers, Simon. > > -Toke