Re: [DNSOP] [Ext] the power of ideas

Edward Lewis <edward.lewis@icann.org> Tue, 04 April 2017 15:30 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F0B1296D8 for <dnsop@ietfa.amsl.com>; Tue, 4 Apr 2017 08:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 RJVVgunYqDUO for <dnsop@ietfa.amsl.com>; Tue, 4 Apr 2017 08:30:09 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B06512420B for <dnsop@ietf.org>; Tue, 4 Apr 2017 08:30:09 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 4 Apr 2017 08:30:07 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 4 Apr 2017 08:30:07 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] the power of ideas
Thread-Index: AQHSrLUI3erBhIQMcUertbP/DUiqBKG1iYuA
Date: Tue, 4 Apr 2017 15:30:06 +0000
Message-ID: <D68BB788-3CE4-4630-BCC3-46D0F4ED5876@icann.org>
References: <CA+nkc8Bwc6eQz6YPAnMLNjvHm4POLTyvsTRQC5Pn+R4iTzaB-g@mail.gmail.com> <3A4E2834-2BD4-4DC3-9D5A-A15B3DCDA738@isoc.org> <alpine.LRH.2.20.999.1704031546230.16478@bofh.nohats.ca> <7458227.fcc3KKjKTW@linux-hs2j>
In-Reply-To: <7458227.fcc3KKjKTW@linux-hs2j>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3574150205_1199968659"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rDV8_TYxlS1ZtstaWYpdm8AYPh0>
Subject: Re: [DNSOP] [Ext] the power of ideas
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 04 Apr 2017 15:30:11 -0000

On 4/3/17, 16:00, "DNSOP on behalf of Paul Vixie" <dnsop-bounces@ietf.org on behalf of paul@redbarn.org> wrote:

    On Monday, April 3, 2017 7:48:49 PM GMT Paul Wouters wrote:
    > ...
    > As Evan said, there should not be any code in an authoritative server
    > that requires it to do recursive validation.
    
I'm going to squat on Paul Vixie's subject line but not respond to anything he says, in part because something crossed my mind, based, ironically enough, in a conversation Paul and I had not long ago (at an ICANN meeting venue).

We reminisced about client-subnet-id.  There was a way-back time when I spoke of a q-trinity - qname, qtype, qclass - being the three things needed to get a specific response from DNS.  Including any other information was a pollutant.

Paul pulled that out when my name was on an early version of the client-subnet-id document (as a caretaker editor).  The reason I was participating in that was seeing how the implementation of "stupid DNS tricks" (as one side of the war might call them) or "tailored DNS responses" (as the other side of the war might call the same battle) got carried out in specific contexts.  They "worked" despite some flaws and dire predictions.

It isn't that it's a sin to pollute the query with other information, there's a cost of doing so.  In some cases, the cost is worth the benefit, in others, not.  It's not a binary "do it or not" but a sliding scale of "is the cost less than the benefit?" I say sliding because "cost" and "benefit" are not fixed values over time.  (Moore's law, Kaminsky's BlackHat presentation change cost and benefit calculations.)

Back to the quote above.  In general, an authority server having to do lookups will have scaling implications, suck performance, present a potential for abusive loading (think DoS/DDoS).  (Related but different, DNSSEC once required the server verify signatures on load - that slowed loading zones, so it was dropped with the consequence of having to carefully define the AD bit in a response.)  But in specific, managed and contained contexts, having authorities look up data to improve an answer can be worth the cost.

Question hard-and-fast rules from the past.  Things change.