This 'trust-anchor' should ideally be the root. If there is no signed root, then all DNS clients that want to verify zone data will have to manually configure the zone keys, and maintenance of these keys is a process that does not scale well. The IETF is currently working on a solution to this issue.
Operators that configure 'trust-anchors' into their validating DNS clients will need to be conscientious about maintaining them. The 'trust-anchor' and the Key Signing Key (KSK) used to sign the zone must remain synchronised. If operators do not update their keys, then their zones might become invisible to DNS clients performing DNSSEC validation.
To avoid possible failures, the RIPE NCC we will sign the e164.arpa zone according to the policy below:
The KSKs for the ENUM zone which is to be used as a 'trust-anchor' will be published on a secure website. We will follow the format used in the 'trusted-keys' statement in BIND9 named configuration files.
Changes to this procedure, as well as any other announcements from the RIPE NCC, will be signed with our PGP key and published on our secure website and the ENUM-WG mailing list.
All key rollover events will be announced one week in advance on the ENUM-WG mailing list.