[DNSOP] CDS Bootstrapping for vanity DNS servers

rubensk@nic.br Wed, 22 June 2022 02:51 UTC

Return-Path: <rubensk@nic.br>
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 0EAD7C14792E for <dnsop@ietfa.amsl.com>; Tue, 21 Jun 2022 19:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 lOjHEcdjzKCv for <dnsop@ietfa.amsl.com>; Tue, 21 Jun 2022 19:51:20 -0700 (PDT)
Received: from mx.nic.br (mx.nic.br [200.160.4.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 18F79C14CF1A for <dnsop@ietf.org>; Tue, 21 Jun 2022 19:51:18 -0700 (PDT)
Received: from smtpclient.apple (unknown [191.19.224.122]) (Authenticated sender: rubens) by mx.nic.br (Postfix) with ESMTPSA id E7352BD02D for <dnsop@ietf.org>; Tue, 21 Jun 2022 23:51:12 -0300 (-03)
From: rubensk@nic.br
Content-Type: multipart/signed; boundary="Apple-Mail=_70DC2FFC-FF98-4169-B454-E7480F4044FB"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Message-Id: <84B820D1-5BF7-4C3A-8C4D-6D4CD1D554ED@nic.br>
Date: Tue, 21 Jun 2022 23:51:10 -0300
To: dnsop@ietf.org
X-Mailer: Apple Mail (2.3696.100.31)
X-Rspamd-Server: mx.nic.br
X-Spamd-Result: default: False [-4.47 / 15.00]; BAYES_HAM(-2.77)[98.98%]; SIGNED_PGP(-2.00)[]; MV_CASE(0.50)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:27699, ipnet:191.19.224.0/20, country:BR]; NEURAL_HAM(-0.00)[-0.999]; FROM_NO_DN(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]
X-Rspamd-Queue-Id: E7352BD02D
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HRa9LIWZO8r3a4vurSQGerehI_E>
Subject: [DNSOP] CDS Bootstrapping for vanity DNS servers
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: Wed, 22 Jun 2022 02:51:24 -0000

Hi.

During a meeting today of ROW (https://regiops.net) the I-D on CDS bootstrapping by using a DNSSEC-signed name at name server zone (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/) was discussed.
In that discussion, it was mentioned that the current draft only supports out-of-bailiwick name servers; I replied that the same principle could be applied to in-bailiwick name server by usage of the reverse DNS zones for IPv4 and IPv6.


Reverse DNS zones have been signed for a while now, as you can see in this walk-thru of the DNSSEC trust chain for one IP address:
https://dnsviz.net/d/3.2.160.200.in-addr.arpa/dnssec/


So, instead of _dsboot.example.com.br._signal.ns1.example.net.br, it could be a CDS/CDNSKEY record at _dsboot.example.com.br._signal.1.2.0.192.in-addr.arpa or  _dsboot.example.com.br._signal.b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. Or put _dsboot.example.com.br as the PTR response for that query, but keeping it aligned with direct resolution seems preferable to me.

Whether this violates any currently in-force DNS RFCs/STDs requirement, or if would fail or not to work with the current codebase of authority and recursive servers, I don't know.



Rubens