From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 63AA521F1A7 for ; Sun, 9 Feb 2014 10:04:57 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id cm18so8198621qab.37 for ; Sun, 09 Feb 2014 10:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qqBFerd7tIRo+bIISHEFayfvGOK3dnfZUxSyNk/thlU=; b=E/BMcKoFa+02Pzfx6uzveffhdM+X9ICcm3Fyn6UTd3fl/ifnlRrQLANYN5jnN+g9RC E3BN0kBxlojWGdRT1N9dAZ56T1C7U576rEa3iHNjBErLAFJJI43/YLeg/kNRCJVJHAwe QpzaQNz1epA67zJHbZy7vJCyTwXzaxSfYeE5sGtg4btjKtXMR18N1VojOvaRsWu1B6y8 zilOYDVYymFgg/HTOBjU9Ob18UsCpVTiSJ9IeNKi3LhpwCdFvUSJPcr3n4mMccoNz9+C PKNYEFVUXUC9lc8mUTr2KNaXvG9rN850JxTb9lDogtwRGfUV/hp/7RlgDpLGXZP6AqIY f57Q== MIME-Version: 1.0 X-Received: by 10.229.41.67 with SMTP id n3mr23935376qce.6.1391969096148; Sun, 09 Feb 2014 10:04:56 -0800 (PST) Received: by 10.224.27.133 with HTTP; Sun, 9 Feb 2014 10:04:55 -0800 (PST) In-Reply-To: <87lhxk78pa.fsf@toke.dk> 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> Date: Sun, 9 Feb 2014 10:04:55 -0800 Message-ID: From: Dave Taht To: =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 18:04:57 -0000 Got the right time? I have no idea how to deal with the time headache still, besides adding an un-validating-resolver to ntpdate, and sanity checks in dnsmasq like (if system time is < my build time, don't do dnssec) - but the latter is imperfect. http://www.bufferbloat.net/issues/113 On Sun, Feb 9, 2014 at 4:48 AM, Toke H=F8iland-J=F8rgensen w= rote: > 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-existenc= e : FAILED > > ;; Impossible to verify the Non-existence, the NSEC RRset can't be valida= ted: 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.tohoj= o.dk to 213.80.98.3 > Sun Feb 9 13:45:22 2014 daemon.info dnsmasq[6698]: forwarded mail2.tohoj= o.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] toho= jo.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 t= o 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.tohoj= o.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] toho= jo.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 t= o 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? > > > > 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.d= k.karlstad.toke.dk is NXDOMAIN > > This is probably not desirable? > >> 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 h= ere: > > http://ftp.isc.org/isc/bind9/keys/9.8/ > > -Toke > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html