From nobody Tue Oct 19 05:48:18 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A523E3A0C92 for ; Tue, 19 Oct 2021 05:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de 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 2ZMXtL-Tgq6q for ; Tue, 19 Oct 2021 05:48:10 -0700 (PDT) Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 9AEC93A0C54 for ; Tue, 19 Oct 2021 05:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=TolBJENYEmrR2tqTWYi0vLpkwQuBoIW0hVcEKz2LiI8=; b=SQ1GbMMe1UJVlDcB3ARGfIyqnd Eukn6zu3onNQ/Sy4FhBiOSlUFmptWopKLyaUVbUHtj6KItZw3BXh+FEex1mRple3LPDta1S2goT+c Jh+Epn0pgapwz2Fl+5Y6tHPomCu8B7HOVyl4eO+AMP71UWRRbDbVIOA1AJu6ztCGj+HLK1HgZYTFD EH04G4JuOkT7ETYdZZwxICDp7cLExwpBA60qS6OJLeSfaEQuEyrMc8NUDrffh+yzm2OmgljJ0XreT o5lMTQ+BBmoPxAafx0X504VRMkfbR6OXSn5bEjhAFch6SHQW7nldFhSEhGLdt8oj8nDBFVuGJbY5/ mblKdK3A==; Received: from [213.61.118.178] (helo=[192.168.188.94]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mcoXD-0003PE-Ue for dnssec-bootstrapping@ietf.org; Tue, 19 Oct 2021 14:48:04 +0200 To: dnssec-bootstrapping@ietf.org From: Peter Thomassen Message-ID: <20de3f7d-2793-34a1-1a4f-a37518d31384@desec.io> Date: Tue, 19 Oct 2021 14:48:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: [DNSSEC-Bootstrapping] Status X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 12:48:16 -0000 Folks, I quickly wanted to check in with you what the status is on DNSSEC Bootstrapping. 1.) Draft --------- My impression is that the draft is in quite mature shape, and we've converged on most questions. Of the remaining issues, only one affects the protocol format (everything else is about defining operational practice, such as when to trigger a bootstrapping scan). I'll send a separate message about the protocol format issue. We have requested slots to present at ICANN 72 and IETF 112, and are planning to ask the DNSOP WG for adoption around that time. Link: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ 2.) Implementation status ------------------------- deSEC is running bootstrapping zones at _boot.ns1.desec.io and _boot.ns2.desec.org, which contain bootstrapping signaling records for about 14,000 domains. (This is currently not automatically synced when a new domain is created at deSEC. If you need a new domain to show up, please send me a note.) Regarding other DNS operators, registrars and registries on this list: Would you like to share what your current plans are? Thanks, Peter -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 From nobody Tue Oct 19 06:05:43 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED43A0CBA for ; Tue, 19 Oct 2021 06:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de 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 DQZebzdIaWba for ; Tue, 19 Oct 2021 06:05:34 -0700 (PDT) Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 BB3043A0CB9 for ; Tue, 19 Oct 2021 06:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cthkZLWDxUOM6GMHEDQVOFb1A06Qk/JRqRumEhUc0qc=; b=OpDTVgexwg77RMXIMVXIjYa8Fw 3EZRCw3f/WwHgZh2H1UTPlyf5lD3PBLYC/iNnnYrdjaJtw6jmhfNqNmADxSQqV9P+h8BiDKQ+jjfh YsCdS6WXZPHR65IqeJTBz1saWkVvaJwSWuR9ZHL4xGU4DvQ/o3Y9RYb667618TjqrWeU7YF7EMEFS p6foKLYm2W4iGrNvB4u6pFRbOPqpehaxytwU67NATsPOluB0MoA8JIl0V3NG0y4T+rOJk2g1W4KrY iHOEFNC9pkbusTA2RosVYzp4/4hwqiZkL1YdYeEs91zXG2Hs5nm76AVVj6X8QLrIf0PJ7b442ErQT 79BKDesw==; Received: from [213.61.118.178] (helo=[192.168.188.94]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mcoo8-0004Lw-Eq for dnssec-bootstrapping@ietf.org; Tue, 19 Oct 2021 15:05:32 +0200 To: dnssec-bootstrapping@ietf.org From: Peter Thomassen Message-ID: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> Date: Tue, 19 Oct 2021 15:05:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: [DNSSEC-Bootstrapping] Sharding? X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 13:05:42 -0000 Hi all, In my other email, I mentioned an open question about the protocol format. Here you go. So far, the owner name of the signaling record for example.co.uk hosted on ns1.provider.net is: example.hash(co.uk)._boot.ns1.provider.net For a given second label such as hash(co.uk), the first label will indicate all the (bootstrappable) domains that the DNS operator manages under that ancestor. In case of the .com zone, I can imagine this to be a number that is potentially very high. (The concern does not apply to the second label, as many domains will have the same ancestor.) 1.) Do you think that this will be a problem for anyone, such as at the scale of Cloudflare? 2.) If yes: What could be done about it? a. One migiation could be to synthesize signaling records ad hoc, but that requires auth support. b. Another way would be to introduce some kind of sharding (= splitting the first label into several, possibly based on a few hash digits). c. ...? I am not sure this is really a problem at all, but an approach like 2.b) would be a protocol change, so it will be hard to do it later. That's why I'm interested in your opinions. (If nobody thinks this is a problem, we can close it right away.) Cheers, Peter -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 From nobody Tue Oct 19 09:30:51 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF42B3A0D45 for ; Tue, 19 Oct 2021 09:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20210112.gappssmtp.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 wzavwviYResU for ; Tue, 19 Oct 2021 09:30:42 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 255013A0CBE for ; Tue, 19 Oct 2021 09:30:41 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id ec8so15256553edb.6 for ; Tue, 19 Oct 2021 09:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=58YQtW8FtHwVEK/h9ZzrFitCdSo/8BWo5WwOgVPY3gU=; b=oiar1SN3AAsrznd+qoCKoypQ48qdtdTzvSJYg3WtnQSQH+IZKgBs9Tn5wuYRmqZmyS RJvWNGozLrg7jqV7ND/a3o6eo7hhDlNh9wrXo2a2M77hxuEp4qSx9R8O+hlSl8reKg3K uM1sOGaklrQE2vdGun52bI72vNmcRQWHWWwuLWq9gdv+45/TUdqLtgklfR7JXS6O06W8 gbvPz/BPHQ4nkud3Rt38nuWKES2GILiC1G9re3OSB7RQaaEyOJyu2ftqwWfwSrmeJBmN ggp54m+Hmkg80Bij/ah+APZ56X6n1prc9Cncspvrq4WH1Kc4O3S1Vk61meAgJkRHj4ra qF7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=58YQtW8FtHwVEK/h9ZzrFitCdSo/8BWo5WwOgVPY3gU=; b=196iaOe8FS7gxvJHeSym0PawRq1kFZi7QfG7f+ggs/hHUGKqLBVliQhhBwOQiJwG1p EckUKJZh69UTQVbL5I8hYQp3CWZ37LYiL6e1s9227+Cs6/9m5CVOi1S3qsrSCaMLWid2 m/BFC6eUPNlD5geqT5+dxFZupW8v1zuBCnPH2RPwF8k68lmieHCliG+jvqjcMDIDLuQC PxhnMZHPCQxnrtAHUPZlcC4VLvuCfKRshTho0UN/qUItmcgqep6QXaYwBOIlqeZzOcFd QjTN7dUe20OggR/M68BR4ViNUORfrL/AofNBUdVOr4QwoGgy92EFMZvj+uabamVJj77x Sy0w== X-Gm-Message-State: AOAM533wOSIBM1fctGC47Ft+oXmM1My5YQVa3z9QxL9mS62RbY1E+o1V yMkDesfkyD/vTbHkJP8FLxqGGw3b0Cg7dFFc4Miz00LgrfVJeA== X-Google-Smtp-Source: ABdhPJwquNdkZqUFEtwu5KMkRQxpY6TF/QrzqmEeCqyx5Bpu+0id1lPxOkp/w0rjZ2NdrX/al6NNjFzROJtBYm+rGOA= X-Received: by 2002:a05:6402:4382:: with SMTP id o2mr53925227edc.271.1634660880499; Tue, 19 Oct 2021 09:28:00 -0700 (PDT) MIME-Version: 1.0 References: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> In-Reply-To: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> From: Steve Crocker Date: Tue, 19 Oct 2021 12:27:48 -0400 Message-ID: To: Peter Thomassen Cc: dnssec-bootstrapping@ietf.org Content-Type: multipart/alternative; boundary="0000000000001d17c205ceb72554" Archived-At: Subject: Re: [DNSSEC-Bootstrapping] Sharding? X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 16:30:48 -0000 --0000000000001d17c205ceb72554 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Peter, The sentence For a given second label such as hash(co.uk), the first label will indicate all the (bootstrappable) domains that the DNS operator manages under that ancestor. raises a question of nor only whether the number is too large but also how frequently it changes. How accurate does this have to be? If it's supposed to be completely accurate, this will likely be out of date very quickly for a large domain. Thanks, Steve On Tue, Oct 19, 2021 at 9:05 AM Peter Thomassen wrote: > Hi all, > > In my other email, I mentioned an open question about the protocol format= . > Here you go. > > So far, the owner name of the signaling record for example.co.uk hosted > on ns1.provider.net is: example.hash(co.uk)._boot.ns1.provider.net > > For a given second label such as hash(co.uk), the first label will > indicate all the (bootstrappable) domains that the DNS operator manages > under that ancestor. > > In case of the .com zone, I can imagine this to be a number that is > potentially very high. (The concern does not apply to the second label, a= s > many domains will have the same ancestor.) > > 1.) Do you think that this will be a problem for anyone, such as at the > scale of Cloudflare? > 2.) If yes: What could be done about it? > a. One migiation could be to synthesize signaling records ad hoc, > but that requires auth support. > b. Another way would be to introduce some kind of sharding (=3D > splitting the first label into several, possibly based on a few hash > digits). > c. ...? > > I am not sure this is really a problem at all, but an approach like 2.b) > would be a protocol change, so it will be hard to do it later. That's why > I'm interested in your opinions. (If nobody thinks this is a problem, we > can close it right away.) > > Cheers, > Peter > > -- > Like our community service? =F0=9F=92=9B > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Kyffh=C3=A4userstr. 5 > 10781 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > > -- > DNSSEC-Bootstrapping mailing list > DNSSEC-Bootstrapping@ietf.org > https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping > --0000000000001d17c205ceb72554 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peter,

