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

Mark Andrews <marka@isc.org> Sat, 07 November 2015 23:52 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 8A1A81B30A4 for <dnsop@ietfa.amsl.com>; Sat, 7 Nov 2015 15:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Et8bLsIyiTHL for <dnsop@ietfa.amsl.com>; Sat, 7 Nov 2015 15:52:28 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E5D1ACEB0 for <dnsop@ietf.org>; Sat, 7 Nov 2015 15:52:28 -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 082B7349315; Sat, 7 Nov 2015 23:52:18 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E32DE160044; Sat, 7 Nov 2015 23:52:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CF61F16007B; Sat, 7 Nov 2015 23:52:29 +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 H3SoO55DVxUK; Sat, 7 Nov 2015 23:52:29 +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 4ECB5160044; Sat, 7 Nov 2015 23:52:29 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id CF2683C117B4; Sun, 8 Nov 2015 10:52:13 +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> <20151106201718.0FCBA3C06566@rock.dv.isc.org> <53FE03EF-9C40-40DC-A403-50C0A339C6C6@fl1ger.de>
In-reply-to: Your message of "Sat, 07 Nov 2015 17:10:52 +0100." <53FE03EF-9C40-40DC-A403-50C0A339C6C6@fl1ger.de>
Date: Sun, 08 Nov 2015 10:52:13 +1100
Message-Id: <20151107235213.CF2683C117B4@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/OcvlwBKIiUf92xkna27R_6GYjBs>
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: Sat, 07 Nov 2015 23:52:29 -0000

In message <53FE03EF-9C40-40DC-A403-50C0A339C6C6@fl1ger.de>, "Ralf Weber" write
s:
> Moin!
> 
> On 6 Nov 2015, at 21:17, Mark Andrews wrote:
> 
> > In message <8D78B784-34D3-421E-B82C-52DD32E22B74@fl1ger.de>, "Ralf 
> > Weber" write
> > s:
> >> 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
> Cool, but unless they inform someone it won't help improve anything.
> Others do and it's good to see some people on the authoritative side
> doing something about it. IMHO it's still a drop in the ocean.
> 
> >> <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.
> Ever heard of negative registration or the .sucks domain....
> 
> [lots of DNS operational failure modes deleted]
> > 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.
> I agree with you on both points, but that doesn't help to get these
> wrong behaviours fixed. After working decades on operating recursive
> servers I have lost hope that we will get these behaviours fixed.
> 
> Whenever such a thing occurs no customer gave a damn about the wrong
> configuration of the authority, they all wanted the domain to resolve.
> That is the reason why advancing new technologies in the DNS is so
> difficult (impossible ;-).
> 
> Honestly I'd rather direct my energy to helping the end user with
> DNS than fixing all the DNS misconfigurations on the internet, but
> maybe this is because I'm getting old and have chased windmills
> long enough ;-).
> 
> So long
> -Ralf

Fixing misimplementations of the protocol is different to fixing
misconfiguration of servers.  The draft is aimed primarially at
fixing misimplementations rather than misconfigurations though both
need fixing.

To fix misimplementation of the protocol you work your way back to
the vendors to get the server or firewall fixed at the source then
install the fixed server / firewall.  Once you fix a misimplementation
it stays fixed as there is nothing to change other than upgrading
the server / firewall.

I do know that TLD servers get fixed and stay fixed [1].  We are
yet to attempt to do this sort of thing in lots to TLDs at the same
time.

There has never been a concerted effort to fix protocol errors by
asking the parents to check the child servers and informing the
operators that they are broken.

Most servers actually do the right thing and not all errors stop
interoperation.  e.g. echoing back a client cookie doesn't actually
stop DNS resolution.  For some other option this would be fatal
which is why we want to clean the ecosystem of broken servers now
rather than later.  To test more that what is causing immediate
problems.

As a vendor you (Nominum) should be checking the servers you ship
are compliant.  If you find ones that are out of compliance you
should be fixing them and informing your customers that there are
fixed servers available.  Compliance tests should be part of the
QA process.

Mark

[1] https://ednscomp.isc.org/compliance/ts/tld.html
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org