From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by huchra.bufferbloat.net (Postfix) with ESMTP id 4091321F13F for ; Sun, 20 Apr 2014 08:41:05 -0700 (PDT) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.8/8.14.8) with ESMTP id s3KFf4XO007973 for ; Sun, 20 Apr 2014 11:41:04 -0400 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU s3KFf4XO007973 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1398008464; bh=DfN3ZELiUrH4hte/gVautTBCt7XoOZ954Lz72nWjgCU=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=j1a7uUW2X8s+X/h++S4IxMCegjBv7xC8XyHzX7Jt8AXefroQCJ51XTj08JDeiVZpz /g1YvlxzkyeVcGW2/SQ36XxvghY8gX+TNjpG6W6BP/P3ldZSwz/w5g6s0u4wCm0uSG rhbc72TronxJ4a3bW0HZPlyozt4+Gek98qq2kVIA= Received: from MX3.WPI.EDU (mx3.wpi.edu [130.215.36.147]) by MAIL1.WPI.EDU (8.14.8/8.14.8) with ESMTP id s3KFf4b5007970 for ; Sun, 20 Apr 2014 11:41:04 -0400 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by MX3.WPI.EDU (8.14.4/8.14.4) with ESMTP id s3KFf3B7006863 for ; Sun, 20 Apr 2014 11:41:04 -0400 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id s3KFf3V0017825 for ; Sun, 20 Apr 2014 11:41:03 -0400 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id s3KFf2F4017824 for cerowrt-devel@lists.bufferbloat.net; Sun, 20 Apr 2014 11:41:02 -0400 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Sun, 20 Apr 2014 11:41:02 -0400 From: Chuck Anderson To: cerowrt-devel@lists.bufferbloat.net Message-ID: <20140420154101.GA16334@angus.ind.WPI.EDU> Mail-Followup-To: cerowrt-devel@lists.bufferbloat.net References: <1c739791-2058-4267-bc41-789496d74faf@email.android.com> <20140413175940.GP16334@angus.ind.WPI.EDU> <20140420140144.GZ16334@angus.ind.WPI.EDU> <157885.1398007005@turing-police.cc.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <157885.1398007005@turing-police.cc.vt.edu> User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [Cerowrt-devel] Full blown DNSSEC by default? 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, 20 Apr 2014 15:41:05 -0000 On Sun, Apr 20, 2014 at 11:16:45AM -0400, Valdis.Kletnieks@vt.edu wrote: > On Sun, 20 Apr 2014 10:01:45 -0400, Chuck Anderson said: > > > The first effect of using a client-side DNSSEC validator is that > > gw.home.lan doesn't work: > > > > Apr 20 00:12:32 a unbound[1885]: [1885:1] info: validation failure : no NSEC3 records from 172.30.42.65 for DS lan. while building chain of trust > > > > To make this work, you have to tell unbound that home.lan is an > > insecure domain: > > > > unbound-control insecure_add home.lan. > > Ouch. > > This wouldn't be so bad, if there was some way to tell it to believe > *your* instance of home.lan, but not trust the babbling of any other > instance you might come across. What we *really* want to do with unbound > is this stuff in the unbound.conf file: > > trust-anchor-file: > File with trusted keys for validation. Both DS and DNSKEY > entries can appear in the file. The format of the file is the > standard DNS Zone file format. Default is "", or no trust > anchor file. > > auto-trust-anchor-file: > File with trust anchor for one zone, which is tracked with > RFC5011 probes. The probes are several times per month, thus > the machine must be online frequently. The initial file can be > one with contents as described in trust-anchor-file. The file > is written to when the anchor is updated, so the unbound user > must have write permission. > > trust-anchor: <"Resource Record"> > A DS or DNSKEY RR for a key to use for validation. Multiple > entries can be given to specify multiple trusted keys, in addi‐ > tion to the trust-anchor-files. The resource record is entered > in the same format as 'dig' or 'drill' prints them, the same > format as in the zone file. Has to be on a single line, with "" > around it. A TTL can be specified for ease of cut and paste, but > is ignored. A class can be specified, but class IN is default. > > trusted-keys-file: > File with trusted keys for validation. Specify more than one > file with several entries, one file per entry. Like > trust-anchor-file but has a different file format. Format is > BIND-9 style format, the trusted-keys { name flag proto algo > "key"; }; clauses are read. It is possible to use wildcards > with this statement, the wildcard is expanded on start and on > reload. > > Having said that, I admit not having in hand an easy way to feed unbound > the needed info. Not sure if 'dig home.lan ds > trust-anchor-here' will do > it, as the unbound on my laptop isn't configured to talk to DNS learned via > DHCP, so home.lan doesn't resolve at all for me... Well, home.lan isn't DNSSEC signed on CeroWrt is it? I don't know how one would manage the private trust anchors needed to make such a setup work, and even then it would have to override the root's NSEC proof of non-existence of "lan." Maybe in the DNSSEC world, such private DNS zones will need to go away and be replaced by real, publically registered DNS zones? I'm using dnssec-triggerd which installs the DHCP nameserver as a forwarder for unbound after checking to make sure it works with DNSSEC: # dnssec-trigger-control status at 2014-04-20 09:26:13 http fedoraproject.org (209.132.181.16): OK cache 172.30.42.65: OK state: cache secure # unbound-control forward 172.30.42.65 # unbound-control list_forwards . IN forward: 172.30.42.65