Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt

Willem Toorop <willem@nlnetlabs.nl> Tue, 12 July 2022 14:36 UTC

Return-Path: <willem@nlnetlabs.nl>
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 BF794C14F728 for <dnsop@ietfa.amsl.com>; Tue, 12 Jul 2022 07:36:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cx9U6Hg48t5y for <dnsop@ietfa.amsl.com>; Tue, 12 Jul 2022 07:35:56 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033D6C14CF04 for <dnsop@ietf.org>; Tue, 12 Jul 2022 07:35:52 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id fd6so10360043edb.5 for <dnsop@ietf.org>; Tue, 12 Jul 2022 07:35:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nlnetlabs.nl; s=google; h=message-id:date:mime-version:user-agent:from:subject:to:references :content-language:in-reply-to:content-transfer-encoding; bh=yljXqUdv4MeZc6l8/VeWsCerpnyowNwzywKhwsCeo2g=; b=hDr+uCUnAyQYGFjTdwyEPfJgr/y0NxSnB72xYr7+j9rCbcPkqOf7xOVFMZS8eG8P7R DPCsv1fSdP+kbsKEyCEPiIE65aG8791IdxUvXyjDtGAjouFbiO0m11tE3Vq3i4qulpdd TIk0UQr2NYpmFyCGsCH/H1NISYIHMFpvXMo4p3QZl1+9NeaxhAWqfkVgXUi/csDUyAYi tpFGW0w1Nv02gjmqWOeGoZkOPR8a4VdJeI7dwH1WxR7HfQEVF+3RdcqMXRJnrskM1i9W NhkhDLk2s2KJWQOqFvlKthUINrMfOyNPkMyMremhauw1nuXl8kvy68jhO+tn+hCMnAUb 9WGw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:references:content-language:in-reply-to :content-transfer-encoding; bh=yljXqUdv4MeZc6l8/VeWsCerpnyowNwzywKhwsCeo2g=; b=VlwI3dbqYK+qwOKRnOpe5eGia9T2k1nfkys2LCPmNEh8Cg13nibA/xFTrcsRTy6WwQ 8m/PInpjAaJiTQsJfhR16mxT+iPbt2ekKONlVKgNkdq3FQe7UyPXi357quEbfRSpxDdG SFDZmZRmQqsC3ERcewwk6XnJDk3NF+70S/3/DH1hBsxLKITGv7VaHwixasopztEBrQDe KNSDSo6u+pCv229d0+JSCHn1D3T5IJZgOOaIMWXDCt5pT5N+7LApEp4rn3r45HOC80og K1doq3a7YfIJyhWumasmUwEg7TdPIcwC125M9y9OQswAxcmY6zxLBntRlwCO8kl7ine3 JA/A==
X-Gm-Message-State: AJIora/fgvgJRBeVDRmqTtKe2+gQxV6OVHe2ZTP1W3oI3qCPk9WC2pky TuQBXZMQack3R4O4pBiI9PUHXtT8nKfvtg==
X-Google-Smtp-Source: AGRyM1uYIDaS6hObZfoTQCQJOh/NrIgl0DFkk6R1vI1Hha7LQkbkREpNuM+PCQB02aURWLS109xTDg==
X-Received: by 2002:a05:6402:278e:b0:43a:9cf5:6608 with SMTP id b14-20020a056402278e00b0043a9cf56608mr32725685ede.76.1657636550741; Tue, 12 Jul 2022 07:35:50 -0700 (PDT)
Received: from ?IPV6:2a10:3781:2851:0:53ee:18be:1ac5:a369? ([2a10:3781:2851:0:53ee:18be:1ac5:a369]) by smtp.gmail.com with ESMTPSA id v6-20020aa7d806000000b0043a6c538047sm6139210edq.70.2022.07.12.07.35.49 for <dnsop@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jul 2022 07:35:50 -0700 (PDT)
Message-ID: <03fcdc90-1857-cefd-5fec-be7ad9422db4@nlnetlabs.nl>
Date: Tue, 12 Jul 2022 16:35:47 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
From: Willem Toorop <willem@nlnetlabs.nl>
To: DNSOP Working Group <dnsop@ietf.org>
References: <165757672414.5113.12045650066277748904@ietfa.amsl.com>
Content-Language: en-US
In-Reply-To: <165757672414.5113.12045650066277748904@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/N4v-lo-LERh1uYKm76xLbNEOk0E>
Subject: Re: [DNSOP] New Version Notification for draft-yorgos-dnsop-dry-run-dnssec-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 12 Jul 2022 14:36:00 -0000

