[dns-operations] TLD zones with lame servers
rubensk at nic.br
Thu Jun 13 20:27:40 UTC 2019
> * 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
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.
More information about the dns-operations