[dns-operations] DNSSEC undoing independence of root-zone operators

[Phil Pennock]

On 2011-02-15 at 15:06 -0800, David Conrad wrote:
> Say the Illuminati force VeriSign to remove .US from the root zone and publish it.  

Say that an international spat leads to a removal of .IR based on the
actions of a government other than that of .IR.  Independent sovereign
authority is important, even if "we" don't like that other nation.

> Current solution: resolver operators take action (presumably to reinsert .US (if they care)). 
> 
> End result: multiple name spaces determined by resolver operators.
> 
> Your proposed solution: some number of root server operators refuse to accept the change and resign the old zone with .US still in it, while presumably others (e.g., the ones operated by the USG or their direct contractors) accept the change and sign the .US-less zone.  Remedy: resolver operators modify their hints to use only the root servers they think are doing the right thing.
> 
> End result: multiple name spaces determined by resolver operators.
> 
> What problem are you trying to solve again?

Thank you: that's what I wanted, a no-op change between the previous
solution and the DNSSEC world.

You missed the "DNSSEC without my proposed solution" scenario: some
number of root server operators refuse to accept the change, but can't
re-sign the old zone because they lack the keys.  They can stop
publishing DNSSEC records and lead to resolver failures because of the
lack of a graceful transiation, or they can sign with new keys which
will be rejected by the resolvers as bogus, as DNSSEC does what it's
designed to do.

My proposal doesn't change the protocol.  It preserves the independence
which nominally currently exists, to the same end result.  As long as
everything is fine, the root server operators accept the same master
zone-file, strip DNSSEC signatures so that their own DNSKEY records can
be inserted, and re-sign.  The client tools which auto-update trust
anchors poll all servers currently authoritative, to get the union.

Attack surface is less than it is now, since an attacker needs to get
the keys and the traffic, whereas right now only the traffic is needed;
but yes, this does increase the risk of a key compromise.  Which would
be handled in the same way a key compromise would be right now.

I failed to mention that the granularity of signing is "owner of the IP
address being unicasted/anycasted", not "operator of an anycast
instance".

-Phil