Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Edward Lewis <edward.lewis@icann.org> Fri, 19 August 2016 19:35 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 58F4112D11E for <dnsop@ietfa.amsl.com>; Fri, 19 Aug 2016 12:35:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level:
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-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 AcErZmzXA16R for <dnsop@ietfa.amsl.com>; Fri, 19 Aug 2016 12:35:25 -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 5BD3A12B01F for <dnsop@ietf.org>; Fri, 19 Aug 2016 12:35:25 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 19 Aug 2016 12:35:23 -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; Fri, 19 Aug 2016 12:35:22 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: william manning <chinese.apricot@gmail.com>
Thread-Topic: [DNSOP] The Larger Discussion on Differences in Response Drafts
Thread-Index: AQHR973IVjjhc7YxJkClw1fEI06GoKBQbkEAgACU0ID//+FkAA==
Date: Fri, 19 Aug 2016 19:35:21 +0000
Message-ID: <1738EE77-2A1C-4EAA-B099-AE4818372EBA@icann.org>
References: <665d8bd3-4229-eb98-1688-2460dcb943b6@gmail.com> <99CE1D3E-18A0-42E6-949F-E78995AFCEE2@icann.org> <CACfw2hhAzqV56V+e+X_1+F7p4Jdzs4O98pXX=UdHAVbQX6VOfw@mail.gmail.com>
In-Reply-To: <CACfw2hhAzqV56V+e+X_1+F7p4Jdzs4O98pXX=UdHAVbQX6VOfw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.18.0.160709
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_3554465722_1064065140"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bplLg0eeYvBQbtnARA9utnjhxSY>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] The Larger Discussion on Differences in Response Drafts
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 19 Aug 2016 19:35:27 -0000

On 8/19/16, 13:24, "william manning" <chinese.apricot@gmail.com> wrote:

>First off, I take exception to the use of the word "dangerous".  AXFR isn't dangerous, it's just the best way to do the job.  If there are other query types that are better (or only) can be done over TCP, then so be it.  But they aren't per se dangerous.

Dangerous is in the eye of the beholder.  I had in mind the critiques that ANY queries were dangerous (with some operators already curtailing them).  AXFR isn't dangerous, but it is restricted to TCP because of a different need, the need to maintain ordering of the segments.

>End of the day, this question is fundamentally one of which side knows best what the application is looking for, the resolver or the server?   

That's the root cause of the work here.

In 2009 or so I recall an IAB draft document on DNS that urged an end to "curving the DNS" to applications.  My response was that the only evidence to date was the MX record's inclusion of the A record in the response - harking back to the origin of domains in email arguably driving the definition of the DNS as a protocol.  (Forgive a lot of hand waving, I do have another draft that covers that in more formal detail.)

The DNS has, historically, for better or worse, remained neutral towards the applications that use it.  I suspect that the fear was that if the DNS helped one protocol out, it might harm another, so we've kept an even keel.  I'm not saying that we must remain that way, just that this is the historical record.

The problem with now defining what additional record sets belong to certain queries is that we make handling unknown record types murky.  Perhaps we can have a subset of RR type codes that are set aside for types with additional section expectations - I just can't imagine writing future-proofed code in that case.  So maybe that's a stupid idea.  (Not the first one today.)

I'm open to other solutions.  I'm just giving a historical perspective.  What can go in EDNS0 or into "session" state is an open topic, as an example.