= The sentence

=
For a given second label such as hash(co.uk), the first label will indicate all the (bootstr= appable) domains that the DNS operator manages under that ancestor.<= /div>

rai= ses a question=C2=A0of nor only whether the number is too large but also ho= w frequently it changes.=C2=A0 How accurate does this have to be?=C2=A0 If = it's supposed to be completely accurate, this will likely be out of dat= e very quickly for a large domain.

Than= ks,

Steve


On Tue, Oct 19, 2021 at 9:05 AM Peter Thomassen <peter@desec.io> wrote:
Hi all,

In my other email, I mentioned an open question about the protocol format. = Here you go.

So far, the owner name of the signaling record for example.co.uk hosted on <= a href=3D"http://ns1.provider.net" rel=3D"noreferrer" target=3D"_blank">ns1= .provider.net is: example.hash(co.uk)._boot.ns1.provider.net

For a given second label such as hash(co.uk), the first label will indicate all the = (bootstrappable) domains that the DNS operator manages under that ancestor.=

In case of the .com zone, I can imagine this to be a number that is potenti= ally very high. (The concern does not apply to the second label, as many do= mains will have the same ancestor.)

1.) Do you think that this will be a problem for anyone, such as at the sca= le of Cloudflare?
2.) If yes: What could be done about it?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. One migiation could be to synthesize signali= ng records ad hoc, but that requires auth support.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. Another way would be to introduce some kind = of sharding (=3D splitting the first label into several, possibly based on = a few hash digits).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. ...?

