Re: [DNSOP] Verifying TLD operator authorisation

[Jim Reid <[e-mail]>]

> On 18 Jun 2019, at 11:13, Bjarni Rúnar Einarsson <[e-mail]> wrote:
> 
> The SOA record for a TLD contains two DNS names which should be
> under the control of the NIC ...
> People on this list can probably comment on whether my above
> assumption is correct, and whether those are good candidates for
> what you have in mind.

Being able to control a zone’s SOA record (or whatever) means just that. No more, no less. It doesn’t mean someone who has that ability also has the authority to change the zone’s delegation even though they can manipulate the zone contents.

Consider a registry that outsources authoritative DNS service. For instance one of the slave servers for .is could mess about with their copy of the zone file. [Admittedly breaking DNSSEC validation unless they also had access to the appropriate private key.] Modifying the SOA record doesn’t give that misbehaving slave provider authority to go to IANA and get the .is delegation changed even if they can make the SOA record or whatever “look right” in support of their bogus change request.

2FA on changes to TLD delegations is a good thing. However I doubt this can be done safely through a mechanism that relies on a magic token being present or absent from the TLD itself. That approach changes the threat model and introduces new attack vectors. These need careful consideration and testing. DNSSEC signing helps of course but isn’t necessarily a magic bullet: suppose the registry has also outsourced TLD signing.