[dnsext] enough is enough

bert hubert <bert.hubert@netherlabs.nl> Sun, 21 December 2014 09:45 UTC

Return-Path: <ahu@xs.powerdns.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 355661A0370 for <dnsext@ietfa.amsl.com>; Sun, 21 Dec 2014 01:45:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 HPYPEQgy4ssv for <dnsext@ietfa.amsl.com>; Sun, 21 Dec 2014 01:45:03 -0800 (PST)
Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC571A036F for <dnsext@ietf.org>; Sun, 21 Dec 2014 01:45:03 -0800 (PST)
Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from <ahu@xs.powerdns.com>) id 1Y2d4I-0000Eu-HY; Sun, 21 Dec 2014 10:44:54 +0100
Date: Sun, 21 Dec 2014 10:44:54 +0100
From: bert hubert <bert.hubert@netherlabs.nl>
To: Patrik Fältström <paf@frobbit.se>
Message-ID: <20141221094454.GC13389@xs.powerdns.com>
References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <A78F8417-AEA2-42BF-A7D5-96FE99DCBBBE@rfc1035.com> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <E732A2F7-E467-4940-8A66-726FC894B4B3@frobbit.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <E732A2F7-E467-4940-8A66-726FC894B4B3@frobbit.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/NKJOHkqmCS1WUwchtEJPmpcHJ74
Cc: DNSEXT Group Working <dnsext@ietf.org>
Subject: [dnsext] enough is enough
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: Sun, 21 Dec 2014 09:45:05 -0000

On Sun, Dec 21, 2014 at 06:34:02AM +0100, Patrik Fältström wrote:
> - ...policy in some registries require NS records for registrations of a domain (i.e. no difference between registration and delegation), there will be lame delegations

To clarify, nothing like this is what I intended. Perhaps a prototype will
help:

"Dear domain operator, nameserver vendor, or load balancer purveyor,

The domain x.y.z fails to resolve using our software, and we have determined
that this is because the software or hardware publishing the DNS details of
x.y.z is not conforming to the DNS standards.

The violation is: Sending empty non-aa answers to AAAA queries
The result is: our software generates a SERVFAIL response, confusing
Microsoft Exchange.
The product at fault is: Citrix Netscaler 

Please find further details attached to this message.

While some other software or service is able to resolve your domain, we are
not going to work around this issue. 

For years, all resolver vendors and service providers have papered over DNS
protocol violations if one of the other big resolver implementations was
able to resolve a domain. There is now a staggering amount of papering over
in each nameserver implementation.

As a DNS community, we have decided that enough is enough. We encourage you
to contact the responsible vendor (see above). We are more than willing to
talk to them if this helps them resolve the issue.

Kind regards,

PowerDNS, also on behalf of ISC, .., .. and .."

This would then come with a website with further explanations, and perhaps
even a registry of faults that has been decided we're not going to fix.

I'm open to providing specific workaround configurations to individual
operators if this helps them in the meantime, but they'll hate having to
maintain all these workarounds, thus generating rising pressure on the
vendors of broken equipment.

Ideas?

	Bert


> 
> - ...policy in some registries require NS records for registrations of a domain (i.e. no difference between registration and delegation), there will be proxy registrations and registrants that lie
> 
> - ...data sent to a registry/registrar, regardless of data protection legislation, is available freely "on the net", there will be proxy registrations and registrants that lie
> 
> - ...policy make it impossible to register domain names in some registries, there will be proxy registrations to circumvent the very same rules
> 
> - ...there is no agreement on what data to send to registries for DNSSEC signed zones, it will be very hard to get lots of DNSSEC signed zones
> 
> - ...policy in some registries that the registrant should contact them directly, registrars will lie to the registry during registration period so that they can give the registrant the service the registrant ask for
> 
> I.e. the world out there is so messy that what you talk about is a light warm breeze...
> 
> Just the notation of "the TLDs" to fix things is confusing to me. Does "the TLD" imply the registry, whoever is the administrative contact for the TLD in the IANA database, or the backend provider, or the technical contact or the one holding the whois record of the delegation the question is about, or...
> 
>    Patrik
>