I am not sure this is really a problem at all, but an approach like 2.b) wo= uld be a protocol change, so it will be hard to do it later. That's why= I'm interested in your opinions. (If nobody thinks this is a problem, = we can close it right away.)

Cheers,
Peter

--
Like our community service? =F0=9F=92=9B
Please consider donating at

https://= desec.io/

deSEC e.V.
Kyffh=C3=A4userstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

--
DNSSEC-Bootstrapping mailing list
DNSSEC-B= ootstrapping@ietf.org
https://www.ietf.org/mailman/listinfo/dns= sec-bootstrapping
--0000000000001d17c205ceb72554-- From nobody Tue Oct 19 11:10:56 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1164A3A0954 for ; Tue, 19 Oct 2021 11:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 j82eJ2ReqrCp for ; Tue, 19 Oct 2021 11:10:48 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 8544B3A094D for ; Tue, 19 Oct 2021 11:10:48 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id n7so7772543ljp.5 for ; Tue, 19 Oct 2021 11:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sea5/jIC3CrerwWtMaP+kIm+dwl7iExVwtN3MHmkI6s=; b=K4IGmjEEtEFVTJK3sBqmYNgy+1KxFgoYQrbek4SzP88JxH6uWfkPTTFzprujdIiHW8 nwmb+vSiLKRwTwY/HiBYLptQ04hY9WFxiLOqanHgCngV83KjqLYrhU011FW2nRwNNd1V cZRZUu0Jh/SqJtMIJwYFQ8wpcHg3X8LThQyycAG5RqGpYdsD/8UOAmMacd4fU5K9G3A/ 8Ao7UMPm7rK3vE/qgsVY7ct+ooqzsuTI2ZGb70XEw177mryHk/HNh/yE1csGkOSXisKU NfxOVpDj74Kk5e4EljTrYZwhYoFNJqk5KXBRuwn5FpW2v7UMrgYacuohS+BwujAiDfZZ plRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sea5/jIC3CrerwWtMaP+kIm+dwl7iExVwtN3MHmkI6s=; b=XwTN3h0x7/nvB6o551uJI3rEjZZkkRDkir5UWOYaEQr479+/UCQy7NeMA34reXTX9E g5G2XMrYxnEkpUV7decbF1Y7UyUCPECONleM+EBWnoa6Y+oHRafGRDud8x28a4LNDrzk iwwZV7P1g9NC+/zmz8BKBS5N+20T1QYofxKdx3waaoBbHUtKHnngRrHH3RWvgG6TTLEh vrDiANMssjUEetaLqACMAp8dZqjKC4NdGAj8ZuCqtIF77yVNw0oPKFAw8XF4qNLmG/Lh HxLjFstQwqzVVYnuyuXt27HoCTcxCup4W3PLftBKcIFLWKUmeXIn8zdblpr1x/TfZzy9 1X8w== X-Gm-Message-State: AOAM531DYmbyagwExo2RTNX0cp8m1JAeR7W1y7SHPnpvaFeFaNuMRO6x YoXEImXZINw0bFLOTMkgV+nG5pdkNOWwcC5iZow= X-Google-Smtp-Source: ABdhPJza16zL+J7CZpyEs400F24zWBry7F9ykhPQzsHlS6HggrbXUjlukvDiuACxKPt/O8iFYveGqqA+6fbor6CQa+k= X-Received: by 2002:a2e:98d2:: with SMTP id s18mr8539743ljj.266.1634667045117; Tue, 19 Oct 2021 11:10:45 -0700 (PDT) MIME-Version: 1.0 References: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> In-Reply-To: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> From: Brian Dickson Date: Tue, 19 Oct 2021 11:10:34 -0700 Message-ID: To: Peter Thomassen Cc: dnssec-bootstrapping@ietf.org Content-Type: multipart/alternative; boundary="0000000000008ce10205ceb894e8" Archived-At: Subject: Re: [DNSSEC-Bootstrapping] Sharding? X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2021 18:10:54 -0000 --0000000000008ce10205ceb894e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the preferred model is to have the bootstrapping zone reflect only pending bootstrap domains, i.e. that need to go secure but have not yet gone secure. Once a zone is securely delegated, the operator should remove the bootstrap entries. It is basically the same logic as CDS/CDNSKEY. Thus, the size of a given operators bootstrap zone would reflect the rate of new zones going secure, not the total number of zones that are secure. (This scales really well for large and small operators, I believe. Especially with automation involved.) Brian On Tue, Oct 19, 2021 at 6:05 AM Peter Thomassen wrote: > Hi all, > > In my other email, I mentioned an open question about the protocol format= . > Here you go. > > So far, the owner name of the signaling record for example.co.uk hosted > on ns1.provider.net is: example.hash(co.uk)._boot.ns1.provider.net > > For a given second label such as hash(co.uk), the first label will > indicate all the (bootstrappable) domains that the DNS operator manages > under that ancestor. > > In case of the .com zone, I can imagine this to be a number that is > potentially very high. (The concern does not apply to the second label, a= s > many domains will have the same ancestor.) > > 1.) Do you think that this will be a problem for anyone, such as at the > scale of Cloudflare? > 2.) If yes: What could be done about it? > a. One migiation could be to synthesize signaling records ad hoc, > but that requires auth support. > b. Another way would be to introduce some kind of sharding (=3D > splitting the first label into several, possibly based on a few hash > digits). > c. ...? > > I am not sure this is really a problem at all, but an approach like 2.b) > would be a protocol change, so it will be hard to do it later. That's why > I'm interested in your opinions. (If nobody thinks this is a problem, we > can close it right away.) > > Cheers, > Peter > > -- > Like our community service? =F0=9F=92=9B > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Kyffh=C3=A4userstr. 5 > 10781 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > > -- > DNSSEC-Bootstrapping mailing list > DNSSEC-Bootstrapping@ietf.org > https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping > --0000000000008ce10205ceb894e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the preferred=C2=A0model is to have the bootstrapp= ing zone reflect only pending bootstrap=C2=A0domains, i.e. that need to go = secure but have not yet gone secure.
Once a zone is securely delegated, = the operator should remove the bootstrap entries.
It is basically the s= ame logic as CDS/CDNSKEY.
Thus, the size of a given operators boo= tstrap zone would reflect the rate of new zones going secure, not the total= number of zones that are secure.
(This scales really well for large and= small operators, I believe. Especially with automation involved.)

