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