[dnsext] getting TLDs to fix other people's problems

Jim Reid <jim@rfc1035.com> Sat, 20 December 2014 16:21 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9301A8A12 for <dnsext@ietfa.amsl.com>; Sat, 20 Dec 2014 08:21:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 th2WGMUdXxoZ for <dnsext@ietfa.amsl.com>; Sat, 20 Dec 2014 08:21:31 -0800 (PST)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A261A8A14 for <dnsext@ietf.org>; Sat, 20 Dec 2014 08:21:31 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 64204242143B; Sat, 20 Dec 2014 16:21:28 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <20141220142506.C7EA12630502@rock.dv.isc.org>
Date: Sat, 20 Dec 2014 16:21:25 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <A78F8417-AEA2-42BF-A7D5-96FE99DCBBBE@rfc1035.com>
References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/xStZ8w_lxWNlYKV0L0uZKqD3HLw
Cc: DNSEXT Group Working <dnsext@ietf.org>, bert hubert <bert.hubert@netherlabs.nl>
Subject: [dnsext] getting TLDs to fix other people's problems
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Dec 2014 16:21:33 -0000

On 20 Dec 2014, at 14:25, Mark Andrews <marka@isc.org> wrote:

> What we really need is for TLD operators to audit all the delegated
> servers and inform their owners when they see a broken one.

Mark, this is a ridiculous idea. It's utterly unworkable. just like it would be to get TLDs to act as the lame delegation police. It simply isn't going to happen. Even if this contact was viable, it will be rare to find a registrant who understands this aa=0 issue and is willing to fix the broken implementation: "the DNS for my domain is working just fine for me, so why should I care about the troubles it causes someone else or pay to fix their problem?".

I wish you every success getting ICANN to adopt that policy for gTLDs and then steering it through the policy-making machinery and/or legislation for each of the 200-odd ccTLDs. Once that's done, good luck with implementing and enforcing those policies.

> They are the ones with the lists of authoritative servers and the contact
> information.

No they are not. Lots of registrants hide behind proxy/privacy services. Some of them publish non-functioning contact data for the registrant, Other registrants supply ficticious contact data, myself included. Draining these festering swamps will take forever and no matter how hard registries try, they will always be stuck with them. Don't take my word for it. Ask the IPR and law enforcement types who have been screaming for years at ICANN about bogus whois data.

Remember too that the two largest TLDs (which have ~50% of the world's registered delegations) operate the thin registry model where the registrars and not the registry hold registrant contact data. Verisign couldn't even contact the holder of domain-with-aa=0-issues.com if they wanted to.