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

Phil Pennock dnsop+phil at spodhuis.org
Wed Feb 16 01:01:45 UTC 2011


On 2011-02-15 at 18:10 -0500, Andrew Sullivan wrote:
> Suppose some root server operators wanted break away.  Prior to
> DNSSEC, they had to get others to accept their alternate root.hints
> file and use it, or else somehow inject poison such that people
> started using their alternative answers.

No, prior to DNSSEC they just continued publishing a complete root zone
(as regards delegations, not as regards NS records for the root) on
their existing IP address and resolver operators get to choose whether
or not to drop the censored root servers from their start-up hints file,
to ensure they can consistently lock onto the uncensored set.

> Today, now that everything is signed, what they have to do is get
> people also to accept their alternate trust anchor.  DNSSEC will work
> as long as there is a valid signature chained from at least one
> configured trust anchor.  So if people accept the alternate-root-TA,
> then signed responses from those alternate root people will also work.

And my proposal is that the alternate trust anchors all exist in
parallel, signing the same content (excepting DNSKEY on .) and client
tools which currently fetch the one DNSSEC signing key instead fetch one
per root server IP address.

In the event of a split, the server operators continue on the same IP,
as before, using the same key they were already using, strip out the
censored NS, as before, and the only action needed by the resolver
operators is to remove the IP addresses of the censored servers, as
before.

Sorting out a new trust anchor is a significant barrier, especially
since a large percentage of private resolver operators don't really
understand even DNS.

My intent is to preserve the pre-DNSSEC status quo of independence,
including the pre-DNSSEC status of just accepting the one zonefile as
being the sanest solution, barring very good cause not to.

-Phil



More information about the dns-operations mailing list