Re: [DNSOP] New draft on delegation revalidation

Petr Špaček <petr.spacek@nic.cz> Thu, 28 May 2020 14:38 UTC

Return-Path: <petr.spacek@nic.cz>
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 A856B3A0F04 for <dnsop@ietfa.amsl.com>; Thu, 28 May 2020 07:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 jx69S0zeCLJB for <dnsop@ietfa.amsl.com>; Thu, 28 May 2020 07:38:15 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E95003A0E3B for <dnsop@ietf.org>; Thu, 28 May 2020 07:38:14 -0700 (PDT)
Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:1488:fffe:6:5c39:29ff:fe8a:696c]) by mail.nic.cz (Postfix) with ESMTPSA id 18C0B14056E; Thu, 28 May 2020 16:38:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1590676692; bh=9rP9zByXBqgLcR6XgVz36LmhzbFPttWD4LuUHSTT1yw=; h=To:From:Date; b=F7MEiK8vxudI2I4DfgF+tpsET2JsvYqEhSmtEm87DS/Js7l0WT7ByeZ5Amin2pf68 OAmL76fv0lHML3y5bAfTVRHc5wsSxVORUkBetM0hypRU3b1bktyLCdz1EZZ68TBTDx F2XeS1z8j0PkuuLX3Sts/hWynafvzE+6Iinvk2W4=
To: Shumon Huque <shuque@gmail.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
References: <CAHPuVdV9eSCLQOqMF0cq8fHcuSZs7nCgjhHMfMoaV5H=ekbtSA@mail.gmail.com> <7dd08da3-72f8-f25a-c6be-4ff7f76a4084@nic.cz> <CAHPuVdX29yLG4VFMLq8ad7wgq2N-L=FfG=f-eBd2F6aP_q6CCg@mail.gmail.com>
From: Petr Špaček <petr.spacek@nic.cz>
Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAl4QsCEFCQeWKZ8ACgkQzo3WoaUKIeRd HBAApKY18pJ+g172AeAefYwPoIZRM5WDNopHw/l7ErfMNzm9Da0/gOy8CUH2gA+qF+ufryIs DY0akLVaL7X21+hAp3gFX+/GHqSjJcmWvEfU7eoLl9OxE8NvQd2V/DPVDqnQscTUUba5taAU OM51bU+vCNQXlT3uuntIOwwbB9W6hMSe16EhB9mzj6hozyTemsfHTjoNJbVrhLzf3Idnp3fY rO0qfqOlwIi+5YWT0SHSVx6zmOBStzT4otRtFyfKD+CXdFOt40Dw1qYlZt2ms3kcaEk/+Uub SKZhr5IsSE5rV8TasKiQvP/ToxPyk1QkqCrzzroGrkMHfzW7MACvpKWnQAjhiVuO++Ne4XMJ h8zL0c31u5MQ76zckowHtGy9plwKFoIrtRB2UgwjtvTSkXn7nC6YVoDlCe/WD7PYfpig9iaO bQwP3fAq+sx+BU6eIZC7edZU8rqi3SWrg4p9jH0SmU1BwO7dwgbMyAEYpiv+mNu9pIBFxLqL ihSk+1M+Y3EaJP0QeKFI6qeZuJAOhkO4Gi7lTLXo4AepjnKPzN15LJJBg3W9t9Zss/Hp11se r/N87fn6XlzV+yfq0gYwJufF2MsDVaU3NQhT/0cXks6Gh4MvUcEircxTaAbaEP7mbMc5o4S4 n0V+MoU+ohqRrPW9gngGxIziKeFey4RBIKfpLgC0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAl4QsBwFCQeWKZ8ACgkQzo3WoaUKIeTkEQ//eyj4Odb1AoZJk6Y0 wkPG+9vvC1UwIOMPlerIzHv3ukrSCBdNQG/1vfaDH/xM8ywHHGKnvrIoGbuAyO6llLvo8Mir JwnqRmcChkFPwx78piJPHdWGQzQT9lWObEgwwonB9xQmxU7ih8WKfBpB+ME9knYycoYJwXiJ vLTjQg5Xe2eXa8fbiNY+v2B3Wwza41Ke7dzYUcdPAMaDPhX4x3GeWUv+y1WP7mFAi2JxQV/L ZZuiYVDR526wwWOe6DZyUZC9S6qD6qaPvqJ/j3hzgSBpJUvSDlvmsdWAZZd9bUbMgU4BpwLv 7yh/6NyQGRs3SuCjmRKek7rS+dngqYNAYISSKnFDvst00kGBmT8/Ys2oB/VXqAsP+ej0Qp1g XyV2gfIbzSIHwFOXgX7+fVN8qqqcToOZJ8ibfbshSrrEZ69QGHTZcU/wbVRmLl1Nrk0BEEd8 lTFhbl13eJkUN5jlWdTofW/mYoccvySMJP7IzVri+6UjS2JB/CcCR/v9g0vl2tmt5hc+XGNu m6sVfLcF2fbG+tkmm1tjzwSYcbhGetQ8Gq0mtpuglnetRPLqvEvbcJBISMG2Dnu1o7epMVbe qmFqRuYrEWncuK/k2BCla1G+a+0PUwNdRXHpBlHnWnaE9FzT8GU0L23p1dcj/vCUH9Z5b9uz OygWMJcrpXjAxMUsUPa5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXhCwQQUJB5YpxAAKCRDO jdahpQoh5KUKEACZrrC0gOit1Ur0UQ/DL0wqIFPGmNW6bvBuyASm8HMpBA/ip6SqIebejC/Q lGU88Of7csaadKXlcAtN2W2eyKX+pwrIGlL9+laHDu+Gn8wG+0uUDSIEIS7juhycLRa2rNwh dx89ArwmAs+UNglXPqIc9nfMXK4tXdJSAjk7yekd/0WRc2fjsY292C4hQ51/vUpMpU+cDFw/ bwW7t7HEL/oRkRpDkPufFSLPfGVX2rqRnKaDM4xmpUXB5N2PC65umPxRq/YY3f+j/jAfaWWB 27SFiRpC4T48HNse0ZGKoeWnfYZpyYqnIRSURLu0ykYr9B90S/MteKxHDALNfllocQOgM0Bn Ama5S+cVqew97CJEAthW7PGe6Oa3k+dH340svGvrTFdJGH/3hCGDw3b3o4vV8F653fBk0qHJ UO7QoFaCuTFhQhCUEP3EVGFeT/TR4lGGUtmdeiyUgymzp3yVVYNgf+t4LO/+CIK8uFQAA+cx xNlj5NXS5+vyy2bQ8paZIw0B0pInOSvxQywwLPr8hv0gnOLMTmBPwPAsJsW4wwFe6CIHSNW1 Ctj7N4X/CwAzGZ1s8jTuWXoaJT7UaycXQpi8mRnMBoDM/mS/xiKMlXPbAbKgbhaVpziTNJzo IX3KjUN/6ZGVnN22b886q+lffrx5QYuxHwIA0gHzJiBopEjrOQ==
Organization: CZ.NIC
Message-ID: <0f92991e-991a-f497-9b75-cf924512b0ba@nic.cz>
Date: Thu, 28 May 2020 16:38:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <CAHPuVdX29yLG4VFMLq8ad7wgq2N-L=FfG=f-eBd2F6aP_q6CCg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US-large
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cIk6eLbq-FshjPEJI7FT1U1qBLA>
Subject: Re: [DNSOP] New draft on delegation revalidation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 28 May 2020 14:38:18 -0000


