[Cerowrt-devel] Full blown DNSSEC by default?

[Cerowrt-devel] Full blown DNSSEC by default?

[Dave Taht]

I am delighted that we have the capability now to do dnssec.

I am not surprised that various domain name holders are doing it
wrong, nor that some ISPs and registrars don't support doing it
either. We are first past the post here, and kind of have to expect
some bugs...

but is the overall sense here:

A) we should do full dnssec by default, and encourage users to use
open dns resolvers like google dns that support it when their ISPs
don't?

B) or should we fall back to the previous partial dnssec
implementation that didn't break as hard, and encourage folk to turn
it up full blast if supported correctly by the upstream ISP?

C) or come up with a way of detecting a broken upstream and falling
back to a public open resolver?

Is there a "D"?

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

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

[Török Edwin]

On 04/13/2014 07:26 AM, Dave Taht wrote:
> I am delighted that we have the capability now to do dnssec.
> 
> I am not surprised that various domain name holders are doing it
> wrong, nor that some ISPs and registrars don't support doing it
> either. We are first past the post here, and kind of have to expect
> some bugs...
> 
> but is the overall sense here:
> 
> A) we should do full dnssec by default, and encourage users to use
> open dns resolvers like google dns that support it when their ISPs
> don't?

There are people who don't use Google DNS due to privacy concerns.
Given the choice between not using DNSSEC, and using Google's DNS they might prefer not having DNSSEC.

> 
> B) or should we fall back to the previous partial dnssec
> implementation that didn't break as hard, and encourage folk to turn
> it up full blast if supported correctly by the upstream ISP?
> 
> C) or come up with a way of detecting a broken upstream and falling
> back to a public open resolver?
> 
> Is there a "D"?

There are some tests described here, and a 'dynamic fallback' technique in section 5:
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-00

I think the 'dynamic fallback' can be described in short as: try to use upstream DNS resolver,
and if you don't get the DNSSEC metadata that you expected, *then* eventually fallback to iterating from Root for that metadata.
So then A/AAAA/TXT/NS/etc. records would be answered by upstream, and only for the DNSSEC metadata you would need to iterate
(and you could cache that, or stop iterating if you realize the zone is unsigned as per section 5.1.1)

Best regards,
--Edwin

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

[Toke Høiland-Jørgensen]

> Is there a "D"?

Running a full resolver in cerowrt? I've been running a dnssec-enabled bind for some time on my boxes (prior to dnssec support in dnsmasq).

-Toke

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

[Dave Taht]

On Sun, Apr 13, 2014 at 3:05 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
>> Is there a "D"?
>
> Running a full resolver in cerowrt? I've been running a dnssec-enabled bind for some time on my boxes (prior to dnssec support in dnsmasq).

I had done  quite a few optimizations to  make  running  a full  blown
 bind9 resolver at  home pretty performant  (caching  the  roots,  for
example). I also liked  being   able to  do   full  split dns,  etc.

But:  I  got  fed  up  with doing bind for  a variety of reasons:

A) 4 CERT alerts  in  a  year,   including a  couple nasty ones
B) Too  hard to configure  even for  a wizard
C) Too  hard  to  configure  via  a  web interface
D) People  blocking the roots
E) Would  run  out of flash easily with the  jnl file

So  I  pursued  finding something  (e.g.   dnsmasq)  that  was smaller,
more  integrated,   easier  to  configure,  and  easy on  ram  and   flash.

so  that's dnsmasq  today.  It seems  more  plausible to  continue  to
 improve  dnsmasq than  it is  to dumb down bind.

I do not mind continuing  to  support  and improve optional   bind and
unbound  support for those that want to use them.

> -Toke
>
>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

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

[Dave Taht]

On Sun, Apr 13, 2014 at 12:51 AM, Török Edwin
<edwin+ml-cerowrt@etorok.net> wrote:
> On 04/13/2014 07:26 AM, Dave Taht wrote:
>> I am delighted that we have the capability now to do dnssec.
>>
>> I am not surprised that various domain name holders are doing it
>> wrong, nor that some ISPs and registrars don't support doing it
>> either. We are first past the post here, and kind of have to expect
>> some bugs...
>>
>> but is the overall sense here:
>>
>> A) we should do full dnssec by default, and encourage users to use
>> open dns resolvers like google dns that support it when their ISPs
>> don't?
>
> There are people who don't use Google DNS due to privacy concerns.
> Given the choice between not using DNSSEC, and using Google's DNS they might prefer not having DNSSEC.