Brian

On Tue, Oct 19, 2021 at 6:05 AM Peter Thomass= en <peter@desec.io> wrote:
<= /div>
Hi all,

In my other email, I mentioned an open question about the protocol format. = Here you go.

So far, the owner name of the signaling record for example.co.uk hosted on <= a href=3D"http://ns1.provider.net" rel=3D"noreferrer" target=3D"_blank">ns1= .provider.net is: example.hash(co.uk)._boot.ns1.provider.net

For a given second label such as hash(co.uk), the first label will indicate all the = (bootstrappable) domains that the DNS operator manages under that ancestor.=

In case of the .com zone, I can imagine this to be a number that is potenti= ally very high. (The concern does not apply to the second label, as many do= mains will have the same ancestor.)

1.) Do you think that this will be a problem for anyone, such as at the sca= le of Cloudflare?
2.) If yes: What could be done about it?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. One migiation could be to synthesize signali= ng records ad hoc, but that requires auth support.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. Another way would be to introduce some kind = of sharding (=3D splitting the first label into several, possibly based on = a few hash digits).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. ...?

I am not sure this is really a problem at all, but an approach like 2.b) wo= uld be a protocol change, so it will be hard to do it later. That's why= I'm interested in your opinions. (If nobody thinks this is a problem, = we can close it right away.)

Cheers,
Peter

--
Like our community service? =F0=9F=92=9B
Please consider donating at

https://= desec.io/

deSEC e.V.
Kyffh=C3=A4userstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

