Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

[Matthew Pounsett <[e-mail]>]

Following Suzanne's request to send text, I've put together a first draft
of what I think the Remediating (renamed to Remediation) section should
look like.  In addition to this rewrite, I'd recommend moving it to be
directly after the Testing section.


# Remediation

Name server operators are generally expected to test their own
infrastructure
for compliance to standards. The above tests should be run when new systems
are brought online, and should be repeated periodically to ensure continued
interoperability.

Domain registrants who do not maintain their own DNS infrastructure are
entitled to a DNS service that conforms to standards and interoperates well.
Registrants who become aware that their DNS operator does not have a well
maintained or compliant infrastructure should insist that their service
provider correct issues, and switch providers if they do not.

In the event that an operator experiences problems due to the behaviour of
name servers outside their control, the above tests will help in narrowing
down the precise issue(s) which can then be reported to the relevant party.

If contact information for the operator of a misbehaving name server is not
already known, the following methods of communication could be considered:

- the RNAME of the zone authoritative for the name of the misbehaving server
- the RNAME of zones for which the offending server is authoritative
- administrative or technical contacts listed in the registration
information
  for the parent domain of the name of the misbehaving server, or for zones
  for which the name server is authoritative
- the registrar or registry for such zones
- DNS-specific operational fora (e.g. mailing lists)

Operators of parent zones may wish to regularly test the authoritative name
servers of their child zones.  However, parent operators can have widely
varying capabilities in terms of notification or remediation depending on
whether they have a direct relationship with the child operator.  Many TLD
registries, for example, cannot directly contact their registrants and may
instead need to communicate through the relevant registrar.  In such cases
it
may be most efficient for registrars to take on the responsibility for
testing
the name servers of their registrants, since they have a direct
relationship.

When notification is not effective at correcting problems with a misbehaving
name server, parent operators can choose to remove NS records that refer to
the faulty server.  This should only be done as a last resort and with due
consideration, as removal of a delegation can have unanticipated side
effects.
For example, other parts of the DNS tree may depend on names below the
removed
zone cut, and the parent operator may find themselves responsible for
causing
new DNS failures to occur.