Re: [Cerowrt-devel] Full blown DNSSEC by default?

[Chuck Anderson <cra@WPI.EDU>]

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 <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...

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