Process for handling TLD delegation changes
While I welcome a document on the procedure for changing TLD delegations in the root zone, some aspects of the proposal are disconcerting. In particular the section headed "IANA Procedures for Removing Problematic Delegation Data" is troublesome. This may be simply a matter that needs more clarification. However the current text seems to be suggesting IANA takes on responsibilities that are probably beyond its scope. The proposal appears to say that in certain (unspecified) circumstances, IANA may remove or change a TLD's glue or NS records without the knowledge or approval of the TLD owner. This presents a number of potentially serious technical, operational and policy problems. [1] IANA has a clear role as the registry for the root zone. As such it should not be making value judgements about the existing delegation data for some TLD. That is largely a decision for the TLD operator. This is even more important when the criteria used for these judgements are not documented and the circumstances when they may be applied are unclear. Furthermore, IANA should not be determining the content of the root zone and a TLD's delegation based on these (unspecified) value judgements. If IANA or any other body has concerns about the quality of a TLD's delegation, they should of course make representations to the TLD operator. But it must be the TLD's decision on how that advice is acted on. [2] The delegation data and NS RRset for any TLD must be the exclusive operational and administrative responsibility of the TLD operator. If IANA changes this data without co-ordination with the TLD operator, the outcome may well be much worse than the "extreme operational problem" that IANA is trying to solve on its own. For instance by unilaterally removing NS and/or glue records for some TLD, IANA could cause the world's resolving name servers to generate excessive load for the TLD's remaining functional name servers. Unilaterally replacing new, possibly broken delegation information with old, "working" data could have other unpleasant consequences. The TLD may be getting delegated to an old name server that has been phased out and no longer has the capacity to serve the TLD. It may not be running appropriate name server software. It might not even have an accurate, up to date copy of the TLD zone: checking the zone's SOA serial number on that server proves nothing. This would mean IANA might delegate the TLD to a server that is handing out bogus data for the TLD. The old server might not be in a suitably secure facility or covered by support contracts or enjoy 24x7 monitoring and supervision. IANA is unlikely to know in advance if these conditions held or not. The TLD operator would. Or at least should know this. [3] The criteria and circumstances when IANA might act in this way are not clearly explained. This information should be published. [4] Even although these actions may only take place in exceptional, emergency conditions, some form of wider consultation should take place beforehand if at all possible. No doubt this would happen in practice, but the proposal does not actually say so. That dialogue might entail getting opinions from the Root Server System Advisory Committee or some forum where operational DNS and network issues are discussed. Input from the operator of the faulty name server may also be a help here. Ideally there should be some sort of expert consensus on the action IANA should take assuming IANA was unable to get a response from the TLD operator concerned. That said, I believe IANA must only act in such circumstances with the full co-operation and knowledge of the TLD operator. [5] Technically, removing bad data from a TLD's delegation may not have any beneficial effect in the short term. Long-lived TTLs on NS and glue records could mean the bad data remains in the world's name servers for many days after any change is made. In some cases that bad data could be in the TLD's zone file where IANA will be unable to do anything about it and any change to the delegation info in the root zone would have no significant effect. Deleting an unresolvable or unreachable NS record for some TLD delegation from the root zone won't help if the same error remains in the TLD's zone file. [6] Unilateral changes to the root zone by IANA may well create more instability for the TLD and the world's DNS infrastructure. Simply reverting to the delegation info prior to the change might not be the proper course of action. Under the proposed procedure IANA cannot always be certain about what was the "last known good version" of a delegation. By restoring what IANA believes is that version -- what criteria will be used to make that determination? -- IANA may well be reintroducing old and possibly bogus name servers which could have inconsistent data for the TLD. If those servers contain bogus data, this could lead to false data for the TLD propagating and persisting throughout the DNS. [7] There may be unpleasant legal, regulatory and political implications for IANA if it changes a TLD's delegation without the consent of that TLD operator, even if the change was well-intentioned. In essence, IANA could be seen to be interfering in something that is a "national matter". [8] From a policy perspective, I am very uncomfortable with the precedent that would be set if IANA had the ability to unilaterally change the contents of the root zone. Doing this for extreme operational problems is all very well in theory, but it's the start of a very slippery and dangerous slope. [9] IANA seems to be proposing to act as judge, jury and executioner whenever these exceptional circumstances arise. This is unsatisfactory. These roles must be separated. For instance, the root server operators could report the problem, say abnormal query loads, IANA decides what changes to make after consulting a panel of experts and then gets approval from DoC to make those changes. I expect that this is the process that IANA would follow anyway. Though as such it should be formally documented. Many of the above concerns could be addressed if all change requests to the root zone included a mandatory back-out procedure which explained what action should be taken in the event of a problem with the change request. This is common practice whenever changes are made on mission-critical IT systems. It is disturbing that no such mechanism seems to exist for updates to the root zone. The proposal appears to suggest any back-out process might only be discretionary, which seems unwise. If the TLD operator is required to provide a clear back-out strategy for each change, IANA would have a much firmer foundation for taking unilateral action whenever that TLD operator was unresponsive. This would also prevent any operational confusion over who is responsible for a TLD's definitive delegation data. Therefore I recommend that IANA considers making a mandatory back-out procedure part of the root zone change request process. |