IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Thu, 03 May 2018 23:23 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 CB54912DA3D for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 16:23:11 -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 MSlBaNzaTEW4 for <dnsop@ietfa.amsl.com>; Thu, 3 May 2018 16:23:09 -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 C7CCB12DA05 for <dnsop@ietf.org>; Thu, 3 May 2018 16:23:09 -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 36CA63AB05D; Thu, 3 May 2018 23:23:09 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E25F7160043; Thu, 3 May 2018 23:23:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C1ED816006F; Thu, 3 May 2018 23:23:07 +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 8hFoTjLhY7Ev; Thu, 3 May 2018 23:23:07 +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 7F7E8160043; Thu, 3 May 2018 23:23:06 +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: <40451767-9536-448B-8BBD-A592AD430A78@pch.net>
Date: Fri, 04 May 2018 09:23:04 +1000
Cc: David Huberman <david.huberman@icann.org>, Edward Lewis <edward.lewis@icann.org>, Shane Kerr <shane@time-travellers.org>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <23302F63-7B87-42B2-9A5B-DE8FF3EFA7F4@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>
To: Bill Woodcock <woody@pch.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/huubG1JJD0PmYI7Pc22NajVgboI>
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 23:23:12 -0000

> On 4 May 2018, at 8:36 am, Bill Woodcock <woody@pch.net> wrote:
> 
> 
> 
>> On May 3, 2018, at 3:27 PM, David Huberman <david.huberman@icann.org> wrote:
>> 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…
> 
> But isn’t that, by definition, impossible?  What could break as a result of a _lame_ delegation being removed?
> 
> They’d have to be spoofing a real IP address behind their firewall, which isn’t supposed to work anyway.
> 
>                                -Bill

A “Lame Delegation” can be to a particular machines.  These delegation for .fj are lame and have been for over a year.

fj. @128.32.136.3 (adns1.berkeley.edu.): dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused optlist=refused signed=refused ednstcp=refused
fj. @2607:f140:ffff:fffe::3 (adns1.berkeley.edu.): dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused optlist=refused signed=refused ednstcp=refused
fj. @128.32.136.14 (adns2.berkeley.edu.): dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused optlist=refused signed=refused ednstcp=refused
fj. @2607:f140:ffff:fffe::e (adns2.berkeley.edu.): dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused optlist=refused signed=refused ednstcp=refused

But because .fj has multiple servers

fj.			86400	IN	NS	ns1.berkeley.edu.
fj.			86400	IN	NS	teri.usp.ac.fj.
fj.			86400	IN	NS	ns2.berkeley.edu.
fj.			86400	IN	NS	rip.psg.com.
fj.			86400	IN	NS	manu.usp.ac.fj.
fj.			86400	IN	NS	auth00.ns.uu.net.

the service is still up.  In the meantime .fj doesn’t have the level of redundancy they presumably think they have and every resolver in the world spends time discovering that they are broken.

There are others like these where the servers fail to respond to certain classes of legitimate DNS queries.

westlaw.com.au. @146.242.20.65 (ns-emea-1.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.18.65 (ns-amers-1.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.19.65 (ns-amers-2.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.21.65 (ns-emea-2.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.22.65 (ns-apac-1.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok
westlaw.com.au. @146.242.24.65 (ns-apac-2.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok

Why should resolvers have to work around idiocy like this?

Mark
-- 
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