[dns-operations] TLD zones with lame servers

[Kim Davies]

Quoting Jim Reid on Monday June 10, 2019:
> 
> No Mark, they don’t. They shouldn’t either.
>
> For these issues, IANA can *only* listen to the ccTLD’s formal
> technical & admin contacts (and/or the Sponsoring Organisation). This is
> a matter of national sovereignty.
>
> IANA can’t act unilaterally in these cases. That would require a
> consensus policy at ICANN and such a policy does not exist. If you think
> such a thing is needed, go ahead and create one. ICANN’s policy-making
> machinery is open to all.
>
> Please also think about the long-term consequences of IANA becoming
> the TLD police. Could/should IANA delete the NS record for some TLD
> because it didn’t like the hostname or the choice of DNS software or
> how it’s configured or where the server is located or if it had an IPv6
> address or if it didn’t use the latest EDNS options or....

I am choosing this as a convenient point to jump on this thread to add a few
details about what IANA does and doesn't do, and why.

* National sovereignty plays a factor insofar as it is fundamentally a
  local decision who the manager of a ccTLD is. I do not consider that to
  consequently mean ccTLD managers have the unique privilege to define
  every aspect, and it is appropriate to have management processes
  around that that require certain technical and other procedural requirements
  to be met. For example, a country may come to consensus that a party should
  be their ccTLD manager, but they still need to demonstrate operational
  competency in order for the IANA process to allow them to receive the
  formal delegation.

* The general (unstated) principle that defines how we manage the root zone
  delegations is "be reactive". This means we wait for change requests
  to be submitted to us and we process them accordingly, which includes
  requiring consent from the TLD manager for the change. Our technical
  checks are applied at the time of a change request, but if you do not
  make a root zone change there is no ongoing requirement to maintain that
  with some caveats. While we do informally nudge ccTLD operators when we
  become apprised of issues, there is no standing procedure to seek out
  such issues in our day-to-day operations.

* We briefly, in the distant past, experimented with proactively monitoring
  the accuracy of delegations to detect lame delegations or other mismatches
  against the data in the root zone. The response back then was IANA was
  straying from its remit. Now, that was a very different time and almost
  every consideration that would go into the calculus there is different
  today so it may be worth reassessing if that is still the right approach.

* To Mark's comment about the rights of nameserver operators: for
  IANA to recognize nameserver operators in their own right would be
  a fundamental shift to the trust model for the root zone. We don't
  have first-class "host objects" with contact points attached to
  them, all changes to nameservers are communicated through a TLD
  manager that utilizes the host in their NS-set. Today we expect the
  relationship between the TLD manager and their vendor that provides
  them authoritative nameservice to be bilateral between the two of
  them. I appreciate this isn't particularly satisfactory if a third
  party authority severs its relationship with the TLD, but the risk
  of that situation needs to be contrasted against the opposite risk
  where a vendor unexpectedly goes modifying TLD records without proper
  coordination with the TLD manager. I'd also add the trend is that many
  TLDs use in-bailiwick hostnames that are unique to that TLD, so the
  population of nameservers where the vendor controls the hostname in the
  NS-set is likely small and shrinking.

* One of the benefits of the current model is that our procedure 
  essentially requires a requester to prove custody of the zone to effect a 
  root zone change. i.e. we expect the new NS-set to published in the child
  prior to the root; we expect a new DNSKEY to be published in the child
  prior to the DS being placed in the root zone; we expect the authoritative
  A/AAAA records for a host to be updated prior to a glue change. Allowing
  NS-set changes to be made without a corresponding change to the child
  zone (in order to allow third-parties to make changes) would weaken this
  protection.

kim