[Sidrops] DNS-RR for RPKI Publication Point Operation Practice
Di Ma <madi@zdns.cn> Mon, 26 June 2023 12:31 UTC
Return-Path: <madi@zdns.cn>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1AC151070 for <sidrops@ietfa.amsl.com>; Mon, 26 Jun 2023 05:31:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 rwVfOtMi7kNt for <sidrops@ietfa.amsl.com>; Mon, 26 Jun 2023 05:31:48 -0700 (PDT)
Received: from smtpbg153.qq.com (smtpbg153.qq.com [13.245.218.24]) (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 1E17AC14CE38 for <sidrops@ietf.org>; Mon, 26 Jun 2023 05:31:45 -0700 (PDT)
X-QQ-mid: bizesmtp71t1687782697t4coednq
Received: from smtpclient.apple ( [113.105.127.26]) by bizesmtp.qq.com (ESMTP) with SMTP id 0 for <sidrops@ietf.org>; Mon, 26 Jun 2023 20:31:37 +0800 (CST)
X-QQ-SSF: 01400000000000Z0Z000000A0000000
X-QQ-FEAT: uWtt+4oZiA+jIVLi5+rpLvCql8fnXqoDsahRr78aUumEIhxlxUwvxzDuHT6Jn ORpMnCZC3Td+tb4B98qxMBaPI7Ih7u86jhuQ7OsOmxwguKiuH3TPjhdRixltlvex/dBc/r8 VzKUC9F4f2K3SHtiSEV+Y2qvKO1qqBqs0FhsJEHbGQapYa8NqBEy7zs8qxadpOtIVo6eIxz VHG/Y2eRIeS9KtNCH71NiGZblbB+JIo7b2wB877jysOd/iUy/lgwjarR8QWBwvlXN38tLES /fqjTfDADSeIkM82li+xGdS8VW1p9Jy31tFKvbMTOgGDIF9Q7etR3kbKOjUN3V9VM2PF+dR 9izYUfkbOHvPEOuAK5GTOWWv8Ifq2dvTfajCZTVKfZnldj1oqezQuPT7V+JDQ==
X-QQ-GoodBg: 2
X-BIZMAIL-ID: 72870669061864776
From: Di Ma <madi@zdns.cn>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Message-Id: <F1D163AB-2103-4A57-BFCA-A5717E582D8F@zdns.cn>
Date: Mon, 26 Jun 2023 20:31:26 +0800
To: SIDR Operations WG <sidrops@ietf.org>
X-Mailer: Apple Mail (2.3731.600.7)
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:zdns.cn:qybglogicsvrgz:qybglogicsvrgz6a-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tdSw9aJlEz18Zh0fOjy8YsrqhPs>
Subject: [Sidrops] DNS-RR for RPKI Publication Point Operation Practice
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jun 2023 12:31:51 -0000
Hi, folks, I am thinking about a way of improving the interaction between the RPKI Publication Point and the RPKI Relying Party. A couple of days ago, I just realized the DNS had been playing a significant role in RPKI operation efficiency when my RP system took remarkable time to get access to some RPKI Publication Points due to DNS query delay. Since DNS resolution of the IP address of publication point is inevitable before an RP starts interacting with the very publication point, I cannot help but think of the discussions we had in this mailing list about RP synchronization in bandwidth constrained environments. As far as I developed and maintained RP systems, I think it would be better for an RP to know about what the publication point operation practice relating to its interaction with RPs such as download speed limit, frequency restriction, compression protocol and so on. Why not consider unitizing DNS to meet this end? We might make an RP query a special sub-domain of publication point’s name to get those information of publication point operation practice (ppop) in the meanwhile when it enquires as to the A/AAAA record, the TXT DNS-RR of _ppop.[publication point name] for instance, without making any change to current rrdp. This could be optional for both repository managers and RPs. If this WG group think this is good idea then we can work together to go into the detail of key-value design of DNS TXT RR for this extension. Comments? :-) Di