IETF Logo Mail Archive

Re: [DNSOP] Caching of negative zone (non-authoritative) responses

Mark Andrews <marka@isc.org> Tue, 09 July 2019 23:58 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 837D01200C3 for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 16:58:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 Fopy1cUL2czR for <dnsop@ietfa.amsl.com>; Tue, 9 Jul 2019 16:58:47 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 ACCB0120098 for <dnsop@ietf.org>; Tue, 9 Jul 2019 16:58:47 -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 4A8153AB002; Tue, 9 Jul 2019 23:58:46 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1A3AF160048; Tue, 9 Jul 2019 23:58:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E0A15160079; Tue, 9 Jul 2019 23:58:45 +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 MPuB1a6KT-N5; Tue, 9 Jul 2019 23:58:45 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id F21DF160048; Tue, 9 Jul 2019 23:58:44 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <677BC30B-BF8E-4954-A3BE-EFD2F812792D@fugue.com>
Date: Wed, 10 Jul 2019 09:58:39 +1000
Cc: "Michael J. Sheldon" <msheldon@godaddy.com>, "dnsop@ietf.org" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C9FAE0A-0C3A-446B-8EF4-21E89880CCC5@isc.org>
References: <BYAPR02MB51900835E25A720BB9BF23C8DBF60@BYAPR02MB5190.namprd02.prod.outlook.com> <5268DB15-162D-4934-A941-C0ADE5A528B1@isc.org> <167DC406-7CA5-4C45-9F44-6586713CA0E8@fugue.com> <0CC7ADBE-E712-4578-8E22-2C0C5FB1B10E@isc.org> <677BC30B-BF8E-4954-A3BE-EFD2F812792D@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dtcYcFEx40wFrVlD4qahPbXtzbQ>
Subject: Re: [DNSOP] Caching of negative zone (non-authoritative) responses
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 09 Jul 2019 23:58:49 -0000


> On 9 Jul 2019, at 10:53 pm, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Jul 9, 2019, at 12:00 AM, Mark Andrews <marka@isc.org> wrote:
>> Actually if a DNS operator is requesting that NS records pointing to them be removed then the TLD only need to look at the enclosing SOA of NS’s address records to find a valid contact.
> 
> And how do they validate that any communication that follows is actually with that contact?

They email the address and ensure they get back something unique from that email.

1) Check the NS is returning REFUSED for the delegated zone.
2) Email the SOA contact with a unique confirmation URL with a validity interval.
3) When the URL is clicked remove the NS record from the delegation.

Optionally allow for confirmation via email.

If you want to check with delegated zone’s administrators do that between steps 1 and 2.

If you are worried about the SOA contact being forged require that the SOA record be signed
and that it validates as secure.

The DNS is a good enough introducer especially when it is signed.

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