Good point.

Well  there is also dnscrypt and opendns. There's a (broken) dnscrypt
packaging attempt in ceropackages.

>
>>
>> B) or should we fall back to the previous partial dnssec
>> implementation that didn't break as hard, and encourage folk to turn
>> it up full blast if supported correctly by the upstream ISP?
>>
>> C) or come up with a way of detecting a broken upstream and falling
>> back to a public open resolver?
>>
>> Is there a "D"?
>
> There are some tests described here, and a 'dynamic fallback' technique in section 5:
> http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-00
>
> I think the 'dynamic fallback' can be described in short as: try to use upstream DNS resolver,
> and if you don't get the DNSSEC metadata that you expected, *then* eventually fallback to iterating from Root for that metadata.

Which only works for a full blown local resolver. In the dnsmasq case
the switch would have to be  another open dns resolver.

We could iterate over a list of open dns resolvers to find the best one.

> So then A/AAAA/TXT/NS/etc. records would be answered by upstream, and only for the DNSSEC metadata you would need to iterate
> (and you could cache that, or stop iterating if you realize the zone is unsigned as per section 5.1.1)

Maybe there could be a "dnssec-fallback-resolver" setting in dnsmasq,
that it could fall back to if a known-not-to-resolve-properly domain
can't do a proof of non-existence properly?

bork.bork.bork.bork.example.org

> Best regards,
> --Edwin
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

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

[dpreed]

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


I'd be for A.  Or C with a very, very strong warning that would encourage users to pressure their broken upstream.  Users in China will never not have a broken upstream, of course, but they know that already... :-)
 
Similarly, I hope we don't have Heartbleed in our SSL.  Maybe we should put a probe in Cero's SSL that tests clients to see if they have Heartbleed fixed on their side, and warns them.
 
Any DNS provider that doesn't do DNSSEC should be deprecated strongly (I'm pretty sure OpenDNS cannot do so, since it deliberately fakes its lookups, redirecting to "man in the middle" sites that it runs).
 


On Sunday, April 13, 2014 12:26am, "Dave Taht" <dave.taht@gmail.com> said:



> I am delighted that we have the capability now to do dnssec.
> 
> I am not surprised that various domain name holders are doing it
> wrong, nor that some ISPs and registrars don't support doing it
> either. We are first past the post here, and kind of have to expect
> some bugs...
> 
> but is the overall sense here:
> 
> A) we should do full dnssec by default, and encourage users to use
> open dns resolvers like google dns that support it when their ISPs
> don't?
> 
> B) or should we fall back to the previous partial dnssec
> implementation that didn't break as hard, and encourage folk to turn
> it up full blast if supported correctly by the upstream ISP?
> 
> C) or come up with a way of detecting a broken upstream and falling
> back to a public open resolver?
> 
> Is there a "D"?
> 
> --
> Dave Täht
> 
> NSFW:
> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 2514 bytes --]

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

[Dave Taht]

On Sun, Apr 13, 2014 at 9:16 AM,  <dpreed@reed.com> wrote:
> I'd be for A.  Or C with a very, very strong warning that would encourage
> users to pressure their broken upstream.  Users in China will never not have
> a broken upstream, of course, but they know that already... :-)

I'd be very much for A except that I'd like somehow a failure to resolve
due to a dnssec problem to return a pointer to something, somehow
that informs the user as to what went wrong and what to do about it.

> Similarly, I hope we don't have Heartbleed in our SSL.

All versions of cerowrt prior to 3.10.36-3 potentially had heartbleed
in the https admin interface, and also possibly hostapd (though I
don't know how to exploit it). The optional wpa_supplicant, openvpn,
strongswan, authsae packages also were affected and a few others I
forget.

More scarily - from a large deployment perspective, things like the
radsec radius backend also use TLS security to carry authentication
info back to a radius server.

All of openwrt, dd-wrt, etc from Attitude Adjustment to trunk to about
12 hours after the disclosure were vulnerable.  Patches went into the
relevant repositories but it's going to be very hard to push updates
out to the field, since no update mechanism exists for most embedded
products.

Boingo has sent out a mail to all customers saying they were not
affected, but I do worry a lot about the overall security of
enterprise wifi and 802.1x ethernet networks in general.

> Maybe we should put
> a probe in Cero's SSL that tests clients to see if they have Heartbleed
> fixed on their side, and warns them.

I'd like more probes and defenses in general, notably things that detect
dns amplification attempts and send them somewhere to be collected,
some sort of universal moon worm attempt detector/reporter, and the
equivalent of a rbl database for attacks and potential attackers.


> Any DNS provider that doesn't do DNSSEC should be deprecated strongly (I'm
> pretty sure OpenDNS cannot do so, since it deliberately fakes its lookups,
> redirecting to "man in the middle" sites that it runs).

