[Unbound-users] Delegation-only zones and non-root zone RFC 5011?

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Viktor,

On 20/01/15 05:32, Viktor Dukhovni wrote:
> On Mon, Jan 19, 2015 at 10:21:36AM +0000, Tony Finch wrote:
> 
>>>> On Sat, Jan 17, 2015 at 10:08:48PM +0000, Viktor Dukhovni
>>>> wrote:
>>>> 
>>>>> Also, how would one configure unbound to use an
>>>>> auto-trust-anchor-file via RFC 5011 for a given gTLD or
>>>>> ccTLD?

$ dig mytld DNSKEY > mytld.key
# check if key is trustworthy
# add a line to unbound.conf:
auto-trust-anchor-file: "mytld.key"

>>>> Any comment on my second question?  If one enables RFC 5011
>>>> tracking for all the trust anchors one cares about, it is no
>>>> longer necessary to worry about delegation-only above those
>>>> trust anchors.
>> 
>> I don't know of any zones other than the root which promise to
>> follow the RFC 5011 key rollover timing requirements. (And even
>> the root zone does it wrong by not having a standby KSK.)
>> 
>> If you want to use RFC 5011 on a TLD you will have to inspect
>> their DNSSEC Practice Statement with care.
> 
> Yes of course, that makes sense.  We're may not be quite there
> yet. And yet at some point this may become more important, and so
> the question is whether unbound is ready to support such non-root
> zones if when they show up...

You can add them into the config file with the auto-trust-anchor-file
statement.  You can repeat this statement in the config file to add
more trust anchors.

> I can, for example, envision the ".de" TLD adopting such a policy, 
> and interested resolvers starting to track those keys per RC 5011, 
> thereby closing opportunities for the root zone keys to return 
> improper .de answers.

If you have nested trust anchors, unbound uses the closest one by
preference (i.e. exactly what you say that you want).

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUvh7yAAoJEJ9vHC1+BF+NmWYP/RZVnth+p5MsdGA+XZpWhZpu
1xwg+BiuFznExmXl4mx2lbXmL61agRPC9zudaInnyeLDsVnjx0zaHStXmISVCaX+
91k+lGv0EAgee2Af8zJ/O7rUrUI4MTvejprSeI9jQmJ81hh4WGoRT3qH3Bo72BVL
mGcWpxz+au5QSiz4RqkIU1rHEQb6DQR6MlrEZL6ileBmoZT8LJXaco/PK0TFssbY
ueqWRGDAMYFXU3PYutz08meSx1iQeKrsQ9fLCDOA1w/I0WA/NuNuHH/4hcUuhTh6
suBITGy8t+7NHeUkAkCB2d0NvP948ndzgG7TNtuMC/yVrYE52zISQ7bffXBZ4xXq
+LtMVf+LcTmKxCti+wT2z0MLps41O5BP8omIoblB42l71wfoE0GQI9UQKln42FmF
hvFw6faH/qAVtW/8RTMwGExg+Gee14GeMIr/l0BFwUFaiMdseT1oKCgzvYum50FA
CNHzJKkcWZa/hm4KhKQyV3u6hRiIzPgNHMl4wk031XiGfPYOw1Pr0/AfoD+Am10K
SmamWlDhRuPrMzqjjS5nHwa5a6yoTsWbSRNrOV+ZaxxVP+voZDFvnKhqWIGMybR/
FG7CaexWTmZr2J+QkdIC63SoCPXxDsxKlEYstwpB8sjiMa32xDi4ndscMMXK0vWS
gVaZkYhYopyvxOm7wBDH
=rzo0
-----END PGP SIGNATURE-----