IETF Logo Mail Archive

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

Frederico A C Neves <fneves@registro.br> Thu, 03 May 2018 22:41 UTC

Return-Path: <fneves@registro.br>
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 88AB112DA26 for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 15:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 jXsY61pC4u0P for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 15:41:38 -0700 (PDT)
Received: from clone.registro.br (clone.registro.br [200.160.2.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99759120721 for <dnsop@ietf.org>; Thu, 3 May 2018 15:41:38 -0700 (PDT)
Received: by clone.registro.br (Postfix, from userid 1000) id C1E94FC16F; Thu, 3 May 2018 19:41:36 -0300 (-03)
Date: Thu, 03 May 2018 19:41:36 -0300
From: Frederico A C Neves <fneves@registro.br>
To: David Huberman <david.huberman@icann.org>
Cc: Mark Andrews <marka@isc.org>, Edward Lewis <edward.lewis@icann.org>, Shane Kerr <shane@time-travellers.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Message-ID: <20180503224136.GD62787@registro.br>
References: <7C873271-A784-4594-91A3-48C697EEC613@vpnc.org> <b3ed96d7-26fb-3d97-118b-39e8f352a38c@time-travellers.org> <87F43055-5B0E-4551-BD8D-241D93F9039F@icann.org> <0AA87D00-17F7-4D10-A72D-E4723C4A0642@icann.org> <B1F34038-595E-48A5-AFB6-20F3214BB8BF@isc.org> <EFC5B29C-48D2-4F5C-BF2D-26C26E302889@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <EFC5B29C-48D2-4F5C-BF2D-26C26E302889@icann.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EACCskZGQaA8WGE0-t1o23UXI18>
Subject: Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 03 May 2018 22:41:40 -0000

On Thu, May 03, 2018 at 10:27:30PM +0000, David Huberman wrote:
> Mark Andrews stated:
> 
> >It’s amazing how fast people can fix lame delegations once email and other 
> >services stop flowing. The only reason you think it is un- winnable is that you 
> >are unwilling to remove the delegation for failing to maintain a properly 
> >working configuration. 
> 
> Ideally, yes – of course.
> 
> But in practical terms, when any type of registry strips away a lame delegation
> attached to a real, operating network with users behind it, and things break
> as a result, it has a high potential of affecting the innocent 3rd parties using that
> network.  Especially at scale, the legal liability issues implicated by such an action
> are frightening, and quickly outweigh the ‘for the common good’ arguments. 

As long as there is community support Mark's observation works as
expected.

Slightly variatios of this policy are in place for LACNIC and APNIC
regions and is very effective.

http://www.lacnic.net/686/2/lacnic/6-lame-delegation-policy
https://www.apnic.net/manage-ip/manage-resources/reverse-dns/lame-dns-reverse-delegation/

Fred

v2.23.0 | Report a Bug | By Email