Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

Morizot Timothy S <> Fri, 13 March 2015 17:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5BEBC1A9077 for <>; Fri, 13 Mar 2015 10:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.111
X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ieR433-rluUv for <>; Fri, 13 Mar 2015 10:21:53 -0700 (PDT)
Received: from ( [IPv6:2610:30:4000:25::92]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 095011A906B for <>; Fri, 13 Mar 2015 10:21:47 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id t2DHL1HM022247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Fri, 13 Mar 2015 12:21:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=irs-20130926; t=1426267279; bh=w840u9jKk8gzYR6MFCeYCWuPOOoTrWf7ot2mEGdWdCw=; h=From:To:Subject:Date:References:In-Reply-To; b=kBomIh5E9XlHaIDYH1NhCIYxvGi4pp6tmEvibF80rAsvkyDyP7du66sV2/KVNAQRp 7HQ1okiNhfnT8HwiS2YyfpKyHFTwucYt8fxWBI1n+9x68YVDXehfXGZR7UlZ1NRxvB GHd9IM+SJMObBtKBdGHSlaGvvWioYAzBQciZVOCI=
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 13 Mar 2015 12:21:32 -0500
Received: from ([fe80::3c47:b073:8e3a:ef02]) by ([fe80::3c8a:d464:662e:8675%14]) with mapi id 14.03.0224.002; Fri, 13 Mar 2015 12:21:32 -0500
From: Morizot Timothy S <>
To: "" <>
Thread-Topic: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Thread-Index: AQHQXXhexKncgQDHLUeTZsGtIlbAqJ0a5y0AgAAHHYD//7JCYA==
Date: Fri, 13 Mar 2015 17:21:31 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_968C470DAC25FB419E0159952F28F0C06DF659F0MEM0200CP3XF04d_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Mar 2015 17:22:00 -0000

From: Paul Vixie

ultimately what matters is whatever works. if cloudflare decides to stop answering QTYPE=ANY then it would take all million or so qmail customers complaining to cloudflare's NOC to get cloudflare to change its mind. i don't think that's going to happen, for a number of reasons, one of which is that the corner case qmail is depending on was a bad idea originally and has gotten nothing but worse since then. but let's run the experiment, shall we?


DNSSEC is a colossal flop, but not a mistake. It's an embarrassment, but we'd do it all again if we had to. It's late -- it was started years before the IPv6 effort but is (believe it if you can) even less finished and less deployed than IPv6. It's ugly and complicated and if we knew then what we know now we'd've scrapped DNS itself and started from scratch just to avoid the compromises we've made. But we didn't know then, etc., and what we have to do now is avert our gaze and fully deploy this ugly embarrassing thing.

I agree that what works will ultimately win the day. Cloudflare can do what it wants and if it only breaks qmail's unusual implementation they may decide they are fine with the results. That's a process independent of operational recommendations or policy work. Nor do I see that either will ultimately impact the outcome.

Many of the discussions about DNSSEC tend to focus on who has or hasn't signed their authoritative zones and people tend to point to a low percentage of signed zones as some sort of failure in the deployment of the protocol. (I'm not sure I've seen an analysis that attempts to determine how many of  those unsigned zones are basically just parked domains, but that's a side issue.) But signing is only part of the story and for those of us who have signed our zones, not the most important part. For instance, the statistic I monitor and care the most about is this one:

It's been steadily increasing for years now and gives me an idea what percentage of the US public is protected against certain types of attacks involving our zones. DNSSEC validation is not a panacea, but in a layered approach toward combating fraud and certain sorts of attacks, it does provide a particular sort of protection not available through any other means. Whether or not ISPs sign their authoritative zones matters much less to us than whether or not they implement DNSSEC validation on their recursive nameservers. And that's not a failure at all. By the measure above (which isn't perfect, but the best one available) roughly a fifth to a quarter of the US public, the primary consumers of our zones, exclusively use validating nameservers. That's significant. Would I like to see it higher? Sure. But I'll take it.

Enabling validation supports everyone who cares enough about their zones to sign them, whatever percentage of the total authoritative namespace that might be. Signing authoritative DNS is a decision each organization must make for themselves. I would encourage it, but that's something the organization must weigh. Enabling validation is a public good and much less problematic. And the concerns that have led to the need for negative trust anchors during early deployment mostly go away once most nameservers validate. Then if an organization breaks their authoritative DNS through a DNSSEC error, it breaks for most people instead of just ones with certain providers. It's an incomplete deployment of validation that's toxic and we'll see the most significant benefit from widespread validation. Yet when people talk about DNSSEC 'being broken' (a characterization with which I don't really agree), they mostly focus on the authoritative side.

Just a few thoughts spurred by the discussion.