--
DNSSEC-Bootstrapping mailing list
DNSSEC-B= ootstrapping@ietf.org
https://www.ietf.org/mailman/listinfo/dns= sec-bootstrapping
--0000000000008ce10205ceb894e8-- From nobody Wed Oct 20 09:21:34 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919083A090B for ; Wed, 20 Oct 2021 09:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=a4a.de 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 ei1UjGBWHP4l for ; Wed, 20 Oct 2021 09:21:25 -0700 (PDT) Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 B1FC03A08EC for ; Wed, 20 Oct 2021 09:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Subject:From:References:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ao5DGMTZG7z9D58hgDaRNRm+8bIfHVkKvJa9pWcOKOU=; b=sKqI+89QkbACo+h8xbRjxPpUch O6ga0/biBtX65AJuyx3A7XGZNZlhoTwxrOio0+Ks58PrJgjO58pO4aNtGmG2dkVnshj83qfkV/ECL rVp51g1DzU3kYTPSS/YREO5SBJLbP+QneFZAtBrjpWno2mNVoyPZdA11q/38NWKUnJKj1ND2O82T1 BXbLXMNZJ9mIWJLaZ1XqWsbOpRyAY+CdUcHInm3OE70VvPM3gZOuBtjiMZepaFG8IiD50wEyffupl 9tE+uds/yLuTiaKleqeLXVzuBvGHnpqMArmvT2Vofh3odjKDFb3p161XkPvG7JKdktIBSDUNcS7aU j4Kf/I0Q==; Received: from ip-109-40-240-5.web.vodafone.de ([109.40.240.5] helo=[192.168.255.245]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mdELB-0002or-Dv for dnssec-bootstrapping@ietf.org; Wed, 20 Oct 2021 18:21:21 +0200 To: dnssec-bootstrapping@ietf.org References: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> From: Peter Thomassen Message-ID: Date: Wed, 20 Oct 2021 18:21:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSSEC-Bootstrapping] Sharding? X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 16:21:32 -0000 Hi Brian, Christian, On 10/19/21 8:10 PM, Brian Dickson wrote: > I think the preferred model is to have the bootstrapping zone reflect only pending bootstrap domains, i.e. that need to go secure but have not yet gone secure. > Once a zone is securely delegated, the operator should remove the bootstrap entries. I agree with your sentiment that the bootstrapping zone should only contain pending bootstrappable domains, and that records should be cleaned up once corresponding delegations have been secured. That's also what the draft is saying. However, if the parental agent (registry/registrar) does not support the mechanism, bootstrapping records may remain in place more or less indefinitely, until the parent changes their mind (or DS records are provisioned manually). In that case, a large number of records could accumulate under certain hash(ancestor) labels. Do DNS operators think this is a problem that needs to be addressed? > It is basically the same logic as CDS/CDNSKEY. Yeah. In fact, those may also stay for quite a while, but they are in different zones, and keeping them doesn't cause any harm. > Thus, the size of a given operators bootstrap zone would reflect the rate of new zones going secure, not the total number of zones that are secure. > (This scales really well for large and small operators, I believe. Especially with automation involved.) The derivative of the bootstrapping zone's size reflects the rate of new zones going secure (assuming a constant set of zones), but the size itself also has a constant offset that reflects lack of support at the parent. On a different note: What's your take on Steve's concern? Thanks, Peter > Brian > > On Tue, Oct 19, 2021 at 6:05 AM Peter Thomassen > wrote: > > Hi all, > > In my other email, I mentioned an open question about the protocol format. Here you go. > > So far, the owner name of the signaling record for example.co.uk hosted on ns1.provider.net is: example.hash(co.uk )._boot.ns1.provider.net > > For a given second label such as hash(co.uk ), the first label will indicate all the (bootstrappable) domains that the DNS operator manages under that ancestor. > > In case of the .com zone, I can imagine this to be a number that is potentially very high. (The concern does not apply to the second label, as many domains will have the same ancestor.) > > 1.) Do you think that this will be a problem for anyone, such as at the scale of Cloudflare? > 2.) If yes: What could be done about it? >         a. One migiation could be to synthesize signaling records ad hoc, but that requires auth support. >         b. Another way would be to introduce some kind of sharding (= splitting the first label into several, possibly based on a few hash digits). >         c. ...? > > I am not sure this is really a problem at all, but an approach like 2.b) would be a protocol change, so it will be hard to do it later. That's why I'm interested in your opinions. (If nobody thinks this is a problem, we can close it right away.) > > Cheers, > Peter > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Kyffhäuserstr. 5 > 10781 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > > -- > DNSSEC-Bootstrapping mailing list > DNSSEC-Bootstrapping@ietf.org > https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping > > -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 From nobody Wed Oct 20 10:21:48 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30203A0A83 for ; Wed, 20 Oct 2021 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ADZnIfDU1kad for ; Wed, 20 Oct 2021 10:21:40 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 7ECD23A0A7B for ; Wed, 20 Oct 2021 10:21:40 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id g36so36937lfv.3 for ; Wed, 20 Oct 2021 10:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Auw6D0f022hPArboiuA83J6Rn7WH40k0AE2SV23rXfw=; b=cm1q0jB8U1WkYbCNIi5DS4UC5a5CovbJr27zOJFneRzLltCcOzUmuXXwAb1YtpjcGO XdWDpOgvlexhs5/8spIrWmGO2eJKkJFhDbIcY5Oj6uvnUjZgprnHkrLJ7mlT5Ba7iQzC QHvG1TREomSdTXIowZ3mhm+pkBGu95G+NXeIq4nF15N3bu7uTXUSi4FTicPiVekoJIi0 J3vPYYO4WWCFaZ33Gv0gXylFUu/qQEIvpfuZZtSte1ir++MpShX5OX2TO1/SVu+P8aZ1 1eplBVhuW4bw8RVxHya6j/XfkT++ypdeeflu0We/DgRWgsTBT/YYpueY92JOCHmpxGM0 yWTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Auw6D0f022hPArboiuA83J6Rn7WH40k0AE2SV23rXfw=; b=dsl88b8201tvPr1fX037yDk3Cy/WGIEezyBmJBppEoCQJng3LX+9lBkA42J3SlyjYD XnM8+xhnh7aC6OEpnblcG+5VXil4/w0w6lcdNRTC/W7HeyV8+0+E5V3g86Rmzb5btAMP 2F3D/R6UkZxvKw6k6Ls/I0u7c47L9rlKuoXQauoQrwFrG+KL3KDNLSHY0KvNCPWiNtwY 3MNo1ekiBlGXWbTUiwcvFzoUP95A+ERs0sIrZk+w/w2YEzd58RXdMItI98VGMRHZKVfy vka703kIiS+AUloqb3fVKX+eT0pVrMALaLWzBJMICwFU65hsjCRC0XdPv7obscyIqt2x BE0w== X-Gm-Message-State: AOAM531oHnd5yLEOFVYaV24ysOx6I4nQC6vw3qk1466eAhL7npeDEaLQ LHo2HkXtnpJFRrvO57o7Kb4KGM9qzCe6gDoeTv9ms1dS X-Google-Smtp-Source: ABdhPJySne2Kqoh7/j5K+ZsQqduYUam+raCPDmHsf/rDuSbvyxvgvP4BSuNUkey0VzeKqPTbVHdD/s6qCN6mIqwYh0A= X-Received: by 2002:a05:6512:a92:: with SMTP id m18mr499314lfu.427.1634750498202; Wed, 20 Oct 2021 10:21:38 -0700 (PDT) MIME-Version: 1.0 References: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> In-Reply-To: From: Brian Dickson Date: Wed, 20 Oct 2021 10:21:26 -0700 Message-ID: To: Steve Crocker Cc: Peter Thomassen , dnssec-bootstrapping@ietf.org Content-Type: multipart/alternative; boundary="000000000000bde6a705cecc027b" Archived-At: Subject: Re: [DNSSEC-Bootstrapping] Sharding? X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2021 17:21:46 -0000 --000000000000bde6a705cecc027b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 19, 2021 at 9:30 AM Steve Crocker wrote: > Peter, > > The sentence > > For a given second label such as hash(co.uk), the first label will > indicate all the (bootstrappable) domains that the DNS operator manages > under that ancestor. > > > raises a question of nor only whether the number is too large but also ho= w > frequently it changes. How accurate does this have to be? If it's > supposed to be completely accurate, this will likely be out of date very > quickly for a large domain. > > I think that is a non-issue, or orthogonal to the purpose of the zone(s). Each zone would be basically internally integrated by the DNS operator, as a service for their customers. Each zone would basically operate like a queue for a backlog of zones known to be possible to go secure. There are multiple steps in going secure, via bootstrap: - Generate keys and sign the zone - Publish records in bootstrap zone - Parental agent pulls record from bootstrap and adds secure delegation - Clean-up of processed records for now-secure domains So there are two places where some latency or queueing are likely to happen: signing to publishing; and publishing to consumption. Each DNS operator will have its own operational practices and infrastructure. Each operator would need to do its own thing, including setting expectations for customers, and ensuring things continue to work. The aggregate behavior is fine even if some DNS operators drop the ball occasionally. The market forces exert influence, i.e. customers can switch operators if they are not happy with the performance. Brian > > On Tue, Oct 19, 2021 at 9:05 AM Peter Thomassen wrote: > >> Hi all, >> >> In my other email, I mentioned an open question about the protocol >> format. Here you go. >> >> So far, the owner name of the signaling record for example.co.uk hosted >> on ns1.provider.net is: example.hash(co.uk)._boot.ns1.provider.net >> >> For a given second label such as hash(co.uk), the first label will >> indicate all the (bootstrappable) domains that the DNS operator manages >> under that ancestor. >> >> In case of the .com zone, I can imagine this to be a number that is >> potentially very high. (The concern does not apply to the second label, = as >> many domains will have the same ancestor.) >> >> 1.) Do you think that this will be a problem for anyone, such as at the >> scale of Cloudflare? >> 2.) If yes: What could be done about it? >> a. One migiation could be to synthesize signaling records ad hoc= , >> but that requires auth support. >> b. Another way would be to introduce some kind of sharding (=3D >> splitting the first label into several, possibly based on a few hash >> digits). >> c. ...? >> >> I am not sure this is really a problem at all, but an approach like 2.b) >> would be a protocol change, so it will be hard to do it later. That's wh= y >> I'm interested in your opinions. (If nobody thinks this is a problem, we >> can close it right away.) >> >> Cheers, >> Peter >> >> -- >> Like our community service? =F0=9F=92=9B >> Please consider donating at >> >> https://desec.io/ >> >> deSEC e.V. >> Kyffh=C3=A4userstr. 5 >> 10781 Berlin >> Germany >> >> Vorstandsvorsitz: Nils Wisiol >> Registergericht: AG Berlin (Charlottenburg) VR 37525 >> >> -- >> DNSSEC-Bootstrapping mailing list >> DNSSEC-Bootstrapping@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping >> > -- > DNSSEC-Bootstrapping mailing list > DNSSEC-Bootstrapping@ietf.org > https://www.ietf.org/mailman/listinfo/dnssec-bootstrapping > --000000000000bde6a705cecc027b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 19, 2021 at 9:30 AM Steve= Crocker <steve@shinkuro.com&g= t; wrote:
Peter,