Dear dnsop,

We submitted a new version of a “dry-run DNSSEC” draft. The draft
describes a method that allows for testing DNSSEC deployments in real
world DNS(SEC) deployments without affecting the DNS service in case of
DNSSEC errors. Any encountered errors are signaled to the DNS operator
of the faulty zone with DNS Error Reporting
(draft-ietf-dnsop-dns-error-reporting).

This is a new idea which will be presented during dnsop at the IETF114
and was also presented at the IETF113. A recording of the IETF113
presentation is here: https://youtu.be/watch?v=7HxcmvFOnlU&t=3675s
Slides here:
https://datatracker.ietf.org/meeting/113/materials/slides-113-dnsop-dry-run-dnssec-01

We received a lot of feedback with our presentation which we used to
reorganize the draft to convey the idea more clearly and coherently. We
also received some critique and objections which were non-technical in
nature. Below is a list with these objections followed by our response.

** This is another straw on the camel’s back **

Not all resolvers have to support/implement it. Most important is that
provisioning at the registry and signaling of Dry-run is supported. If
needed we can say it is OPTIONAL for resolvers in the draft. We intend
to implement it ourselves in Unbound and have it enabled by default when
error reporting is enabled. We know from experience with trust-anchor
signaling and sentinel record that with only a small, up to date
resolver population, the signaling is already quite substantial.

There are different kinds of straws and this one is one that has the
good cause of enabling operators to deploy DNSSEC with confidence.


** Why not have a duplicate parallel test deployment? **

There is nothing better than testing with your actual user population to
dry-run your DNSSEC deployment. Note that slack’s parallel test
deployment did not show them the Route53 failure that caused them to
have an DNSSEC outage eventually[1]


** Why not sell DNSSEC domains cheaper? **

Yes, we’re all for that too, but that’s orthogonal to seeing what the
actual effect of starting DNSSEC with your deployment with your real
user population would be.


The other objections which were more technical, like for example
“registries supporting only fixed sized hashes per algorithm” and
“couldn’t we normalize the different DS hacks somehow” are all addressed
in the new version of the document.

We’re looking forward to a new round of feedback and critique ;)
Both on-list and in-person at the IETF-114!

Kind regards,

Yorgos, Willem and Roy


Op 11-07-2022 om 23:58 schreef internet-drafts@ietf.org:
> 
> A new version of I-D, draft-yorgos-dnsop-dry-run-dnssec-01.txt
> has been successfully submitted by Yorgos Thessalonikefs and posted to the
> IETF repository.
> 
> Name:		draft-yorgos-dnsop-dry-run-dnssec
> Revision:	01
> Title:		dry-run DNSSEC
> Document date:	2022-07-11
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-yorgos-dnsop-dry-run-dnssec/
> Html:           https://www.ietf.org/archive/id/draft-yorgos-dnsop-dry-run-dnssec-01.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-yorgos-dnsop-dry-run-dnssec
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-yorgos-dnsop-dry-run-dnssec-01
> 
> Abstract:
>    This document describes a method called "dry-run DNSSEC" that allows
>    for testing DNSSEC deployments without affecting the DNS service in
>    case of DNSSEC errors.  It accomplishes that by introducing a new DS
>    Type Digest Algorithm that signals validating resolvers that dry-run
>    DNSSEC is used for the zone.  DNSSEC errors are then reported with
>    DNS Error Reporting, but any bogus responses to clients are withheld.
>    Instead, validating resolvers fallback from dry-run DNSSEC and
>    provide the response that would have been answered without the
>    presence of a dry-run DS.  A further option is presented for clients
>    to opt-in for dry-run DNSSEC errors and allow for end-to-end DNSSEC
>    testing.
> 
>                                                                                   
> 
> 
> The IETF Secretariat
> 
>