Concur. On the one hand I was happy with the idea of dnscrypt, but not
happy that the backend couldn't do dnssec right.

> On Sunday, April 13, 2014 12:26am, "Dave Taht" <dave.taht@gmail.com> said:
>
>> I am delighted that we have the capability now to do dnssec.
>>
>> I am not surprised that various domain name holders are doing it
>> wrong, nor that some ISPs and registrars don't support doing it
>> either. We are first past the post here, and kind of have to expect
>> some bugs...
>>
>> but is the overall sense here:
>>
>> A) we should do full dnssec by default, and encourage users to use
>> open dns resolvers like google dns that support it when their ISPs
>> don't?
>>
>> B) or should we fall back to the previous partial dnssec
>> implementation that didn't break as hard, and encourage folk to turn
>> it up full blast if supported correctly by the upstream ISP?
>>
>> C) or come up with a way of detecting a broken upstream and falling
>> back to a public open resolver?
>>
>> Is there a "D"?
>>
>> --
>> Dave Täht
>>
>> NSFW:
>>
>> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

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

[Toke Høiland-Jørgensen]

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

Dave Taht <dave.taht@gmail.com> writes:

> Boingo has sent out a mail to all customers saying they were not
> affected, but I do worry a lot about the overall security of
> enterprise wifi and 802.1x ethernet networks in general.

FWIW the 802.1x authentication usually works in one of two modes:
MSCHAPv2 which is Microsoft's challenge/response protocol that never
ships passwords over the wire (setups that authenticate against an
Active Directory, or people who want to support windows clients natively
will run in this mode), or EAP-TTLS which has a second end-to-end TLS
tunnel from the wireless client all the way back to the authentication
server. Presumably the latter will also be vulnerable to heartbleed
until updated, but at least there's another layer of turtles there.

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

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

[Chuck Anderson]

On Sun, Apr 13, 2014 at 12:05:19PM +0200, Toke Høiland-Jørgensen wrote:
> 
> > Is there a "D"?
> 
> Running a full resolver in cerowrt? I've been running a dnssec-enabled bind for some time on my boxes (prior to dnssec support in dnsmasq).

How do these proposals compare with unbound+dnssec-trigger in the
Fedora world?  I stirred up a rats nest:

https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html

I realize these are slightly different use cases, but it may be
helpful to learn from the different implementations, if for no other
reason than to be sure they interoperate.  I'm going to turn on
unbound+dnssec-trigger on my laptop and try it behind Cerowrt w/DNSSEC
turned on to see what happens...

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

[Dave Taht]

On Sun, Apr 13, 2014 at 10:59 AM, Chuck Anderson <cra@wpi.edu> wrote:
> On Sun, Apr 13, 2014 at 12:05:19PM +0200, Toke Høiland-Jørgensen wrote:
>>
>> > Is there a "D"?
>>
>> Running a full resolver in cerowrt? I've been running a dnssec-enabled bind for some time on my boxes (prior to dnssec support in dnsmasq).
>
> How do these proposals compare with unbound+dnssec-trigger in the
> Fedora world?  I stirred up a rats nest:
>
> https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html

Oh, did you! I'm reluctant to join that enormous thread, but there
have been couple things stated that aren't quite correct.

0) I agree that dnsmasq needs to be tested a lot more before it's
dnssec implementation can be as trusted as much as unbound's or
bind's.

1) dnsmasq is used by ubuntu by default (at least), and it's at least
semi-integrated with network manager in that case over the dbus.

So far as I know the caching functionality in dnsmasq in that instance
is disabled due to fears about cache poisoning, that I don't fully
understand. My half understood fear translates into equivalent fears
for other local dns daemons.

2) Benchmarks like namebench can show the value of the local cache,
shaving milliseconds off of local queries across the network.

I have generally had servers have their own bind daemon for about 16
years - it helps, especially if you like to do reverse lookups.

3) I heartily approve of alternate dns servers like unbound or bind
being used by various distros of choice - a monoculture is not what is
needed here! Support and integration into NM for all of them would be
great.

