Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming
Marek Vavruša <mvavrusa@cloudflare.com> Mon, 15 August 2016 17:44 UTC
Return-Path: <mvavrusa@cloudflare.com>
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 2657812D1D5 for <dnsop@ietfa.amsl.com>; Mon, 15 Aug 2016 10:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 vK9X7ys6-PB1 for <dnsop@ietfa.amsl.com>; Mon, 15 Aug 2016 10:44:18 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 AF5A012D1BD for <dnsop@ietf.org>; Mon, 15 Aug 2016 10:44:18 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id u134so30052883ywg.3 for <dnsop@ietf.org>; Mon, 15 Aug 2016 10:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cFyxBZXF21h1zx0vvoDxEdoYiquYONg7vzmUTWRRNGw=; b=ldwY2BHWI0MlyRFAjGyNkjb+KxZsa51HUsn67x636sp/bsic46OwbKSfDEX5c4CU0Y 8ZpoMXf9fvgIA0Ju0CvgsNKNVnx0cRL360LB5t55R7eVi+GtKKitVLY3ZVqk1zWC3olq Vt9zQ/GqPXvToBk8/KPSW+Cu9G1YiN9HVmTh8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cFyxBZXF21h1zx0vvoDxEdoYiquYONg7vzmUTWRRNGw=; b=ZhfdhRRU2Jy/+AtKkVBj98ChF5Y9HtAz+Q1IE+K5Kl+N8QTDN5nq8ZPXpJCKcz47/i S5Vbx2eLD4Fvc3MqO8sh9weaLnelej8DfKauRBkEd+Z8VQ2YMaljvtJUOrXTlpLcSBep scNy9NZvX9BVm8qzDaYwE4sj70JZ/jA9ZLQw46ouB6oJBlop9pi+o+/QasDqv9Fr+Jmp DjBVoHZdLgPh6Iv+Nk5L3Z3vnBK0iQCG4KaYkHYuOVMTuN0KNt3nvWBYEgJsQUf3z1We g0YTn3rqeU5013f0vwYYAiuMR+X0kO0KdURmmZR6XWga99BNdvYXXvkXi98dQZBb3m8h pYeg==
X-Gm-Message-State: AEkooutUMQZdET6X19pVYoy6fJy8X0Oqr/RfJ2G/Xzak3hPIADpVt+reTdGiIrBMq9hiPoNEVuF4i+zmdXFrfKGg
X-Received: by 10.129.114.86 with SMTP id n83mr22963334ywc.100.1471283057542; Mon, 15 Aug 2016 10:44:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.163.227 with HTTP; Mon, 15 Aug 2016 10:44:17 -0700 (PDT)
In-Reply-To: <ADB85FEB-62B8-4ABB-BFD8-74AAABE66E24@vpnc.org>
References: <f8c62b82-258c-2b2b-5186-c3cd8e7d7448@gmail.com> <20160805114511.3ab76c8e@pallas.home.time-travellers.org> <ADB85FEB-62B8-4ABB-BFD8-74AAABE66E24@vpnc.org>
From: Marek Vavruša <mvavrusa@cloudflare.com>
Date: Mon, 15 Aug 2016 10:44:17 -0700
Message-ID: <CAC=TB10eMLGGjdJUumHcco1fmiiDE1T1RdHAY8Wqbi8hzdJihA@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EYQqrLxsD5GKfRRj0cieUiDN2uc>
Cc: Shane Kerr <shane@time-travellers.org>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming
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: Mon, 15 Aug 2016 17:44:20 -0000
On Sun, Aug 14, 2016 at 4:27 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote: > On 5 Aug 2016, at 2:45, Shane Kerr wrote: > >> First, we have: >> >> "If a priming query does not get a response within 2 seconds, the >> recursive resolver SHOULD retry with a different target address from >> the configuration." >> >> The "2 seconds" seems a bit arbitrary. I'm not sure why any >> recommendations need to be made at all. The document already says that >> these are basically normal DNS queries elsewhere - surely that is enough? >> (And maybe if we do want to recommend a retry then we need to be clear >> that if an answer comes from an earlier query that the resolver may >> accept it?) > > > It's sounding like people don't like the mention of a time at all. Proposed > replacement: > > If a priming query does not get a response within a short time, the > recursive resolver needs to retry the query with a different target address > from the configuration. > > (I am avoiding saying "within a configured time" because I don't think this > is easily configured in some common recursors.) Since root-servers.net is not signed, recursor also has to deal with compatibility problems, such as EDNS stripping for example. I wonder how much should be clarified. I was a bit surprised the root-servers.net is still unsigned, is this deliberate or what would it take to sign it? It's a critical zone, and signing it would make this draft much shorter. Marek >> Second, a possible additional security consideration is that a priming >> query typically signals a resolver starting with an empty cache >> (although not always - the Knot resolver has a persistent cache, for >> example). This may be an especially vulnerable time for a resolver for >> cache poisoning. I don't know what can be done to mitigate this though >> aside from requiring TCP or DNS cookies for a time after startup, so >> perhaps this can be left out. > > > Proposed wording: > > An on-path attacker who sees a priming query coming from a resolver can > inject false answers before a root server can give correct answers. If the > attacker's answers are accepted, this can set up the ability to give further > false answers for future queries to the resolver. False answers for root > servers are more dangerous than, say, false answers for TLDs because the > root servers are the highest node of the DNS. > > --Paul Hoffman > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
- Re: [DNSOP] Working Group Last Call draft-ietf-d… Tim Wicinski
- Re: [DNSOP] Working Group Last Call draft-ietf-dn… 神明達哉
- Re: [DNSOP] Working Group Last Call draft-ietf-dn… Marek Vavruša
- Re: [DNSOP] Working Group Last Call draft-ietf-dn… Warren Kumari
- Re: [DNSOP] Working Group Last Call draft-ietf-dn… Paul Hoffman
- Re: [DNSOP] Working Group Last Call draft-ietf-dn… Andreas Gustafsson
- Re: [DNSOP] Working Group Last Call draft-ietf-dn… Bob Harold
- Re: [DNSOP] Working Group Last Call draft-ietf-dn… Paul Hoffman
- Re: [DNSOP] Working Group Last Call draft-ietf-d… Shane Kerr
- [DNSOP] Working Group Last Call draft-ietf-dnsop… Tim Wicinski
- Re: [DNSOP] Working Group Last Call draft-ietf-d… Edward Lewis
- Re: [DNSOP] Working Group Last Call draft-ietf-d… Stephane Bortzmeyer