Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7368512955B for ; Thu, 27 Oct 2016 15:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wytpfZrCvBdU for ; Thu, 27 Oct 2016 15:10:15 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E50129617 for ; Thu, 27 Oct 2016 15:10:15 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id z190so64803474qkc.2 for ; Thu, 27 Oct 2016 15:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8FK3bAFTDZk3S5705GpLjzJoVqSDE5wMqjFYZNpCRGA=; b=ZHZbYl/ngZQ5O9vQyywiZsViMjEqODvff7ab64RWFD06ncfnGu1RrFv/5FHw7B7pPn /L96O8+E1MF3MMRYoNJa7OPbPJr9PfQDwVy4oU+vEN+jSzLs3VY6Ypze8mSpcoo7Puoq O015CHptsjgxVZp4sMX0E3R/KUd2ejEC1U+YIZuc8fm1NUYTwTNCRAsc3jJQucq0fpr5 JCkAyZc9tasWNe9rcpIyc/Qu+K1NV5qa79IIPolH74ylj31Qe5yCP4938ZYO82EXsJxF 3tQAdAXiMjLgJSd9Lz6A4SP7p9zspCFjEFqFVe7G37kpgwV0FjQDaSNO42ghFVJECUl4 kFAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=8FK3bAFTDZk3S5705GpLjzJoVqSDE5wMqjFYZNpCRGA=; b=dyD0IjQAy3pxk7P6L+bv5S4gzNh3s9sRwerdAdMo+Dhy+nnotwUSSVCIPnFVMMY35h JpXdDSv1AKCA17yAQsYMDUmZiF+Ymna461N/wutcXi5ZRbEX3CVnPZt6OfiILbqb8p3q 1uKs/0DMa1HncgG4IzxGL9XHDm2zFbiIbsiek2jziJ5r9mqWz5UFrhH3r6JyUZGZUPgA w0/sDg7Ac1g/GUFZSTbB3BCUoS4cox5rOaQcN1UHoQiquvVOcm71Dt+NyE6dlfpZwXNv 3cPHTpi1o+Zzb7avUBCOy0P6oxGX33v3XVihaBMAGd8e7cXQbDsoL8euvmStNsnubD41 cBuw== X-Gm-Message-State: ABUngvdoCK95I68BQ/SV+LdFp/ucNdfuzCr4Td+MT+nWy1Q/cjIwR8+Ljdz2NN36U7qZCuYT+yQjbaxLltaI0w== X-Received: by 10.55.200.152 with SMTP id t24mr8673082qkl.205.1477606213951; Thu, 27 Oct 2016 15:10:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.202 with HTTP; Thu, 27 Oct 2016 15:10:13 -0700 (PDT) X-Originating-IP: [216.235.10.37] In-Reply-To: <66334AF3-A365-46C5-A448-1A10B38E169C@gmail.com> References: <20161010023251.241F1560C844@rock.dv.isc.org> <20161017021526.7AB1656D0F46@rock.dv.isc.org> <66334AF3-A365-46C5-A448-1A10B38E169C@gmail.com> From: Matthew Pounsett Date: Thu, 27 Oct 2016 18:10:13 -0400 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary=001a11374d8e807820053fe001a4 Archived-At: Subject: Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 22:10:18 -0000 --001a11374d8e807820053fe001a4 Content-Type: text/plain; charset=UTF-8 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. --001a11374d8e807820053fe001a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Following Suzanne's request= to send text, I've put together a first draft of what I think the Reme= diating (renamed to Remediation) section should look like.=C2=A0 In additio= n to this rewrite, I'd recommend moving it to be directly after the Tes= ting section.


# R= emediation

Name server operators are generally expected to test their own infrast= ructure
for compliance to standards. The ab= ove tests should be run when new systems
ar= e brought online, and should be repeated periodically to ensure continued
interoperability. =C2=A0

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 the= ir DNS operator does not have a well
mainta= ined or compliant infrastructure should insist that their service
provider correct issues, and switch providers if the= y 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 th= e precise issue(s) which can then be reported to the relevant party.
<= div class=3D"gmail_extra">
If contact i= nformation 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 informa= tion
=C2=A0 for the parent domain of the na= me of the misbehaving server, or for zones
= =C2=A0 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 z= ones may wish to regularly test the authoritative name
servers of their child zones.=C2=A0 However, parent operators c= an have widely
varying capabilities in term= s of notification or remediation depending on
whether they have a direct relationship with the child operator.=C2=A0 M= any TLD
registries, for example, cannot dir= ectly contact their registrants and may
ins= tead need to communicate through the relevant registrar.=C2=A0 In such case= s it
may be most efficient for registrars t= o take on the responsibility for testing
th= e 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 re= move NS records that refer to
the faulty se= rver.=C2=A0 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, ot= her 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.

--001a11374d8e807820053fe001a4--