Re: [DNSOP] Asking TLD's to perform checks.

Shane Kerr <shane@time-travellers.org> Tue, 10 November 2015 14:25 UTC

Return-Path: <shane@time-travellers.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04281B2B56 for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2015 06:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 TJafuASlP_2S for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2015 06:25:15 -0800 (PST)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EC81B2B52 for <dnsop@ietf.org>; Tue, 10 Nov 2015 06:25:14 -0800 (PST)
Received: from [2001:960:7b5:3:c68e:8fff:fef5:64bd] (helo=pallas.home.time-travellers.org) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1Zw9rD-0000yk-BC; Tue, 10 Nov 2015 14:25:11 +0000
Date: Tue, 10 Nov 2015 15:25:11 +0100
From: Shane Kerr <shane@time-travellers.org>
To: Mark Andrews <marka@isc.org>
Message-ID: <20151110152511.6f1a1c20@pallas.home.time-travellers.org>
In-Reply-To: <20151105235402.39FFC3BF2F29@rock.dv.isc.org>
References: <20151105235402.39FFC3BF2F29@rock.dv.isc.org>
X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/N0HdpB-ewv0UgVksR10yKxCJccI>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Asking TLD's to perform checks.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2015 14:25:17 -0000

Mark,

On Fri, 06 Nov 2015 10:54:02 +1100
Mark Andrews <marka@isc.org> wrote:

> 	I keep getting told the IETF can't tell people what to do
> 	but that is *exactly* what we do do when we issue a BCP.
> 	We tell people what best current practice is and ask them
> 	to follow it.
> 
> 	Today we have TLDs that do perform all sorts of checks on
> 	servers they delegate zones to and some do inform the
> 	operators of those zones that they have errors.  Those
> 	checks cover in part tests described in
> 	draft-andrews-dns-no-response-issue.
> 
> 	So do we adopt this or do we continue to lie to ourselves
> 	about what BCP actually do?

My guess is that part of the resistance is because you are going to be
asking people to spend money on something that does not provide them or
their customers any (direct) benefits. Further, it breaks the
registry-registrar model in some cases, where registries are kept away
from registrants by a 1.6 km-high wall.

My prediction about the eventual outcome is that you would end up with a
document that works as well as BCP 38; meaning that it is nice to have
for people that want some recommendations about what to check (and
can't be bothered to look at other registries' online documentation, or
contact registries directly and ask what they do).

If your true goal is to get ICANN to act as the some sort of enforcer
for DNS operational purity, then please do so via ICANN channels rather
than the IETF. ;)

To be clear, I am not opposed to a document which lists various checks
a parent zone may want to do, and the costs & benefits of each, as long
as it doesn't end up with you screaming at the microphone because TLD
.XX doesn't implement the recommendations. :)

Cheers,

--
Shane