> On Jun 30, 2015, at 8:53 AM, Tony Finch <d...@dotat.at> wrote:
>
> Olafur Gudmundsson <ola...@cloudflare.com> wrote:
>
>> There is much simpler way.
>> Just add record to the rootzone that is only signed by the new key.
>> If resolver returns AD bit it has the new key.
>
> I don't think this works.
>
> If the new key is published in the root zone's DNSKEY RRset then it will
> be signed by the old key, so a validator will have a trust path from a
> stale trust anchor down to the special record (just like it does for
> records signed by ZSKs).
>
> If the new key is not published in the root zone, then you are assuming
> that the validator uses DNSKEY records for its trust anchor configuration
> (but some validators use DS records) and that the validator will allow any
> RRset to be signed by the trust anchor (but RFC 4035 section 5 suggests
> only using the trust anchor to validate the apex DNSKEY RRset).
>
I think it works some of the time i.e.
if one or more of the following are true
a) If the trust anchor is maintained by operator and operator saw advertisement
and acted upon
b) if the new key is advertised by 5011 protocol long before it is rolled and
then removed
c) If the New key is advertised via CDNSKEY and is picked up via trust anchor
maintenance
but most importantly:
d) the Trust anchor is maintained by storing the DNSKEY when possible[*]
So this is not perfect mechanism, will give us an idea how many Validators
picked up the new trust anchor
and then we can start the real propaganda campaign.
My bullet b) is a change from the root key rollover plan that assumes that new
key is added just before it is used.
I would propose that 5011 advertising is done multiple times before the
rollover and the new key is removed during the ZSK rollover,
to allow testing.
I do not yet propose what name or record is used for this experiment but having
it an “address of an object” would be good as that
enables testing from browsers. (CNAME is just as good as an address)
Olafur
Ps: based on my quick check of unbound and Bind both store DNSKEY’s, I do not
know how Nomininum, Microsoft and/or DNSMasq store it. Large public resolvers
like Google are likely to do this via configuration
> Tony.
> --
> f.anthony.n.finch <d...@dotat.at> http://dotat.at/
> Shannon, Rockall, Malin: South 5 to 7, occasionally gale 8 at first in
> Rockall, decreasing 3 or 4. Moderate or rough, occasionally very rough except
> in Malin. Rain then fog patches. Moderate, occasionally very poor.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