The sentence
=

<= span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">F= or a given second label such as hash(co.uk), the first label will indicate all the (bootstrappable) = domains that the DNS operator manages under that ancestor.

raises a question=C2=A0of nor only whether the number is too= large but also how frequently it changes.=C2=A0 How accurate does this hav= e to be?=C2=A0 If it's supposed to be completely accurate, this will li= kely be out of date very quickly for a large domain.


I think=C2=A0that is a non-issue, or or= thogonal to the purpose of the zone(s).
Each zone would be basica= lly internally integrated by the DNS operator, as a service for their custo= mers.
Each zone would basically operate like a queue for a backlog of zo= nes known to be possible to go secure.
There are multiple steps i= n going secure, via bootstrap:
  • Generate keys and sign the= zone
  • Publish records in bootstrap zone
  • Parental agent pull= s record from bootstrap and adds secure delegation
  • Clean-up of proc= essed records for now-secure domains
So there are two places = where some latency or queueing are likely to happen: signing to publishing;= and publishing to consumption.

Each DNS ope= rator will have its own operational practices and infrastructure. Each oper= ator would need to do its own thing, including setting expectations for cus= tomers, and ensuring things continue to work.

The = aggregate behavior is fine even if some DNS operators drop the ball occasio= nally. The market forces exert influence, i.e. customers can switch operato= rs if they are not happy with the performance.

Bri= an
=C2=A0
=

On Tue, Oct 19, 2021 at = 9:05 AM Peter Thomassen <peter@desec.io> wrote:
Hi all,

In my other email, I mentioned an open question about the protocol format. = Here you go.

So far, the owner name of the signaling record for example.co.uk hosted on <= a href=3D"http://ns1.provider.net" rel=3D"noreferrer" target=3D"_blank">ns1= .provider.net is: example.hash(co.uk)._boot.ns1.provider.net

For a given second label such as hash(co.uk), the first label will indicate all the = (bootstrappable) domains that the DNS operator manages under that ancestor.=

In case of the .com zone, I can imagine this to be a number that is potenti= ally very high. (The concern does not apply to the second label, as many do= mains will have the same ancestor.)

1.) Do you think that this will be a problem for anyone, such as at the sca= le of Cloudflare?
2.) If yes: What could be done about it?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a. One migiation could be to synthesize signali= ng records ad hoc, but that requires auth support.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 b. Another way would be to introduce some kind = of sharding (=3D splitting the first label into several, possibly based on = a few hash digits).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. ...?

I am not sure this is really a problem at all, but an approach like 2.b) wo= uld be a protocol change, so it will be hard to do it later. That's why= I'm interested in your opinions. (If nobody thinks this is a problem, = we can close it right away.)

Cheers,
Peter

--
Like our community service? =F0=9F=92=9B
Please consider donating at

https://= desec.io/

deSEC e.V.
Kyffh=C3=A4userstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

