[dns-operations] TLD zones with lame servers

[Rubens Kuhl]

> 
> * 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.

I believe this could be reconsidered, and suggest it to be brought up with IANA CSC (Customer Standing Committee). 

> 
> * 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.

I also see this should be handled with due care on the policy side, and I believe that only after a long time not answering with authority (1 month or more) the possibility of removal of an entry could be entertained. 
On the in x off controls, it seems that those issues reported occur more  with NS-set from off-TLD name-servers, so it would still be worthwhile because the small shrinking fraction contributes to most if not all lame delegations. 

> 
> * 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.


In this case, if the operator removes a delegation from the child zone, would IANA be willing to consider removing it as well from the delegation without explicit request, after giving a right to refuse to operator ? Note that the timing mitigation would still apply: long time not working. 




Rubens