4) dnsmasq is now fully capable of obsoleting resolv.conf.auto cleverly
and dealing with at least some vagaries of vpns.

> I realize these are slightly different use cases, but it may be
> helpful to learn from the different implementations, if for no other
> reason than to be sure they interoperate.  I'm going to turn on
> unbound+dnssec-trigger on my laptop and try it behind Cerowrt w/DNSSEC
> turned on to see what happens...

I was unaware of the dnssec-trigger stuff, which makes sense
especially on mobiles transiting captive-portal environments.

I would also like openwrt's captive portal stuff to work better.

I was also unaware of unbound's clever suspend resume support
for clearing the local cache.

> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

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

[Aaron Wood]

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

>
> So far as I know the caching functionality in dnsmasq in that instance
> is disabled due to fears about cache poisoning, that I don't fully
> understand. My half understood fear translates into equivalent fears
> for other local dns daemons.


Which isn't near the issue that application-level caching is.  It seems to
be slowly getting better, but I've seen numerous apps (especially in
embedded space) cache resolved addresses seemingly forever.  We found this
at my day-job when dealing with dns-based failover between servers.

I greatly prefer to disable application-layer caching entirely, and rely on
a central caching resolver like dnsmasq in those environments (where we're
running local to dnsmasq, so it's very fast).

-Aaron

[-- Attachment #2: Type: text/html, Size: 1046 bytes --]

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

[Simon Kelley]

On 14/04/14 00:24, Dave Taht wrote:
>
> 
> So far as I know the caching functionality in dnsmasq in that instance
> is disabled due to fears about cache poisoning, that I don't fully
> understand. My half understood fear translates into equivalent fears
> for other local dns daemons.
> 

My understanding is that this relates to multi-user systems where the
users share the cache  and run on the local machine.

Essentially, if I can generate cache misses at will, ie by making
queries, then I can synchronously flood the DNS cache with bogus answers
to the query. Source-port randomisation doesn't help: a simple netstat
or equivalent will tell me that, so the only protection is the 16-bit
query-id, which is no protection at all: 64k UDP packets via the
loopback interface can easily arrive before one from the wider internet.

That allows a user to poison his own DNS, but if the cache is shared,
then it allows him to also poison the DNS of any other user on the machine.

The solution is per-user caches.


Simon.

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

[Dave Taht]

On Thu, Apr 17, 2014 at 2:01 PM, Simon Kelley <simon@thekelleys.org.uk> wrote:
> On 14/04/14 00:24, Dave Taht wrote:
>>
>>
>> So far as I know the caching functionality in dnsmasq in that instance
>> is disabled due to fears about cache poisoning, that I don't fully
>> understand. My half understood fear translates into equivalent fears
>> for other local dns daemons.
>>
>
> My understanding is that this relates to multi-user systems where the
> users share the cache  and run on the local machine.
>
> Essentially, if I can generate cache misses at will, ie by making
> queries, then I can synchronously flood the DNS cache with bogus answers
> to the query. Source-port randomisation doesn't help: a simple netstat
> or equivalent will tell me that, so the only protection is the 16-bit
> query-id, which is no protection at all: 64k UDP packets via the
> loopback interface can easily arrive before one from the wider internet.
>
> That allows a user to poison his own DNS, but if the cache is shared,
> then it allows him to also poison the DNS of any other user on the machine.
>
> The solution is per-user caches.

That is an interesting factoid to add to the discussion over on the
fedora list... does unbound do this?

>
>
> Simon.
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

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

[Chuck Anderson]

On Sun, Apr 13, 2014 at 01:59:41PM -0400, Chuck Anderson wrote:
> On Sun, Apr 13, 2014 at 12:05:19PM +0200, Toke Høiland-Jørgensen wrote:
> > 
> > > Is there a "D"?
> > 
> > Running a full resolver in cerowrt? I've been running a dnssec-enabled bind for some time on my boxes (prior to dnssec support in dnsmasq).
> 
> How do these proposals compare with unbound+dnssec-trigger in the
> Fedora world?  I stirred up a rats nest:
> 
> https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html
> 
> I realize these are slightly different use cases, but it may be
> helpful to learn from the different implementations, if for no other
> reason than to be sure they interoperate.  I'm going to turn on
> unbound+dnssec-trigger on my laptop and try it behind Cerowrt w/DNSSEC
> turned on to see what happens...

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.

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

[Valdis.Kletnieks]

[-- 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 --]

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

[Chuck Anderson]

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