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

Paul Vixie <vixie@tisf.net> Wed, 11 November 2015 07:21 UTC

Return-Path: <vixie@tisf.net>
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 7CA241B3355 for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2015 23:21:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 UOgCvmklV0V7 for <dnsop@ietfa.amsl.com>; Tue, 10 Nov 2015 23:21:10 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920401B3348 for <dnsop@ietf.org>; Tue, 10 Nov 2015 23:21:10 -0800 (PST)
Received: from linux-85bq.suse (unknown [91.93.38.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 881FF18122; Wed, 11 Nov 2015 07:21:09 +0000 (UTC)
From: Paul Vixie <vixie@tisf.net>
To: Mark Andrews <marka@isc.org>
Date: Tue, 10 Nov 2015 23:18:50 -0800
Message-ID: <25390452.6vf6oD0bQi@linux-85bq.suse>
Organization: TISF
User-Agent: KMail/4.14.10 (Linux/4.1.12-1-default; KDE/4.14.10; x86_64; ; )
In-Reply-To: <20151110204330.C47C63C7D699@rock.dv.isc.org>
References: <20151105235402.39FFC3BF2F29@rock.dv.isc.org> <20151110152511.6f1a1c20@pallas.home.time-travellers.org> <20151110204330.C47C63C7D699@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart3413786.dSd7ARpsUx"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/JJRKPbbPweEigz9JOEGyhRQo_Uo>
X-Mailman-Approved-At: Wed, 11 Nov 2015 01:28:00 -0800
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: Wed, 11 Nov 2015 07:21:13 -0000

On Wednesday, November 11, 2015 07:43:30 AM Mark Andrews wrote:
> Perhaps we should be getting Jari, Suzanne and Andrew to push this
> at IGF meetings.

that's a right-thinking goal but with incorrect implementation semantics.

for IGF to care about this, you'd have to show the cost to end users and small domain 
holders, and i don't think it's compelling on that basis.

the best thing to do is write up a BCP-intended draft on what registrants, registrars, and 
registries should each do to check/maintain their registration information (NS, DS, and 
related AAAA or A), covering both motivation and method, with pointers to current open-
source tools, and references describing who has tried this in the past (or currently) and 
how it worked out for them.

then, ask jim galvin of ICANN SSAC, and andrei robachevsky of ISOC, to consider this as a 
possible topic to cover in next year's SSAC/ISOC panel at IGF. in other words there's not 
time to get this onto this year's schedule, but a well written and non-controversial IETF 
draft (or maybe RFC/BCP by then) would form an excellent basis for a highly relevant 
panel on internet stability.

fwiw, the best registry level checking i ever saw was at .BR by frederico neves and his 
team. you'll want him as a co-author of this draft, IMHO.

vixie

re:

> 
> In message <20151110152511.6f1a1c20@pallas.home.time-travellers.org>, Shane
> Ker
> r writes:
> > 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.
> 
> Who are the customers of a registry?  The registrants and those
> that lookup names in the registry.  Yes, everyone else *is* a
> customer of the registry and by performing tests and informing the
> registrants you help both sets of customers.
> 
> As for costs, a machine/vm running checks and sending out email
> every 3 months.  That's effectively all
> <https://ednscomp.isc.org/compliance/summary.html> is though it doesn't
> send the email and it runs the checks daily, it does have to hooks
> to send out email built in but they are not activated.  Once this
> becomes a regular thing many/most/all tlds do the human costs go
> down as it becomes something people can lookup answers for what to
> do when they get the email.
> 
> You ask the registant to contact their DNS/Firewall vendor for the
> fix after explaining the issue.  If they are hosting their own DNS
> they should know who that is.  If they are using a DNS operator the
> message gets relayed to the operator or they can switch DNS operators
> to one which does the right thing.  The DNS operator then needs to
> contact their vendors for a fix.
> 
> As for the no direct contact this doesn't require direct contact.
> The registrars can perform the checks for the servers of all zones
> registered through them or they can relay the messages from the
> registry.
> 
> > My prediction about the eventual outcome is that you would end up with a