On Sun, Apr 20, 2014 at 11:16:45AM -0400, [email protected] 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 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
