IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Fri, 04 May 2018 00:24 UTC

Return-Path: <marka@isc.org>
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 4B738127058 for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 17:24:24 -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 zFSuqurJ0xUX for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 17:24:23 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 030DA12704A for <dnsop@ietf.org>; Thu, 3 May 2018 17:24:23 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 802A23AB045; Fri, 4 May 2018 00:24:22 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2BF75160043; Fri, 4 May 2018 00:24:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DC4FF160055; Fri, 4 May 2018 00:24:21 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qQi5r7Hhqdjj; Fri, 4 May 2018 00:24:21 +0000 (UTC)
Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6F820160043; Fri, 4 May 2018 00:24:20 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <95D39EB7-9CF0-4DFE-AD9C-BCE61A69B4BF@pch.net>
Date: Fri, 04 May 2018 10:24:17 +1000
Cc: Edward Lewis <edward.lewis@icann.org>, David Huberman <david.huberman@icann.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Shane Kerr <shane@time-travellers.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E0AE702-D5BE-46B7-A819-CDECE2004DD1@isc.org>
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> <40451767-9536-448B-8BBD-A592AD430A78@pch.net> <23302F63-7B87-42B2-9A5B-DE8FF3EFA7F4@isc.org> <95D39EB7-9CF0-4DFE-AD9C-BCE61A69B4BF@pch.net>
To: Bill Woodcock <woody@pch.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HDgj3PnsN2XKXPb6NxhULjsDxQI>
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: Fri, 04 May 2018 00:24:24 -0000

> On 4 May 2018, at 10:11 am, Bill Woodcock <woody@pch.net> wrote:
> 
> 
> 
>> On May 3, 2018, at 4:23 PM, Mark Andrews <marka@isc.org> wrote:
>> A “Lame Delegation” can be to a particular machines.  These delegation for .fj are lame and have been for over a year.
> 
> Right, of course, but what breaks if you remove the lame nameservers from the NS list?  What am I not understanding?
> 
>                                -Bill

The problem is that you can’t just remove the NS records from the parent side because name servers learn the NS records from the child side of the delegation as well as the parent side.  The offending NS records need to be removed from both sides.  This (or fixing whatever is broken) is what should be happening when faults are reported.  When that doesn’t happen in a *reasonable* amount of time the *entire* delegation needs to be removed to force the issue.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org

v2.23.0 | Report a Bug | By Email