[DNSOP] comments on draft-bortzmeyer-dnsop-nxdomain-cut-00

神明達哉 <jinmei@wide.ad.jp> Fri, 20 November 2015 20:12 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 8F5011B33FD for <dnsop@ietfa.amsl.com>; Fri, 20 Nov 2015 12:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id l76sBmCdcrdv for <dnsop@ietfa.amsl.com>; Fri, 20 Nov 2015 12:12:21 -0800 (PST)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 399AA1B33D8 for <dnsop@ietf.org>; Fri, 20 Nov 2015 12:12:21 -0800 (PST)
Received: by iouu10 with SMTP id u10so137077687iou.0 for <dnsop@ietf.org>; Fri, 20 Nov 2015 12:12:20 -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=QXnMe4x3+L/Oy3GihyKF78j5P4a97+ccOSRl1KpH9XY=; b=Wr3B+qzuzMxXPDIQZk+jMNPHaNFXOewO2flNELVi4nXiOHi8NzgdR6I9CcK7HX/K6K 8jfTUC+NhEB4dvckhuLEDR6dV+plLrpeVRJ9NdMu+n8Gf0i87N8oQHnMan3sCvBcrvog 13ccTJvutM//iaIB/oEhPLMWDfIkmwUjJYcxH8DMBB2MJKLHP8nxOxchr7nJabYj1Uwx /uvHFrRX1B2oRDztEWLvAWsyxeVnmYv5TuJOBLPi/EDfdYZ3plP2bJA2ERyKybp+3jWO eDUOnndGT7x/3SjW/gBcoUqMnKvHFvHXxxp+aGjYRDqny3zXFshqkbimf4p/iT/V+lYX mQLw==
MIME-Version: 1.0
X-Received: by with SMTP id t91mr17408178ioi.172.1448050340648; Fri, 20 Nov 2015 12:12:20 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by with HTTP; Fri, 20 Nov 2015 12:12:20 -0800 (PST)
Date: Fri, 20 Nov 2015 12:12:20 -0800
X-Google-Sender-Auth: ECj6szRL0JMNULNJhJcGHAPHY8Y
Message-ID: <CAJE_bqe98gi0FHAhiug7w9HCrat_m4LpByqDuy=7m9afGiroug@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/hQykZUXPOKy-a4NEG2abhMt-vO0>
Subject: [DNSOP] comments on draft-bortzmeyer-dnsop-nxdomain-cut-00
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: Fri, 20 Nov 2015 20:12:22 -0000

I've read draft-bortzmeyer-dnsop-nxdomain-cut-00 and have a few
comments.  (I support the basic idea of the proposal, btw)

- Abstract: s/status code/response code/

   This document states clearly that when a DNS resolver receives a
   response with status code NXDOMAIN, it means that the name in the

- Section 2

   When an iterative caching DNS resolver stores an NXDOMAIN in its
   cache, all names and RRsets at or below that node SHOULD be deleted
   since they will have become unreachable.

  I suspect this is highly implementation dependent and so the RFC2119
  'SHOULD' is not really appropriate.  First off, what "delete" means
  isn't very clear.  If the resolver implementation frees memory
  region used for the corresponding cached RRsets that are now known
  to be nonexistent, it would be certainly considered a "delete".  But
  even if the resolver doesn't really "delete" the memory, it could
  look as if it did as long as the resolver doesn't use it for
  subsequent query handling (as described in the first paragraph).
  And the implementation may actually rather prefer to keep them
  in-memory until it needs memory for other purposes to save the
  overhead of actually freeing them.  So, in terms of interoperability
  the only important requirement is the first SHOULD.  IMO, whether
  the resolver implementation should "delete" the ancestor RRsets
  (including what "delete" actually means) should leave to specific
  implementation, and therefore I suggest just removing this

- Section 3

   NXDOMAIN cut may also help with random QNAME attacks
   [joost-dnsterror] [balakrichenan-dafa888].  In these attacks, queries
   are sent for a QNAME composed of a fixed suffix ("dafa888.wf" in one
   of the articles above), which is typically nonexistent, and a random
   prefix, different for each request.

  If the intended attack is against the authoritative server
  (such as that for "dafa888.wf" or "wf") exploiting innocent
  resolvers, then I see that.  But if it's about the attack against
  the resolver (forcing it to perform recursive resolutions very
  often), I doubt the mitigation effect of this proposal since the
  attacker can easily circumvent the defense (using '<random>.' or
  existent names in a zone that has a wildcard, etc).  Assuming the
  intended attack is the former type ([balakrichenan-dafa888] seems to
  talk about that type of attack), I suggest stating that more

- Section 5

   In this document, we deduce the non-existence of a domain only for
   NXDOMAIN answers where the QNAME was this exact domain.

  A minor corner case, but I suspect this is not fully accurate if
  QNAME is the name specified in the question section.  If I remember
  it correctly BIND 9 returns an NXDOMAIN if it finds a CNAME chain
  that leads to a non-existent name.  In this case "QNAME" itself
  exists but the response is NXDOMAIN.  I'm not sure if we do
  something about the text because of this, but I'm noting this just
  for completeness.

- References

              Joost, M., "About DNS Attacks and ICMP Destination
              Unreachable Reports", December 2014,

  Getting this URL resulted in 403 error.  Is that only for me?

JINMEI, Tatuya