On 25. 05. 20 5:23, Shumon Huque wrote:
> On Thu, May 21, 2020 at 8:24 AM Petr Špaček <petr.spacek@nic.cz <mailto:petr.spacek@nic.cz>> wrote:
> 
>     >
>     >    https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
> 
>     I would appreciate a practical example of changes envisioned in the following paragraph:
> 
>     >    A common reason that zone owners want to ensure that resolvers place
>     >    the authoritative NS RRset preferentially in their cache is that the
>     >    TTLs may differ between the parent and child side of the zone cut.
>     >    Some DNS Top Level Domains (TLDs) only support long fixed TTLs in
>     >    their delegation NS sets, and this inhibits a child zone owner's
>     >    ability to make more rapid changes to their nameserver configuration
>     >    using a shorter TTL, if resolvers have no systematic mechanism to
>     >    observe and cache the child NS RRset.
> 
>     Could someone please post an example in steps? Something like:
>     - time 0, NSSET parent = {P0}, NSSET child = {C0}
>     - time 1, NSSET parent = {P1}, NSSET child = {C1}
>     ... along with textual description what operator is hoping to achieve?
> 
> 
> I'll try to come up with a step by step example later. But in the example
> cited, what the operator is trying to achieve is to change their nameserver
> configuration (e.g. switch to another set of nameservers for their zone) in
> such a way that (1) they can make that change visible to resolvers 
> reasonably quickly, and (2) to make sure they are able to backout that
> change quickly if things go wrong. They can do this by lowering the TTL
> in the child NS set which is under their control -- assuming that resolvers are
> preferentially caching the child NS set, in accordance with the data ranking
> rules of the DNS protocol (the child NS set is authoritative).
> 
>     Ad 4.  Delegation Revalidation:
> 
>     I agree with author's note "we would prefer to discard the extensive mechanism" but the simple mechanism has simple description for me to understand consequences.
> 
> 
> I've heard the same from other implementers too. Paul V has mentioned that there are some subtle corner cases that are dealt with more precisely by the extensive algorithm (I can't recall the details right now, but maybe he will elaborate for us). Even if we end up on the simple path, it would be good to have a better understanding of those cases.
> 
>     >    The simple mechanism:
>     >
>     >    o  Cap the time to cache the child NS RRset to the lower of child and
>     >       parent NS RRset TTL.  The normal iterative resolution algorithm
>     >       will then cause delegation revalidation to naturally occur at the
>     >       expiration of the capped child NS TTL, along with dispatching of
>     >       the validation query to upgrade NS RRset credibility.
> 
>     So far so good, but it does not specify what should happen with RRsets other than NS. Even if nothing is prescribed please state that explicitly.
> 
> 
> Thanks, yes I agree we should discuss all of these. Some quick thoughts for now ..
> 
>     Most importantly:
>     - Does the NS affect maximum TTL of _other_ data in the zone?
> 
> 
> I think there are probably different views on what should happen here. Folks who want very prompt takedown of "bad" domains, will probably prefer a complete pruning of the cache at the delegation point at the revalidation interval, if the NS set has changed or disappeared. When this topic has come up in the past, there has been pushback from some implementers that it's difficult to do this because they use a non-tree data structure for the cache (a hash table most commonly). Most resolvers these days already enforce a max cache TTL parameter, so that typically prevents too much abuse. But at the very least, they should probably use the revalidation interval as a signal to stop "pre-fetching" records below the cut.
> 
>     - If it does, doesn't it increase risk of thundering herd behavior?
> 
> 
> Possibly, depending on how popular the zone is, and what we decide is the answer to the previous question. At any rate, implementers should always employ strategies that bound how much work resolvers can be caused to do.

