Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu
To: Chuck Anderson <cra@WPI.EDU>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Full blown DNSSEC by default?
Date: Sun, 20 Apr 2014 11:16:45 -0400	[thread overview]
Message-ID: <157885.1398007005@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Sun, 20 Apr 2014 10:01:45 -0400." <20140420140144.GZ16334@angus.ind.WPI.EDU>

[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]

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 <gw.home.lan. A IN>: 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: <filename>
              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: <filename>
              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: <filename>
              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...

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]

  reply	other threads:[~2014-04-20 15:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-13  4:26 Dave Taht
2014-04-13  7:51 ` Török Edwin
2014-04-13 15:04   ` Dave Taht
2014-04-13 10:05 ` Toke Høiland-Jørgensen
2014-04-13 14:57   ` Dave Taht
2014-04-13 17:59   ` Chuck Anderson
2014-04-13 23:24     ` Dave Taht
2014-04-14  9:29       ` Aaron Wood
2014-04-17 21:01       ` Simon Kelley
2014-04-17 21:19         ` Dave Taht
2014-04-20 14:01     ` Chuck Anderson
2014-04-20 15:16       ` Valdis.Kletnieks [this message]
2014-04-20 15:41         ` Chuck Anderson
2014-04-13 16:16 ` dpreed
2014-04-13 16:40   ` Dave Taht
2014-04-13 17:57     ` Toke Høiland-Jørgensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=157885.1398007005@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=cra@WPI.EDU \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox