From nobody Tue Nov 9 08:13:05 2021 Return-Path: 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 B1D043A0CA5 for ; Tue, 9 Nov 2021 08:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 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, NICE_REPLY_A=-3.33, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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=isc.org header.b=nrJR5ZjH; dkim=pass (1024-bit key) header.d=isc.org header.b=MDyL1q1v 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 thsM8tjV1iPQ for ; Tue, 9 Nov 2021 08:12:55 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 7E2FE3A0D57 for ; Tue, 9 Nov 2021 08:12:50 -0800 (PST) Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 8A25A434EF8 for ; Tue, 9 Nov 2021 16:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1636474369; bh=uYWvUIki3Jawd190AViQvJqH/Q/5fJAkYM4v61mSnKA=; h=Date:To:References:From:Subject:In-Reply-To; b=nrJR5ZjHSTO3WaqcmzZs8GX84PjjxrJCp08q9i01O8RsYEWuzDPVxQppCBfYlMecJ i84PrVkpRlNjh8FoR+abH+mNnftu3hd4yVBx0nCTdi/IFV2mvoCn7nt66EiALeWUTx I0wmn/5T8D+ItjtZ2DTYJ7mCqafOn6bEmMHREDhU= Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id 8067CF08560 for ; Tue, 9 Nov 2021 16:12:49 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 58D67F08566 for ; Tue, 9 Nov 2021 16:12:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 58D67F08566 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1636474369; bh=ldX6vZ7jOSR3nRi7GR7U8tmD76vrf8bEyXxzuciV/Nk=; h=Message-ID:Date:MIME-Version:To:From; b=MDyL1q1vF/VJUVqmNCJDQ0FsEPg6yD+SEcIz4laljJvVL9vZ3uNqdZ2Lm1HZsnbyd Tfjj5Gg7Kk0QChe3N8hDY6FGFjk9eETQR2GBsU11Jr294hLsHY3P4cps2zCJyRFT3U z+HiadxRWcK+JjqZghHcoTnI6/IQvuEL6H1RxqLY= Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UtoL8h8QhnJX for ; Tue, 9 Nov 2021 16:12:49 +0000 (UTC) Received: from [192.168.0.157] (ip-86-49-254-49.net.upcbroadband.cz [86.49.254.49]) by zimbrang.isc.org (Postfix) with ESMTPSA id E2481F08560 for ; Tue, 9 Nov 2021 16:12:48 +0000 (UTC) Message-ID: <2ad3874d-20f2-9713-e1dd-9d37fc68d010@isc.org> Date: Tue, 9 Nov 2021 17:12:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Content-Language: en-US To: dnsop@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] draft-moura-dnsop-negative-cache-loop X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 16:13:04 -0000 On 08. 11. 21 8:49, Giovane C. M. Moura wrote: > Folks, >=20 > Loops in DNS are an old problem, but as our tsuname[0,1] disclosure las= t > May shows, they are still a problem. >=20 > We wrote a new draft that adds a new requirement to existing solutions: > recursive resolvers must detect and negative cache problematic (loop) > records. >=20 > It would be nice to hear what folks have to say. I generally support the direction, 22+ years after RFC 2308 was=20 published it's time to have a look at it again. If I understand this correctly, TL;DR summary essentially is """ make https://datatracker.ietf.org/doc/html/rfc2308#section-7.1=20 mandatory """ (even though your version is a bit stronger). Is that correct? If it is the case, then the document needs to clearly update 2308=20 section 7.1 and go through standards track. Right now this might not be=20 clear. Ad the draft content: > 2. Past solutions This section somehow does not mention RFC 2308 section 7.1 which solves=20 most of the problem if implemented. In fact BIND has an implementation=20 of it and is not vulnerable to the TsuNAME attack (or at least I was not=20 able to reproduce it). > 3. Current Problem Nitpick: Maybe this should go to Appendix as there is no protocol=20 description in here? > 4. New requirement I think section 4 should not require full blown _loop_ detection, but=20 any sort of limit should be good enough for compliance. I mean, implementing a loop detection algorithm in hot path might not be=20 a good idea, mainly because most of the time it just wastes resources -=20 compared to a simple resource limit like, say, number of delegation=20 steps per query. To be clear: I don't think the resolver _has to_ stop resolution at the earliest=20 moment it has data to potentially detect the cycle. If the cycle has=20 length 2, it should be okay to allow the resolver to do 4,6,8,... steps=20 before giving up. For compliance it should be good enough to stop within=20 "a" reasonable limit (not necessarily specified by a number). An additional nitpick: I think section 4. New requirement sound avoid=20 term "negative" caching. In my eyes it is a bit misleading because=20 "negative" is typically used for different kinds of answers. I hope this early feedback helps a bit. --=20 Petr =C5=A0pa=C4=8Dek