--
DNSSEC-Bootstrapping mailing list
DNSSEC-B= ootstrapping@ietf.org
https://www.ietf.org/mailman/listinfo/dns= sec-bootstrapping
--
DNSSEC-Bootstrapping mailing list
DNSSEC-B= ootstrapping@ietf.org
https://www.ietf.org/mailman/listinfo/dns= sec-bootstrapping
--000000000000bde6a705cecc027b-- From nobody Thu Oct 21 01:28:02 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938133A11C5 for ; Thu, 21 Oct 2021 01:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (2048-bit key) header.d=a4a.de 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 FcVjoso0RerJ for ; Thu, 21 Oct 2021 01:26:07 -0700 (PDT) Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 5C51A3A11C2 for ; Thu, 21 Oct 2021 01:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References: In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=IL234jPqYuRY3VuML3NPvmHvVmFY1ggZC5or6vcn6nw=; b=A6mWkOEcfB/mwiNZ9KVhLztFyh gYqh/bPyL3IH2cVf95EfNVJXbRqc+iCekmZK1S2jySip6purO6NMNT/d6XotywFYnFs6znXvvicXH 9H4/XnuEVElScvTlugq+TE8E66Rq8kk3xMAyqrmzHgt6M0nyeY76V678GbqljsYoS/Qvc6bwcHkc1 jSUjKXGClID9xzpUgP7Y7Bx1cvLT8O0yiOUppbjJ1u2XJhzFNYM6J508CcIUtaVtHSd97lgOEc5CI HCxJgpNrwD6TakbTpTsUzW9+s+1X7MZlwusKUNC1GhQ8X6AK54+jC9f3SWdFKS2Gd8+yk3ieTqIx2 VSKkh3oA==; Received: from [2a02:8109:b03f:e20c:fb58:adf6:b24:1fbf] (helo=tp) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mdTOl-0005Up-TP for dnssec-bootstrapping@ietf.org; Thu, 21 Oct 2021 10:26:04 +0200 Message-ID: <46ec10edfafb3a110a9ac5cfaa63a0aa2d17cf83.camel@desec.io> From: Nils Wisiol To: dnssec-bootstrapping@ietf.org Date: Thu, 21 Oct 2021 10:26:03 +0200 In-Reply-To: References: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSSEC-Bootstrapping] Sharding? X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 08:26:20 -0000 On Wed, 2021-10-20 at 18:21 +0200, Peter Thomassen wrote: > However, if the parental agent (registry/registrar) does not support > the mechanism, bootstrapping records may remain in place more or less > indefinitely, until the parent changes their mind (or DS records are > provisioned manually). In that case, a large number of records could > accumulate under certain hash(ancestor) labels. > > > > Do DNS operators think this is a problem that needs to be addressed? In this light, I believe it could make sense to support a potentially large number of bootstrapping records. Otherwise, DNS operators are forced to keep track which zone is located at supporting parental agents and what the security status of each zone is. While this may be good practice, it could increase the adoption barrier. On the other hand, if large bootstrapping zones are supported, DNS operators can still choose to keep track of supporting parental agents and zone security status, but do not have to. This is at the cost of everyone implementing sharding (or some other mechanism) that allows for larger zones. Nils -- deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 From nobody Fri Oct 22 10:02:14 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFBA3A1161 for ; Fri, 22 Oct 2021 10:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, 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 (2048-bit key) header.d=a4a.de 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 sjIdk9XAi9Y1 for ; Fri, 22 Oct 2021 10:02:05 -0700 (PDT) Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 B95FF3A1141 for ; Fri, 22 Oct 2021 10:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Subject:From:References:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jWJu162Y0+SGLNNyqVauGF7PepYQhUX1yTl+/h1OTUo=; b=TqhmrA3EbGtS1MGGUm6yzQ5Sya 29C86AFJksgBCA4ApJjmkrS5MOL1zCTcUwVdceiZbng2OtKTtV4YuLZe35o6dexaWsCt/Y4n8Zk9/ 1l1r/Iprpn5qV/BqDgyli+G74vMIf6XlkXJ49kLB9R9wCj7d4hfF9+2Vlu4Og6eKO6EyMrR4r5Mw9 vXqRVaZin9ErJdU1C11Jj2POu0srRAIuUjKnp2sMkrDCjzxaY5mZH87CaZuLHS6pf2/q+Yx5SfjLN 85zaCta+kL4FWl4gnO2qGhuvxLEiyjX0hfOGi4rEUXw07/sNTOEQdJqDZ4fghMCZtRvVVNDjFcLUQ /dOaIiZQ==; Received: from [213.61.118.178] (helo=[192.168.188.94]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mdxva-00038o-LM for dnssec-bootstrapping@ietf.org; Fri, 22 Oct 2021 19:01:58 +0200 To: dnssec-bootstrapping@ietf.org References: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> <46ec10edfafb3a110a9ac5cfaa63a0aa2d17cf83.camel@desec.io> From: Peter Thomassen Message-ID: Date: Fri, 22 Oct 2021 19:01:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <46ec10edfafb3a110a9ac5cfaa63a0aa2d17cf83.camel@desec.io> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSSEC-Bootstrapping] Sharding? X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2021 17:02:12 -0000 On 10/21/21 10:26 AM, Nils Wisiol wrote: > On Wed, 2021-10-20 at 18:21 +0200, Peter Thomassen wrote: >> However, if the parental agent (registry/registrar) does not support >> the mechanism, bootstrapping records may remain in place more or less >> indefinitely, until the parent changes their mind (or DS records are >> provisioned manually). In that case, a large number of records could >> accumulate under certain hash(ancestor) labels. >> >> >> >> Do DNS operators think this is a problem that needs to be addressed? > > In this light, I believe it could make sense to support a potentially > large number of bootstrapping records. Otherwise, DNS operators are > forced to keep track which zone is located at supporting parental > agents and what the security status of each zone is. DNS operators should still clean up bootstrapping records for zones that have been secured, to keep bulk processing via NSEC walks or XFRs of the bootstrap zone efficient. Given that no operator voiced concerns over the bootstrapping zone size, while it was argued that the protocol scales well even without sharding, I observe that there is currently no support/demand for a sharding mechanism. I am going to rework some of the draft until Monday (IETF 112 draft submission deadline), mainly to make it relate better to RFC 8078. I am not currently planning to consider sharding in this iteration; if someone feels that is a mistake, please let me know. Thanks, Peter PS: In case demand for sharding should come up later within the WG, we can revisit this (and then also discuss questions like how to do it, whether it should be configurable etc.). -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 From nobody Mon Oct 25 09:07:20 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BA13A0900 for ; Mon, 25 Oct 2021 09:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-3.33, 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 (2048-bit key) header.d=a4a.de 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 szg9n6ITCjln for ; Mon, 25 Oct 2021 09:07:13 -0700 (PDT) Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 F14E33A08FE for ; Mon, 25 Oct 2021 09:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=K/lUb7OO60nAem0mbtmKnKOQIRlyxStASy/65BZen2M=; b=BzuXhVjG7xpZqTLzjqrtIUNVd+ WZGlMpsBDMBZPZyQUR7bWulBT3sM3cZbgoRndY4FYeubg0Si1/6/XQnra31TxAztA/aYBhL6T0n75 /420C+7b3eG8lTWqdCKJyfrk1yhKLwx2rIbwiB9l9DaMoZiWgxgaNrENyqP43YoZGmLiwXVFNYxNc h9ge2VLHbpgoClICZ0EnbK5nFIR9k4a0reawicigje6PEOhaEFuWqcbNNzwL5WeLFoAu9ajuDYpBY zYbjFdVpADehyavgl8k2M6knzRsYkohTwEqlwOIUPdsApUfml+NgUd8OmUyKDQHeQSmP1F+r80ZDf SB8CTS7w==; Received: from [130.149.39.73] by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mf2VC-0002ic-3h for dnssec-bootstrapping@ietf.org; Mon, 25 Oct 2021 18:07:10 +0200 To: dnssec-bootstrapping@ietf.org References: <59003805-21ea-bae9-61be-a4884baf828e@desec.io> <46ec10edfafb3a110a9ac5cfaa63a0aa2d17cf83.camel@desec.io> From: Peter Thomassen Message-ID: Date: Mon, 25 Oct 2021 18:07:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSSEC-Bootstrapping] Sharding? X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2021 16:07:18 -0000 Hi all, On 10/22/21 7:01 PM, Peter Thomassen wrote: > I am going to rework some of the draft until Monday (IETF 112 draft submission deadline), mainly to make it relate better to RFC 8078. I am not currently planning to consider sharding in this iteration; if someone feels that is a mistake, please let me know. FYI, here is the draft I am planning to submit tonight: Text: https://desec-io.github.io/draft-thomassen-dnsop-dnssec-bootstrapping/draft-thomassen-dnsop-dnssec-bootstrapping-02.txt HTML: https://desec-io.github.io/draft-thomassen-dnsop-dnssec-bootstrapping/draft-thomassen-dnsop-dnssec-bootstrapping-02.html Feel free to comment / PR until 11pm UTC if anything needs correction. Thanks, Peter -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525 From nobody Tue Oct 26 04:14:51 2021 Return-Path: X-Original-To: dnssec-bootstrapping@ietfa.amsl.com Delivered-To: dnssec-bootstrapping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5563A0F4A; Tue, 26 Oct 2021 04:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (2048-bit key) header.d=a4a.de 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 lZDNchMmjeYJ; Tue, 26 Oct 2021 04:14:29 -0700 (PDT) Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (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 196643A0F3A; Tue, 26 Oct 2021 04:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=a4a.de; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Subject:From:To:References:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=P0dl1mOZINMlj2I1gf5kgaplMG3HMmX9ffS6AntMCWU=; b=Z+EP05zkCVFX0mWZCmJEneQI++ GME9Nl/N5szDKaBxPy8XR8S28dS+Gh0VzQU/kdcPpxY1cLeitqrh8dkXRKuCdghEsHldSxj7ErEhi qWc1DiEYLJ6JxE0wZPpiEIurrkemHDkNGWJiQJGtxFgkeiWbZ8KOkyXnHgScorjZWwM5QF5BG6jsP qdZRgOpvnWwhP+7wjHuJS2xPWsvOaKxiTEv10+iYZyKAfo/WRFdcsbNeul9561v9UtXWoVpharR3V j0NLj6P+QrQVsnuvMFPKnaj4nGSuqnBqc8IWIaKuxZv94gmOVV01OIzm0Z3qAcDPacdVuw+U4c/Vx rswWAIAg==; Received: from [213.61.118.178] (helo=[192.168.188.94]) by mail.a4a.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfKPS-0001nI-Ii; Tue, 26 Oct 2021 13:14:26 +0200 References: <163520620129.17275.16274772439094875607@ietfa.amsl.com> To: "dnsop@ietf.org WG" , dnssec-bootstrapping@ietf.org From: Peter Thomassen X-Forwarded-Message-Id: <163520620129.17275.16274772439094875607@ietfa.amsl.com> Message-ID: <91154628-0ca3-15d8-c6bd-b71232b2e64b@desec.io> Date: Tue, 26 Oct 2021 13:14:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <163520620129.17275.16274772439094875607@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: [DNSSEC-Bootstrapping] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt X-BeenThere: dnssec-bootstrapping@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Authenticated Bootstrapping of DNSSEC Delegations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2021 11:14:34 -0000 Dear DNSOP and DNSSEC bootstrapping aficionados, This draft introduces automatic bootstrapping of DNSSEC delegations. It uses an in-band method for DNS operators to publish information about the zones they host, per-zone and with authentication. With this protocol, DS provisioning can happen securely and without delay. We requested a slot at IETF 112 to present the draft, and it would be great to have some discussions about it then. We'd also like to work towards adoption in the WG if there is interest. There are no technical changes from the previous version -01. Updates are exclusively on clarity, framing (as an RFC 8078 authentication method instead of a separate protocol), and otherwise editorial. Thanks, Peter -------- Forwarded Message -------- Subject: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt Date: Mon, 25 Oct 2021 16:56:41 -0700 From: internet-drafts@ietf.org To: Nils Wisiol , Peter Thomassen A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-02.txt has been successfully submitted by Peter Thomassen and posted to the IETF repository. Name: draft-thomassen-dnsop-dnssec-bootstrapping Revision: 02 Title: Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator Document date: 2021-10-25 Group: Individual Submission Pages: 15 URL: https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-02.txt Status: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/ Html: https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-02.html Htmlized: https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping Diff: https://www.ietf.org/rfcdiff?url2=draft-thomassen-dnsop-dnssec-bootstrapping-02 Abstract: This document introduces an in-band method for DNS operators to publish arbitrary information about the zones they are authoritative for, in an authenticated fashion and on a per-zone basis. The mechanism allows managed DNS operators to securely announce DNSSEC key parameters for zones under their management, including for zones that are not currently securely delegated. Whenever DS records are absent for a zone's delegation, this signal enables the parent's registry or registrar to cryptographically validate the CDS/CDNSKEY records found at the child's apex. The parent can then provision DS records for the delegation without resorting to out-of-band validation or weaker types of cross-checks such as "Accept after Delay" ([RFC8078]). [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on at https://github.com/desec-io/draft-thomassen- dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft- thomassen-dnsop-dnssec-bootstrapping/). The most recent version of the document, open issues, etc. should all be available there. The authors gratefully accept pull requests. ] The IETF Secretariat