[DNSOP] comments on draft-jabley-dnsop-refuse-any-01

神明達哉 <jinmei@wide.ad.jp> Mon, 02 November 2015 06:21 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 BF4671B4801 for <dnsop@ietfa.amsl.com>; Sun, 1 Nov 2015 22:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level:
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 dV2hEKzWVBM0 for <dnsop@ietfa.amsl.com>; Sun, 1 Nov 2015 22:21:52 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A731B4843 for <dnsop@ietf.org>; Sun, 1 Nov 2015 22:21:52 -0800 (PST)
Received: by iofz202 with SMTP id z202so134121370iof.2 for <dnsop@ietf.org>; Sun, 01 Nov 2015 22:21:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=McB908Pn3yNXw9bMDDYtqZKom4ObrxMPYtV//nCGm4s=; b=vwKmAHwjPcwxvFpU1/Y28qOv8+eaI73JrS1mi14ftAsbmCiw+xVpG0mviDUZQTClHU 1T4rFgjX/7IRy55CG4LsyEudTDQM+nhArfkq02Ha5Q5yopcWUgwG8nwNgSq0Hzw7YFTz QxjWhF+dg9As1Nofc1lGVFB0QevCllZUu3XP6ZWT+LQy4xXFjYef1H0/kx7SzheZB/vD ISCgFNlQV+fzvewzFwpWgXddNoBpyZ2xFnBky9gFVEre8yK/xc6u39ZvmehM4GQoDnan A6MO5XiMjP7CBV2ASpvA8OpK8/CuqAVolKmCKr5CF1nNxp3t3RI9HGlk3xTbC1KYVERh dnag==
MIME-Version: 1.0
X-Received: by 10.107.159.72 with SMTP id i69mr24278742ioe.4.1446445312073; Sun, 01 Nov 2015 22:21:52 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.107.140.71 with HTTP; Sun, 1 Nov 2015 22:21:52 -0800 (PST)
Date: Mon, 02 Nov 2015 15:21:52 +0900
X-Google-Sender-Auth: k9TtOf5iqfAtpLKis-6sAefso6E
Message-ID: <CAJE_bqdcmL7zF+iW2c=y4hgzXgzAHoYFNAuTtYQYSqJmavYMkg@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/59oNAQ5hZD3BkbhnPSj9sqa-jvU>
Subject: [DNSOP] comments on draft-jabley-dnsop-refuse-any-01
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: <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: Mon, 02 Nov 2015 06:21:53 -0000

I've read draft-jabley-dnsop-refuse-any-01.  I have a few comments:

- Section 3

   ANY queries are sometimes used to help mine authoritative-only DNS
   servers for zone data, since they return all RRSets for a particular
   owner name.  A DNS zone maintainer might prefer not to send full ANY
   responses to reduce the potential for such information leaks.

  I'm not opposed to the idea of reducing ANY responses per se, but
  this rationale doesn't sound very strong to me.  There are at most
  64K types of records for a particular of name (of the same class),
  and for a signed zone it's quite easy to get all existing types for
  a particular name (the number of which would usually be much smaller
  than 64K in practice).  It may be true that sending an ANY query is
  an easy and cheap way to get all types of records of a particular
  name today, if you really worry about this type of mining, tweaking
  ANY response won't help much anyway.

- Section 4

   1.  A DNS responder may choose to search for an owner name that
       matches the QNAME and, if that name owns multiple RRs, return
       just one of them.

  If the choice of the "one" is not deterministic and especially if a
  zone uses different authoritative server implementations, then it's
  more likely that they return "inconsistent" responses.  This may not
  be a problem, but we may want to encourage consistent behavior,
  e.g., by suggesting the choice of smallest (not just 'a small') one
  in Section 5.

- In terms of using ANY query for debugging purposes, and if our main
  goal is to prevent abuses like amplification attacks rather than
  mining, I wonder whether we want to allow the original behavior
  under some conditions, e.g., queries authorized by TSIG or sent over
  TCP.

- I wonder whether we want to use a new type of RR rather than HINFO
  for synthesized responses. (I've not closely followed discussions on
  this draft, so perhaps it was already considered and rejected?).

--
JINMEI, Tatuya