From prvs=8808b73314=bemasc@meta.com  Mon Mar 18 18:44:41 2024
Return-Path: <prvs=8808b73314=bemasc@meta.com>
X-Original-To: dd@ietfa.amsl.com
Delivered-To: dd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 0C322C15108B
 for <dd@ietfa.amsl.com>; Mon, 18 Mar 2024 18:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level: 
X-Spam-Status: No, score=-7.104 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, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01,
 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=meta.com
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 FS7544Nb2E3e for <dd@ietfa.amsl.com>;
 Mon, 18 Mar 2024 18:44:37 -0700 (PDT)
Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com
 [67.231.153.30])
 (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 152C1C14F74E
 for <dd@ietf.org>; Mon, 18 Mar 2024 18:44:36 -0700 (PDT)
Received: from pps.filterd (m0089730.ppops.net [127.0.0.1])
 by m0089730.ppops.net (8.17.1.19/8.17.1.19) with ESMTP id 42INIh5Q014869
 for <dd@ietf.org>; Mon, 18 Mar 2024 18:44:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meta.com;
 h=from : to : subject :
 date : message-id : content-type : mime-version; s=s2048-2021-q4;
 bh=DE1cbNtibWnmUCHz9YNY/BT7UZWmMEpmC0bmGKtOE+U=;
 b=itctQ3c8nXgCFpcKxyww+IL1ia5VP/dkTylIjP1EoNaB6iOk8iKWkMTabMB4TOIHe4Ru
 d3QcXEkw3wmKNZt6Znkge0z+ziYv8+PXxMfy6NlvD82sXv43cKOKdwGzM6k11c6WwoBM
 cCd+0jDuFkYKukUPScwu/jyeCOlTvoval1x1c7wyYM0V0Rq7AXkcmasLaGgqVQvHUVCX
 yONzQrXUgDR7Kb963glgRrOWMArTGRaeVTfNHTnBfmUlF26BEn/x+IkbMGg+wvu9nRXJ
 D4ZCKoTlhuLYGzvlKnDg1Ov58nKJ7pWMSbA+Rd8fWoRPhcR33K6AB9l4qw9BJTHhEdOQ yQ== 
Received: from nam12-dm6-obe.outbound.protection.outlook.com
 (mail-dm6nam12lp2169.outbound.protection.outlook.com [104.47.59.169])
 by m0089730.ppops.net (PPS) with ESMTPS id 3wxy5nrjhu-1
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
 for <dd@ietf.org>; Mon, 18 Mar 2024 18:44:35 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=Nyw6yCkjldvgTWeRmDtY6enBaNOHh0ii+8iotTZIWrPr3hDbgLPNEvVtIz8LZm++132mdYVCwrVYC91UDEPcvC6qwYe7G81BXhnjBEIqrtlHQXR757pL5mAqev8v4P+wAExgXIQYBb8LAhUjTIuo12cpr75rLcf41lmldpw0H89I8YjBQgH1GIhLP8mZtpSXQ9hdct3ardcctp4YIoWbHOgpDA7YNG3r/zFimF0YczjO/bgTxqFtFtft7HPF+uIHEdRaTp9gMq+JGgfyhKSHNbzPC7D8vIYu6CX96rj6FKg4fm4G6V6vXXnPceHpSBQDckd+G5zRlLM9pj6nGqemRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; 
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
 bh=DE1cbNtibWnmUCHz9YNY/BT7UZWmMEpmC0bmGKtOE+U=;
 b=cJ08iXWlf+S4RUKBdz/uEOsyEUOLoJIaNpANbsigEsLbkLkYMgzdubONVG7Ok5LGcRbxurGBQc2KNndH+MlNKbc5eXz7vz1e5YCXlmXsh/1nj8M9P2pvLxKHxUrpE9Q442onrGKsqjcX3AZBc9b3z0DWMZT+8qYufPm5k+21pwEkJmvPQ07ZEy/sLrkJWGdT1PnoM/1vn2sa46erXyOgsugRdynNz1eKcZLIvqnh+npCXuluhM0csfqq4fDVWmpGZ86A7zHCvMMWWi7TKbEr5pDJKnrSNteGoshOB6vdpgcwQ8RsfW6Rge+ZOj4XJYELXZbET04KimarHei0uOb9FA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=meta.com; dmarc=pass action=none header.from=meta.com;
 dkim=pass header.d=meta.com; arc=none
Received: from SA1PR15MB4370.namprd15.prod.outlook.com (2603:10b6:806:191::8)
 by CY8PR15MB5507.namprd15.prod.outlook.com (2603:10b6:930:92::11)
 with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7386.26; Tue, 19 Mar
 2024 01:44:34 +0000
Received: from SA1PR15MB4370.namprd15.prod.outlook.com
 ([fe80::50:3dc9:3ace:9a3a]) by SA1PR15MB4370.namprd15.prod.outlook.com
 ([fe80::50:3dc9:3ace:9a3a%5]) with mapi id 15.20.7386.025; Tue, 19 Mar 2024
 01:44:34 +0000
From: Ben Schwartz <bemasc@meta.com>
To: "dd@ietf.org" <dd@ietf.org>
Thread-Topic: Proposed change to charter text paragraph 1
Thread-Index: AQHaeZaQQzh+gvlT60eSnWd/9KYlVw==
Date: Tue, 19 Mar 2024 01:44:34 +0000
Message-ID: <SA1PR15MB437053AEDAB6F9C570769988B32C2@SA1PR15MB4370.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
msip_labels: 
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA1PR15MB4370:EE_|CY8PR15MB5507:EE_
x-fb-source: Internal
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hvbRQCKcL50TYcNJdtyjJUXQgj51CnPtyebQk4xH4EgMJ5PlIvDF9r+5Fr3PMDCZU0nvMGTqUsBTHxoJ8czcji8OtnHd5VRAEz0dy3b8Dq36wPGV2te3anA0pPDHpY8+AYKREeVeHvf/zat22Xlu2wtR33c3Yn0zDi4GldipQUU4FjfJZPSDUgT/2EvIrNjqBvLP0sOf/ISAx9FIIy83IdjvK0kB8EtUDFTOw18uetVCnbOhvnMjc/jbmbl3J9eNlRHGgGWoN7pN8eBHyFECtvEU0c5OYEz2++pAvkkf/iZ6DrTIDOmzqCvgJKBW0RfdtXVd586Do8+kfQm74+otoYjs3wVAkJrq+qORl8vXzxSmxU34oDYbC86MT/l0NvWkvWIZ7Q6bMLw2r5HHDk9hk7fRy/CHu+kpcqijxWTN7+Yt2bHz0fNA7CWonxzAhPuq5yBx5jBYhZ1Z24yHqXU5EPlWH0ymSNEQZaX6drQIFU5ypynAxEvf8+CAf+Lpez3e2bvpHwQmCC++0dCqM3ajjdoZqPEu1VzpEbkor7ZzwgXmS1f+T2q2T/tRO+lBY7DmuyigxXkTRJT9Oe/kYm2J7gTwdID1pNEfutzR4L9ioRJF87OD/OuLFESYediLaoI1u/p2GEIyleEXkrgLc+LhDw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
 IPV:NLI; SFV:NSPM; H:SA1PR15MB4370.namprd15.prod.outlook.com; PTR:; CAT:NONE;
 SFS:(13230031)(366007)(1800799015)(376005); DIR:OUT; SFP:1102; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?78SbrP74LDbL28QoTlglc+vbxKAphJkVGNdEIkox8vVzG9MlPaxDikkJ?=
 =?Windows-1252?Q?8DVKCTFQJY3Kd9WUlBjmNYRmvO4EAvNljo6pkqMj+UZjDpFd0v1CEDF2?=
 =?Windows-1252?Q?l/c8NKoWMYA9p36dYNNjHjxVZxp2BP3Lrh6Eckm+r4Px4yNMwMSQ5GIF?=
 =?Windows-1252?Q?CVCc31h6zlqrO4lnnO7tkQrZl6bjEj7kPUOye6NjtBdEHL8hdrVyGNHT?=
 =?Windows-1252?Q?Y7HEvSl+8aIlKdwFhSCPeV2kdhsE0qd4s6eo3cuPOqzunH3Iy/qKOMGA?=
 =?Windows-1252?Q?7/CpAWbclYdE+37no7I1rlpq4C0LnAot7lLdNG2Rd3+VXYcmMH03DUVt?=
 =?Windows-1252?Q?1zy4VvefUET+FPXool8LL3UPRYq/l1NhUcklykeTSMG/Np3dKFRtZ0d/?=
 =?Windows-1252?Q?08Uv1Z8UJ2UiGiEuFd7VzpQQ1fBYg9SDxulclMKnpONrVXqKNV3+FnJN?=
 =?Windows-1252?Q?D4qK+r9S+rkpIkN2T81LL3aGyX6NVZJam1jq1ZXA7QeUq7V1oL0mFZnY?=
 =?Windows-1252?Q?2iXyjXdnKT0yGVZjIFrGCMcq4Wwpb+hJnHhShYs0hMVvNUdcgQpdbqRq?=
 =?Windows-1252?Q?oqsrrylxhpZIhgv1WZl0HRy2OlK9ImXIqunGe7YpLzyzFs2ZWWQ8lNTn?=
 =?Windows-1252?Q?KkmzWElE3GFeTkVcQijcPmU06mrOKdmpx8i8gyxRISkDpz05H/4vp0dd?=
 =?Windows-1252?Q?0HLbUz57lmmDXr2aLExM0z7fgooHmfTsgxdlQ0AXOAGt3paOwOJHAbb9?=
 =?Windows-1252?Q?LV8xRLRdmTdLp9XWiWpACws7Zl7QWUpiTAAGnECRjd7rPStQLdudzr35?=
 =?Windows-1252?Q?y5xjwUOvy5Hqq7LKSycIFVAHZgIpZv26pncF6aqgK1o3t9ZjtZm/124K?=
 =?Windows-1252?Q?nIQqjx15eIwDsZ/xqIHm4jsWi/l70+wQtHWaTvTbdipDXEqIWhAd9YtU?=
 =?Windows-1252?Q?fJIhDQky4xpAduZMn5SxdvOhpMlaaNjKGKMw9gHCLZsuX3YqFUNk4X7z?=
 =?Windows-1252?Q?OM0dO71K9QK08g1DOYR7jrYAy8ofWtS4BJF03arzSYABRG6MEtsOJQWW?=
 =?Windows-1252?Q?aZE+IT6QuYMe9bZ67QX8cH9P6FOOYY8d5eLkbZ7QMXjObiwHSbwR5UiT?=
 =?Windows-1252?Q?bbKh9yKg0JpQbzE2V003YZaQAVTonTzlZILZ7doYpYOK7QwcWvtXPUPE?=
 =?Windows-1252?Q?7SRfNpjzkQy568SiL3U7JL03LgwxF+NjEmbI8xYd0rScf4EyXUJ3jhcY?=
 =?Windows-1252?Q?LvA/cQxsYjwZgCG3ZKwn9L4sDloB0pjZlSGbNnHk2ZiHUrMLMJbVRV03?=
 =?Windows-1252?Q?9DkI7/ptT2JUKpVnbqclf3CF6SHYLYINOyjiYpeB6Eod9sMkloq8ZfsE?=
 =?Windows-1252?Q?nqfB7DJXumBuNYjS8roB9Kg5HoxpZC2GSRnQcduCil+4Ym1RHyBpKLgj?=
 =?Windows-1252?Q?6/cGLuFcRlVXst+awljvBJPlHOsK9LRVIV6V9rHThunMx6XpzqdSsftk?=
 =?Windows-1252?Q?K8K7eqSSxg9eefq+pGIybCes8EAQlcRGn7/lcSE+bN61gmrIFTOR3GSv?=
 =?Windows-1252?Q?26cmQFWdqM9m0E6Yk5Qc6w58JcsE6BslIoFfWYT3sTX7xzvQ18lCGJnu?=
 =?Windows-1252?Q?zYcWQoR7+cPEIykfcKYmw8nSnj3sq3Eagv3+/2mvkxJRsMdav0Br9BUV?=
 =?Windows-1252?Q?1RELUDIH43Mm3LOZRWKrM8pvdnIoa2HAyBGbnUeJ/mMv7CWd90Tm6iK5?=
 =?Windows-1252?Q?LIK762GGnDaQ1JWXgUo=3D?=
Content-Type: multipart/alternative;
 boundary="_000_SA1PR15MB437053AEDAB6F9C570769988B32C2SA1PR15MB4370namp_"
MIME-Version: 1.0
X-OriginatorOrg: meta.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR15MB4370.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a260b97-f9e9-48a6-2814-08dc47b620e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2024 01:44:34.1189 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: cSADW7OvD1gf1hSQIj5PftLwI4YUh3uwVs0n0Elm9mg/Ogn7P71cNa3gpUsCFCJ8
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR15MB5507
X-Proofpoint-GUID: OdoBx3JPn3mtMFZNQfkbCV_GWVTvdZuD
X-Proofpoint-ORIG-GUID: OdoBx3JPn3mtMFZNQfkbCV_GWVTvdZuD
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-03-18_12,2024-03-18_03,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/WCMNYOwlZOLiFOrnhRf_1EMsc7c>
Subject: [dd] Proposed change to charter text paragraph 1
X-BeenThere: dd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS Delegation <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>,
 <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>,
 <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2024 01:44:41 -0000

--_000_SA1PR15MB437053AEDAB6F9C570769988B32C2SA1PR15MB4370namp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Current:

The DNS protocol has traditionally had limited ability to signal to recursi=
ve resolvers about the
capabilities of authoritative servers they communicate with. In part, this =
stems from the inability of
parents (often registries) to specify additional information about child de=
legations (often registrants)
beyond NS, DS, and glue records. Further complicating matters is the inabil=
ity of a registrant to signal
that the operation of a delegation point is being outsourced to a different=
 operator, leaving a
challenge when operators need to update parental information that is only i=
n the control of the child.
A significant issue in today=92s deployed DNS that derives from these issue=
s is data often being out of
synchronization between parents and children. Said another way, children of=
ten have more up-todate information about the nameservers and DNSSEC keying=
 information than their parents due to
slowness, or complete lack, of automated child-to-parent updates.

Proposed:

In the DNS protocol, recursive resolvers have limited information about eac=
h nameserver before their first exchange.  At this step, resolvers only kno=
w the NS, DS, and glue records provided by the parent zone.  These records =
have been sufficient because authoritative DNS servers have traditionally b=
een highly uniform, supporting the same protocols, and stable, changing DNS=
SEC KSKs and nameserver IP addresses only occasionally.

This uniformity and stability is beginning to change, with growing deployme=
nt of new protocols and novel DNSSEC configurations.  Nameservers are now o=
ften controlled by one or more third-party operators, not the child zone, c=
omplicating the process of updating records in the parent.  As a result, re=
levant information about nameservers is often out of date or inexpressible =
in the parent zone.

--_000_SA1PR15MB437053AEDAB6F9C570769988B32C2SA1PR15MB4370namp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Current:</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
The DNS protocol has traditionally had limited ability to signal to recursi=
ve resolvers about the</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
capabilities of authoritative servers they communicate with. In part, this =
stems from the inability of</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
parents (often registries) to specify additional information about child de=
legations (often registrants)</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
beyond NS, DS, and glue records. Further complicating matters is the inabil=
ity of a registrant to signal</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
that the operation of a delegation point is being outsourced to a different=
 operator, leaving a</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
challenge when operators need to update parental information that is only i=
n the control of the child.</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
A significant issue in today=92s deployed DNS that derives from these issue=
s is data often being out of</div>
<div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, =
Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
synchronization between parents and children. Said another way, children of=
ten have more up-todate information about the nameservers and DNSSEC keying=
 information than their parents due to</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
slowness, or complete lack, of automated child-to-parent updates.</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
Proposed:</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
In the DNS protocol, recursive resolvers have&nbsp;limited information abou=
t each nameserver before their first exchange.&nbsp; At this step, resolver=
s only know the NS, DS, and glue records provided by the parent zone.&nbsp;=
 These records have been sufficient because authoritative
 DNS servers have traditionally been highly uniform, supporting the same pr=
otocols, and stable, changing DNSSEC KSKs and nameserver IP addresses only =
occasionally.<br>
<br>
</div>
<div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo=
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c=
olor: rgb(0, 0, 0);">
This uniformity and stability is beginning to change, with growing deployme=
nt of new protocols and novel DNSSEC configurations.&nbsp; Nameservers are =
now often controlled by one or more third-party operators, not the child zo=
ne, complicating the process of updating
 records in the parent.&nbsp; As a result, relevant information about names=
ervers is often out of date or inexpressible in the parent zone.</div>
</body>
</html>

--_000_SA1PR15MB437053AEDAB6F9C570769988B32C2SA1PR15MB4370namp_--

