[DNSOP] Comments on draft-ogud-dnsop-any-notimp-00.txt

Edward Lewis <edward.lewis@icann.org> Fri, 06 March 2015 21:33 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327611A872B for <dnsop@ietfa.amsl.com>; Fri, 6 Mar 2015 13:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 qYTrSTMqn2sx for <dnsop@ietfa.amsl.com>; Fri, 6 Mar 2015 13:33:51 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A341A8730 for <dnsop@ietf.org>; Fri, 6 Mar 2015 13:33:51 -0800 (PST)
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.847.32; Fri, 6 Mar 2015 13:33:49 -0800
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.0847.030; Fri, 6 Mar 2015 13:33:49 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: Comments on draft-ogud-dnsop-any-notimp-00.txt
Thread-Index: AQHQWFU7gy9NBsfyA0y+ffkT2kZByQ==
Date: Fri, 06 Mar 2015 21:33:48 +0000
Message-ID: <D11F80AB.984F%edward.lewis@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3508504423_12935933"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Gy-gMXzGm1InfXABqHPd3qQT-kk>
Cc: Olafur Gudmundsson <olafur@cloudflare.com>, "marek@cloudflare.com" <marek@cloudflare.com>
Subject: [DNSOP] Comments on draft-ogud-dnsop-any-notimp-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 06 Mar 2015 21:33:53 -0000

This draft is an old-school "00"  -  so I'll not get into nits.

First - what is an "upstream Auth server"?  Asking in the sense that perhaps
you mean to say that the requestor ought to assume all sources for the
domain name would return the same.  (I.e., don't try another address.)

Second - the document lacks needed justification/trade off discussion.

I'll take a moment to lay out my thoughts on this.

What good is the ANY query today?

1) The one use case is to retrieve un-expected records at a domain name for
which AXFR is not available.  (An exhaustive search is possible, but would
require 64K queries which is arguably worse than what we have now - at it's
worst.)

All other uses of the ANY query can be covered, reasonably, by other means.
(Having an AXFR of the zone for one, or a look at the database driving the
configuration.)

How is the ANY query harmful?

1) It contributes, not uniquely, to the ease with which amplification
attacks can make use of DNS servers to launch an attack on a third party.
While it is true that any large response can accomplish this, ANY make is it
"worse" but perhaps not  incrementally significantly.

2) It has been proven to be misunderstood because it is the one query type
that cannot guarantee coherence.  Asking a cache with partial set of the
records of a domain name will give that subset, even with DNSSEC.  Beyond
being used in a confusing manner, there are cases where implementers
confusion is apparent in traffic loads.

3) In cases where the responses for certain RRtypes are
environment-dependent, assembling the correct response is difficult.  To
keep this story short, yadda, yadda, yadda, the need to reply to ANY in this
way gets in the way of exploring options in this space.  (This description
might take the longest to document.)