From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (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 BBE5121F19A for ; Sun, 9 Feb 2014 13:07:30 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id e9so9246761qcy.26 for ; Sun, 09 Feb 2014 13:07:29 -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=2sHmqbmQHuYkqRqjv1c11EZ3NeSNnhsSaIhfBJ/96fo=; b=TGvkv7al63BJCvxVNRWBEM25nEkk7nfoxnzbkIkIL86kCMCT/yqQhOCxorG2FDHm94 oZwTj2w/oNuQI1lKf3dIcRiJY1Xxq/zMhhUshrl2BNzZs7tocShIODAyH/ysj1J4Qiws D1Fj4hEiCHKDZN/ex22wXoyBgB7JcINoO/k5EdqYIEkDNe2EceRBuaP6ApdUaCwgm8dj f+9e2tKxwaT4Di6+cY8uRbxT/jJLfhE5PnyFZGvQICrYsThKaGGKoafOHgmd/O61P+kg cv9Vpa0BxWMPF1CxuyseLP6CDj3Hv+0+4frtFxioe5QKDGiz6u4BtaQZ2PGclzCkVXwe DMZA== MIME-Version: 1.0 X-Received: by 10.140.98.135 with SMTP id o7mr39030873qge.102.1391980049663; Sun, 09 Feb 2014 13:07:29 -0800 (PST) Received: by 10.224.27.133 with HTTP; Sun, 9 Feb 2014 13:07:29 -0800 (PST) In-Reply-To: <52F7EC3C.4060505@thekelleys.org.uk> 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> <52F7EC3C.4060505@thekelleys.org.uk> Date: Sun, 9 Feb 2014 13:07:29 -0800 Message-ID: From: Dave Taht To: Simon Kelley 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 21:07:31 -0000 I have been hanging in the webrtc conference room here, of late, generally running the latest google-chrome betas. https://appear.in/bufferbloat On Sun, Feb 9, 2014 at 12:59 PM, Simon Kelley wro= te: > On 09/02/14 12:48, Toke H=F8iland-J=F8rgensen 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-existen= ce >> : 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.d= k >> 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.d= k >> 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 ndo= ts. > 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 process= ing > in dnsmasq that stops queries for DNSKEYS which are known locally is not = the > right thing to do. > > > > > Cheers, > > Simon. > > >> >> -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