I'm not concerned about any single resolver instance, I'm more concerned about large number of resolver instances doing the same thing at the same time.

E.g. if NS TTL was short (say 30 s) and it was used as cap on TTL of all other records in the zone, then each resolver instance would clear zone from its cache each 30 seconds. That might cause interesting behavior when NS TTL is shortened e.g. before NS set change etc.

I do not know if there really is a problem, I'm just trying to explain why potential for thundering herd needs to be be seriously analyzed.


> 
> It might be reasonable to suggest that resolvers enforce a lower limit on the child NS TTL (5 minutes?). If they see something less than that, it would be set to the limit instead.
> 
>     - If it does not, is it even worth the effort if attacker can put week long TTL for A/AAAA and keep using that?
> 
> 
> Answered above ... 
>  
> 
>     - How should resolver handle RCODE=NXDOMAIN? Should it have different effect than changing NS set to different set of servers?
> 
> 
> If resolvers are following RFC 8020 strictly, they are pruning their cache at the delegation - that would be the ideal. Otherwise, they should allow cached records below to live on, subject to max-cache TTL and disabling of pre-fetching.
> 
>     Or change in DS record value?
> 
> 
> Which value? TTL or RDATA?
> 
> DS TTL expiration would automatically trigger a revalidation of the child SEP keys at the parent. RFC 4035 says DS and delegating NS TTL SHOULD match, so NS revalidation should happen on the same time scale. In reality though, they are often different (COM/NET uses 2d for NS, 1d for DS). if NS > DS, a resolver could just decide to explicitly fetch the expiring DS first and wait out the delegating NS TTL if the DS rdata has not changed. But it seems much simpler to just say that  if there is a secure delegation, then the DS TTL should be used as the NS revalidation interval too.
> 
>     For me personally mixing two problems (GHOST domains and NS inconsistency) in single proposal does not help me to understand reasoning behind the proposal and its intended effects.
> 
> 
> Ok, we'll think about how to make this clearer. But the two topics are related. If resolvers prefer the authoritative child NS set, then timely revalidation of the delegation at the parent is also necessary.

Yeah, you are right. It is probably good idea to discuss both at once because it will force us to find compromise between the two. E.g. most aggressive approach where resolver prunes cache on mere NS set _change_ might increase fragility when someone makes mistake while doing NS set change etc.

Having said that, I still think it would help if arguments/requirements for each use-case (GHOST vs. NS inconsistency / malicious vs. well-behaved operator) were laid out separately and then document reconciled arguments from these two camps and reached single recommendation for resolver implementers.

-- 
Petr Špaček  @  CZ.NIC