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

Mark Andrews <marka@isc.org> Fri, 06 November 2015 20:17 UTC

Return-Path: <marka@isc.org>
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 197941B2FF4 for <dnsop@ietfa.amsl.com>; Fri, 6 Nov 2015 12:17:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UUGDzMyjRo_6 for <dnsop@ietfa.amsl.com>; Fri, 6 Nov 2015 12:17:23 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF1D1B2FF2 for <dnsop@ietf.org>; Fri, 6 Nov 2015 12:17:23 -0800 (PST)
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)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id F2B1B3493A5; Fri, 6 Nov 2015 20:17:20 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E585316007C; Fri, 6 Nov 2015 20:17:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D88BE16007A; Fri, 6 Nov 2015 20:17:27 +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 ZISSR456Cefe; Fri, 6 Nov 2015 20:17:27 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id 718DF16005A; Fri, 6 Nov 2015 20:17:27 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0FCBA3C06566; Sat, 7 Nov 2015 07:17:18 +1100 (EST)
To: Ralf Weber <dns@fl1ger.de>
From: Mark Andrews <marka@isc.org>
References: <20151105235402.39FFC3BF2F29@rock.dv.isc.org> <8D78B784-34D3-421E-B82C-52DD32E22B74@fl1ger.de>
In-reply-to: Your message of "Fri, 06 Nov 2015 08:46:10 +0100." <8D78B784-34D3-421E-B82C-52DD32E22B74@fl1ger.de>
Date: Sat, 07 Nov 2015 07:17:18 +1100
Message-Id: <20151106201718.0FCBA3C06566@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/oc-5Xb-PjNYmXrpS0QHs7lYfsQ4>
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: Fri, 06 Nov 2015 20:17:25 -0000

In message <8D78B784-34D3-421E-B82C-52DD32E22B74@fl1ger.de>, "Ralf Weber" write
s:
> Moin!
>
> This may be totally in appropriate
>
> On 6 Nov 2015, at 0:54, Mark Andrews 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.
> Really TLDs doing repeated checks? I know some do when you
> register domains, but repeatedly? Examples?

Yes.  Daily checks of all delegated server.  I don't believe they are
currently reporting the discovered faults.

	http://bamus.switch.ch/edns/summary.html

Others do as well.

ICANN runs regular checks of TLD servers and they do report when they
fail those checks for atleast some of the TLDs.

> > 	So do we adopt this or do we continue to lie to ourselves
> > 	about what BCP actually do?
> They recommend something. The problems is when your
> recommendations are interfering with business or policy aspects
> which this draft clearly does:
>
> "If repeated attempts to inform and get the customer to correct /
>    replace the faulty server are unsuccessful the TLD operator shall
>    remove all delegations to said server from the zone."

Lots of BCP's have costs associated with them.  Checking delegations
and getting them corrected has always been part of their responsabilities
as has been removing delegations that cause operational problems

They really are not being ask to do anything that they should not
already be doing.  I would hope that they never have to remove a
delegation.  That sending a number of emails over several months
would be enough.  It will be for many sites.  They just need to be
informed that they have a issue and they will update to fixed
release.

Some will complain that the TLD's are being busybodies, but having
a document that says these checks should be being performed will
backup the TLD's.  Those that perform these checks today need this
backup.

TLD's will decide in the end whether they remove the delegation or
not.  Backing up that action with consensus that they should be
doing it helps the TLD should they do so.

> <cynic mode=on>
> So you are telling TLD to spend money for checks that will decrease
> there revenue. TLDs make money by registering domains. The don't make
> money by running DNS, that is cost.
> </cynic mode>

If they don't run the DNS they don't get to take in the money.

> I know that a lot of TLDs go to great lengths running a good DNS
> service and have sensible policies for there registrars to run a good
> DNS service also, and the above comments are not for them, but some
> people only look at the money.

Part of running a good service is ensuring that the delegations
work.  This has always been part of there operational responsabilities
even if some of them would like to forget that.

TLD have also been required to remove delegations that cause
operational problems.  They do this today for sites that emit spam,
host malware etc.

Sites that use nameserver that are not rfc compliant do cause
operational problems.  Removing a delegation for that after repeated
attempts to get the issue addressed is no different than removing
a delegation for spaming.

Running nameservers that do not answer well formed queries causes
when a option is set or a flags is not zero cause operational
problems.

Running nameservers that return the wrong error code when option
is set or a flags is not zero cause operational problems.

Lookup are failing (present tense) due to these issues.  More will
fail as clients make more use features that should work for all
site and do work for the majority of sites.

We don't yet have clients sending EDNS(1) queries but EDNS flags,
EDNS options, DNS flags, and unknown types are all regular occurances.

Yes, there are sites today that don't repond to DO=1 queries.
Yes, there are sites today that don't repond to AD=1 queries.
Yes, there are sites today that don't repond to EDNS queries.
Yes, there are sites today that don't repond to EDNS queries with a EDNS option.
Yes, there are sites today that don't repond to various query types.

There are sites that respond with NXDOMAIN rather than NOERROR when
you do one of the above.

The operational problems that result from these behaviours should be
obvious to everyone on this list.

There are lots of other incorrect responses that cause operational
problems.

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