-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft.xml.in
1142 lines (809 loc) · 35.2 KB
/
draft.xml.in
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3688 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY RFC5731 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml">
<!ENTITY RFC5732 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5732.xml">
<!ENTITY RFC5910 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5910.xml">
<!ENTITY RFC6895 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6895.xml">
<!ENTITY RFC6927 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6927.xml">
<!ENTITY RFC7451 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7451.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8590 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8590.xml">
<!ENTITY RFC9364 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml">
<!ENTITY RFC9499 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<rfc
category="std"
docName=""
ipr="trust200902"
submissionType="IETF"
consensus="true"
xmlns:xi="http://www.w3.org/2001/XInclude">
<front>
<title abbrev="TTL mapping for EPP">
Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values
</title>
<author fullname="Gavin Brown">
<organization>ICANN</organization>
<address>
<postal>
<street>12025 Waterfront Drive, Suite 300</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>
<email>[email protected]</email>
<uri>https://www.icann.org/</uri>
</address>
</author>
<date/>
<area>Applications</area>
<workgroup>Registration Protocols Extensions (regext)</workgroup>
<abstract>
<t>
This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-To-Live (TTL) value for domain name delegation records.
</t>
</abstract>
<note title="About this draft" removeInRFC="true"><t>
The source for this draft, and an issue tracker, may can be found at <eref target="https://github.com/gbxyz/epp-ttl-extension"/>.
</t></note>
</front>
<middle>
<section title="Introduction">
<t>
The principal output of any domain name registry system is a DNS zone file, which contains the delegation record(s) for names registered within a zone (such as a top-level domain).
These records typically include one or more <tt>NS</tt> records, but may also include <tt>DS</tt> records for domains secured with DNSSEC (<xref target="RFC9364"/>), and <tt>DNAME</tt> records for IDN variants (<xref target="RFC6927"/>).
<tt>A</tt> and/or <tt>AAAA</tt> records may also be published for nameservers where required by DNS resolvers to avoid an infinite loop.
</t>
<t>
Typically, the Time-To-Live value (TTL, see <xref section="5" sectionFormat="of" target="RFC9499"/>) of these records is determined by the registry operator.
However, in some circumstances it may be desirable to allow the sponsoring client of a domain name to change the TTL values used for that domain's delegation:
for example, to reduce the amount of time required to complete a change of DNS servers, DNSSEC deployment or key rollover, or to allow for fast rollback of such changes.
</t>
<t>
This document describes an EPP extension to the domain name and host object mappings (described in <xref target="RFC5731"/> and <xref target="RFC5732"/>, respectively) which allows the sponsor of a domain name or host object to change the TTL values of the resource record(s) associated with that object.
It also describes how EPP servers should handle TTLs specified by EPP clients and how both parties co-ordinate to manage TTL values in response to changes in operational or security requirements.
</t>
<section title="Conventions used in this document">
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
</t>
<t>
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server.
Indentation and white space in examples are provided only to illustrate element relationships and are not required features of this protocol.
</t>
<t>
A protocol client that is authorized to manage an existing object is described as a "sponsoring" client throughout this document.
</t>
<t>
XML is case sensitive.
Unless stated otherwise, XML specifications and examples provided in this document <bcp14>MUST</bcp14> be interpreted in the character case presented in order to develop a conforming implementation.
</t>
<t>
EPP uses XML namespaces to provide an extensible object management framework and to identify schemas required for XML instance parsing and validation.
These namespaces and schema definitions are used to identify both the base protocol schema and the schemas for managed objects.
</t>
<t>
The XML namespace prefixes used in examples (such as the string <tt>ttl</tt> in <tt>ttl:create</tt>) are solely for illustrative purposes.
A conforming implementation <bcp14>MUST NOT</bcp14> require the use of these or any other specific namespace prefixes.
</t>
<t>
In accordance with <xref target="XSD-DATATYPES">Section 3.2.2.1 of XML Schema Part 2: Datatypes</xref>,
the allowable lexical representations for the <tt>xs:boolean</tt> datatype are the strings "<tt>0</tt>" and "<tt>false</tt>" for the concept 'false' and the strings "<tt>1</tt>" and "<tt>true</tt>" for the concept 'true'.
Implementations <bcp14>MUST</bcp14> support both styles of lexical representation.
</t>
</section>
<section title="Extension elements" anchor="extension-elements">
<t>
This extension adds additional elements to the EPP domain and host mappings.
</t>
<section anchor="ttl_element" title="The <ttl:ttl> element">
<t>
The <tt><ttl:ttl></tt> element is used to define TTL values for the DNS resource records associated with domain and host objects.
</t>
<t>
<tt><ttl:ttl></tt> elements have the optional following attributes, depending on whether they appear in an EPP command or response:
</t>
<ol>
<li>
"<tt>for</tt>", which is <bcp14>REQUIRED</bcp14> in both commands and responses,
and which specifies the DNS record type to which the TTL value pertains.
This attribute <bcp14>MUST</bcp14> have one of the following values: "<tt>NS</tt>", "<tt>DS</tt>", "<tt>DNAME</tt>", "<tt>A</tt>", "<tt>AAAA</tt>" or "<tt>custom</tt>";
</li>
<li>
If the value of the "<tt>for</tt>" attribute is "<tt>custom</tt>",
then the <tt><ttl:ttl></tt> element <bcp14>MUST</bcp14> also have a "<tt>custom</tt>" attribute containing a DNS record type conforming with the regular expression in <xref sectionFormat="of" section="3.1" target="RFC6895"/>.
Additionally, the record type <bcp14>MUST</bcp14> be registered with IANA in <xref target="IANA-RRTYPES"/>.
</li>
<li>
"<tt>min</tt>", which <bcp14>MUST NOT</bcp14> be present in EPP commands but <bcp14>MAY</bcp14> be present in EPP responses (see <xref target="info-command"/>), and which is used by the server to indicate the lowest value that may be set;
</li>
<li>
"<tt>default</tt>", which <bcp14>MUST NOT</bcp14> be present in EPP commands but <bcp14>MAY</bcp14> be present in EPP responses (see <xref target="info-command"/>), and which is used by the server to indicate the default value;
</li>
<li>
"<tt>max</tt>", which <bcp14>MUST NOT</bcp14> be present in EPP commands but <bcp14>MAY</bcp14> be present in EPP responses (see <xref target="info-command"/>), and which is used by the server to indicate the highest value that may be set;
</li>
</ol>
<t>
When present, the value of the "<tt>min</tt>" attribute <bcp14>MUST</bcp14> be lower than the value of the "<tt>max</tt>" attribute. The "<tt>default</tt>" attribute <bcp14>MUST</bcp14> be between the "<tt>min</tt>" and "<tt>max</tt>" values, inclusively.
</t>
<section title="Element content" anchor="element-content">
<t>
The XML schema found in <xref target="formal-syntax"/> of this document restricts the content of <tt><ttl:ttl></tt> elements to be either:
</t>
<ol>
<li>
a non-negative integer, indicating the value of the TTL in seconds, or
</li>
<li>
empty, in which case the server's default TTL for the given record type is to be applied.
</li>
</ol>
</section>
<section title="Supported DNS record types" anchor="supported-dns-record-types">
<t>
To facilitate forward compatibility with future changes to the DNS protocol,
this document does not enumerate or restrict the DNS record types that can be included in the "<tt>custom</tt>" attribute of the <tt><ttl:ttl></tt> element.
</t>
<t>
The regular expression which is used to validate the values of the "<tt>custom</tt>" attribute is based on the expression found in <xref sectionFormat="of" section="3.1" target="RFC6895"/>,
and is intended to match both existing and future RRTYPE mnemonics.
This eliminates the need to update this document in the event that new DNS records that exist above a zone cut (<xref sectionFormat="of" section="7" target="RFC9499"/>) are specified.
</t>
<t>
Nevertheless, EPP servers which implement this extension <bcp14>MUST</bcp14> restrict the DNS record types that are accepted in <tt><create></tt> and <tt><update></tt> commands,
and included in <tt><info></tt> responses,
allowing only those types that are (a) registered in <xref target="IANA-RRTYPES"/> and (b) appropriate for use above a zone cut.
</t>
<t>
A server that receives a <tt><create></tt> or <tt><update></tt> command that attempts to set TTL values for inapplicable DNS record types <bcp14>MUST</bcp14> respond with a 2306 "Parameter value policy" error.
</t>
<t>
As an illustrative example, a server <bcp14>MAY</bcp14> allow clients to specify TTL values for the following record types for domain objects:
</t>
<ol>
<li>
<tt>NS</tt>;
</li>
<li>
<tt>DS</tt> (if the server also implements <xref target="RFC5910"/>);
</li>
<li>
<tt>DNAME</tt> (if the server implements IDN variants using <tt>DNAME</tt> records).
</li>
</ol>
<section title="Glue records">
<t>
Glue records are described in <xref section="7" sectionFormat="of" target="RFC9499"/>.
</t>
<t>
Servers which implement host objects (<xref target="RFC5732"/>) <bcp14>MAY</bcp14> allow clients to specify TTL values for <tt>A</tt> and <tt>AAAA</tt> records for host objects.
</t>
<t>
A server supporting host objects which receives a command that attempts to set TTL values for <tt>A</tt> and <tt>AAAA</tt> records on a domain object <bcp14>MUST</bcp14> respond with a 2306 "Parameter value policy" error.
</t>
<t>
EPP servers which use the "host attribute" model
(described in <xref sectionFormat="of" section="1.1" target="RFC5731"/>)
<bcp14>MAY</bcp14> allow clients to specify TTL values for <tt>A</tt> and <tt>AAAA</tt> records for domain objects.
</t>
</section>
</section>
<section anchor="info-element" title="The <ttl:info> element">
<t>
The <tt><ttl:info></tt> element is used by clients to request that the server include additional information in <tt><info></tt> responses for domain and host objects.
</t>
<t>
It has a single <bcp14>OPTIONAL</bcp14> <tt>policy</tt> attribute, which takes a boolean value with a default value of <tt>false</tt>.
</t>
<t>
The semantics of this element are described in <xref target="info-command"/>.
</t>
<section title="Example">
<sourcecode><ttl:info policy="true"/></sourcecode>
</section>
</section>
</section>
<section title="Examples">
<section title="Explicit TTL value (<create> or <update> command)">
<sourcecode><ttl:ttl for="NS">3600</ttl:ttl></sourcecode>
</section>
<section title="Explicit TTL value (<info> policy mode)">
<sourcecode><ttl:ttl
for="NS"
min="60"
default="86400"
max="172800">3600</ttl:ttl></sourcecode>
</section>
<section title="Empty value indicating default TTL (<create> or <update> command, <info> default mode)">
<sourcecode><ttl:ttl for="NS"/></sourcecode>
</section>
<section title="Custom record type (<create> or <update> command, <info> default mode)">
<sourcecode><ttl:ttl
for="custom"
custom="NEWRRTYPE">3600</ttl:ttl></sourcecode>
</section>
</section>
</section>
</section>
<section title="EPP command mapping">
<section title="EPP query commands">
<section anchor="info-command" title="EPP <info> command">
<t>
This extension defines an additional element for EPP <tt><info></tt> commands and responses for domain and host objects.
</t>
<t>
The EPP <tt><info></tt> command is extended to support two different modes:
</t>
<ol>
<li>
The Default Mode (<xref target="default-mode"/>),
which requests the inclusion of all non-default TTL values in the response; and
</li>
<li>
The Policy Mode (<xref target="policy-mode"/>),
which requests the inclusion of TTL information for all supported DNS record types in the response,
along with the minimum, default and maximum values for those records.
</li>
</ol>
<section title="Default Mode" anchor="default-mode">
<t>
If a server receives an <tt><info></tt> command for a domain or host object which includes a <tt><ttl:info></tt> element
with a "<tt>policy</tt>" attribute that is "<tt>0</tt>" or "<tt>false</tt>",
then the EPP response <bcp14>MUST</bcp14> contain <tt><ttl:ttl></tt> records for all DNS record types that have non-default TTL values.
These elements <bcp14>MUST NOT</bcp14> have the "<tt>min</tt>", "<tt>default</tt>" and "<tt>max</tt>" attributes.
</t>
<t>
Example domain <tt><info></tt> command with a <tt><ttl:info></tt> element with a <tt>policy</tt> attribute that is <tt>false</tt>:
</t>
<sourcecode><xi:include parse="text" href="examples/domain-info-command.xml.txt"/></sourcecode>
<t>
Example domain <tt><info></tt> response to a command with a <tt><ttl:info></tt> element with a <tt>policy</tt> attribute that is <tt>false</tt>:
</t>
<sourcecode><xi:include parse="text" href="examples/domain-info-response.xml.txt"/></sourcecode>
<t>
Example host <tt><info></tt> command with a <ttl:info> element with a <tt>policy</tt> attribute that is <tt>false</tt>:
</t>
<sourcecode><xi:include parse="text" href="examples/host-info-command.xml.txt"/></sourcecode>
<t>
Example host <tt><info></tt> response to a command with a <ttl:info> element with a <tt>policy</tt> attribute that is <tt>false</tt>:
</t>
<sourcecode><xi:include parse="text" href="examples/host-info-response.xml.txt"/></sourcecode>
</section>
<section title="Policy Mode" anchor="policy-mode">
<t>
If a server receives an <tt><info></tt> command for a domain or host object which includes a <tt><ttl:info></tt> element
with a "<tt>policy</tt>" attribute is "<tt>1</tt>" or "<tt>true</tt>",
then the EPP response <bcp14>MUST</bcp14> contain <tt><ttl:ttl></tt> records for all supported DNS record types,
irrespective of whether those record types are actually in use by the object in question.
These elements <bcp14>MUST</bcp14> have the "<tt>min</tt>", "<tt>default</tt>" and "<tt>max</tt>" attributes.
</t>
<t>
Example domain <tt><info></tt> command requesting the server policies:
</t>
<sourcecode><xi:include parse="text" href="examples/extended-domain-info-command.xml.txt"/></sourcecode>
<t>
Example domain <tt><info></tt> response providing the server policies:
</t>
<sourcecode><xi:include parse="text" href="examples/domain-info-extended-response.xml.txt"/></sourcecode>
<t>
Example host <tt><info></tt> command requesting the server policies:
</t>
<sourcecode><xi:include parse="text" href="examples/extended-host-info-command.xml.txt"/></sourcecode>
<t>
Example host <tt><info></tt> response providing the server policies:
</t>
<sourcecode><xi:include parse="text" href="examples/extended-host-info-response.xml.txt"/></sourcecode>
</section>
</section>
</section>
<section title="EPP transform commands">
<section title="EPP <create> command">
<t>
This extension defines an additional element for EPP <tt><create></tt> commands for domain and host objects.
</t>
<t>
The <tt><command></tt> element of the <tt><create></tt> command <bcp14>MAY</bcp14> contain an <tt><extension></tt> element which <bcp14>MAY</bcp14> contain a <tt><ttl:create></tt> element.
This element <bcp14>MUST</bcp14> contain one or more <tt><ttl:ttl></tt> records as described in <xref target="extension-elements"/>.
</t>
<t>
Example domain <tt><create></tt> command:
</t>
<sourcecode><xi:include parse="text" href="examples/domain-create-command.xml.txt"/></sourcecode>
<t>
Example host <tt><create></tt> command:
</t>
<sourcecode><xi:include parse="text" href="examples/host-create-command.xml.txt"/></sourcecode>
<t>
If an EPP server receives a <tt><create></tt> command containing a TTL value that is outside the server's permitted range, it <bcp14>MUST</bcp14> reject the command with a <tt>2004</tt> "Parameter value range error" response.
</t>
</section>
<section title="EPP <update> command">
<t>
This extension defines an additional element for EPP <tt><update></tt> commands for domain and host objects.
</t>
<t>
The <tt><command></tt> element of the <tt><update></tt> command <bcp14>MAY</bcp14> contain an <tt><extension></tt> element which <bcp14>MAY</bcp14> contain a <tt><ttl:update></tt> element.
This element <bcp14>MUST</bcp14> contain one or more <tt><ttl:ttl></tt> records as described in <xref target="extension-elements"/>.
</t>
<t>
Example domain <tt><update></tt> command:
</t>
<sourcecode><xi:include parse="text" href="examples/domain-update-command.xml.txt"/></sourcecode>
<t>
Example host <tt><update></tt> command:
</t>
<sourcecode><xi:include parse="text" href="examples/host-update-command.xml.txt"/></sourcecode>
<t>
If an EPP server receives an <tt><update></tt> command containing a TTL value that is outside the server's permitted range, it <bcp14>MUST</bcp14> reject the command with a <tt>2004</tt> "Parameter value range error" response.
</t>
</section>
</section>
</section>
<section title="Server processing of TTL values">
<section anchor="permitted-types" title="Permitted record types">
<t>
Server operators <bcp14>SHOULD</bcp14> configure server policy to restrict the supported DNS record types, in accordance with their own requirements.
For example, a server <bcp14>MAY</bcp14> allow clients to specify TTL values for <tt>DS</tt> records only.
</t>
<t>
A server which receives a <tt><create></tt> or <tt><update></tt> command which includes a restricted record type <bcp14>MUST</bcp14> respond with a 2306 "Parameter value policy" error.
</t>
<t>
Clients can discover the DNS record types for which an EPP server permits TTL values to be changed by performing a "Policy Mode" <tt><info></tt> command,
as outlined in <xref target="policy-mode"/>.
</t>
</section>
<section title="Use of TTL values in delegation records" anchor="using_ttl_values">
<t>
EPP servers which implement this extension <bcp14>SHOULD</bcp14> use the values provided by EPP clients for the TTL values of records published in the DNS for domain and (if supported) host objects.
</t>
<t>
EPP servers that use the "host attribute" model <bcp14>SHOULD</bcp14> use any <tt>NS</tt>, <tt>A</tt> and/or <tt>AAAA</tt> TTL values specified for the domain object when publishing <tt>NS</tt>, <tt>A</tt> and/or <tt>AAAA</tt> records derived from host attributes.
</t>
</section>
</section>
<section anchor="oob-changes" title="Out-of-band changes to TTL values">
<t>
EPP server operators <bcp14>MAY</bcp14>, in order to address operational or security issues, make changes to TTL values out-of-band (that is, not in response to an <tt><update></tt> command received from the sponsoring client).
</t>
<t>
Server operators <bcp14>MAY</bcp14> also implement automatic reset of TTL values, so that they revert to the default value a certain amount of time after an update has been made.
</t>
<t>
If a TTL value is changed out-of-band, EPP server operators <bcp14>MAY</bcp14> notify the sponsoring client using the EPP Change Poll extension (<xref target="RFC8590"/>), which provides a generalised method for EPP servers to notify clients of changes to objects under their sponsorship.
</t>
</section>
<section anchor="operational-considerations" title="Operational considerations">
<section title="Operational impact of TTL values">
<t>
Registry operators must consider the balance between registrants' desire for changes to domains to be visible in the DNS quickly, and the increased DNS query traffic that short TTLs can bring.
</t>
<t>
Registry operators <bcp14>SHOULD</bcp14> implement limits on the maximum and minimum accepted TTL values that are narrower than the values permitted in the XML schema in the <xref target="formal-syntax" format="title"/> (which were chosen to allow any TTL permitted in DNS records), in order to prevent scenarios where an excessively high or low TTL causes operational issues on either side of the zone cut.
</t>
<t>
<xref target="oob-changes"/> describes how server operators <bcp14>MAY</bcp14> unilaterally change TTL values in order to address operational or security issues, or only permit changes for limited time periods (after which TTLs revert to the default).
</t>
</section>
<section title="When TTL values should be changed">
<t>
A common operational mistake is changing of DNS record TTLs during or after the planned change to the records themselves.
This arises due to a misunderstanding about how TTLs work.
</t>
<t>
It is <bcp14>RECOMMENDED</bcp14> that guidance be provided to users so they are aware that changes to a TTL are only effective in shortening transition periods if implemented a period of time — at least equal to the current TTL — <em>before</em> the planned change.
The latency between receipt of the <tt><update></tt> command and the actual publication of the changes in the DNS should also be taken into consideration in this calculation.
</t>
</section>
<section title="Changes to server policy">
<t>
Registry operators may change their policies relating to TTL values from time to time.
Previously configured TTL values may consequently fall outside a newly-applied policy.
This document places no obligation on EPP server operators in respect of these values,
and server operators may, as part of a policy change, change the TTL values specified by clients for domain and host objects.
<xref target="oob-changes"/> describes how such out-of-band changes should be carried out.
</t>
</section>
</section>
<section anchor="security-considerations" title="Security considerations">
<section title="Fast-flux DNS">
<t>
Some malicious actors use a technique called "fast flux DNS" (<xref target="SAC-025"/>) to rapidly change the DNS configuration for a zone in order to evade takedown and law enforcement activity.
Server operators should take this into consideration when setting the lower limit on TTL values, since a short TTL on delegations may enhance the effectiveness of fast flux techniques on evasion.
</t>
<t>
Client implementations which provide an interface for customers to configure TTL values for domain names should consider implementing controls to deter and mitigate abusive behaviour,
such as those outlined in the "Current and Possible Mitigation Alternatives" section of <xref target="SAC-025"/>.
</t>
</section>
<section title="Compromised user accounts">
<t>
An attacker who obtains access to a customer account at a domain registrar which supports this extension could make unauthorised changes to the <tt>NS</tt> and/or glue records for a domain,
and then increase the associated TTLs so that the changes persist in caches for a long time after the attack has been detected.
</t>
<t>
Client implementations which provide an interface for customers to configure TTL values for domain names should consider implementing upper limits in order to reduce the impact of account compromise,
in addition to best practices relating to credential management, multi-factor authentication, risk-based access control, and so on.
</t>
</section>
</section>
<section anchor="IANA" title="IANA considerations">
<section title="XML namespace">
<t>
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in <xref target="RFC3688"/>.
The following URI assignment is requested of IANA:
</t>
<t>
Registration for the TTL namespace:
</t>
<list>
<t>
<strong>URI:</strong> <tt>urn:ietf:params:xml:ns:epp:ttl-1.0</tt>
</t>
<t>
<strong>Registrant Contact:</strong> IESG
</t>
<t>
<strong>XML:</strong> None. Namespace URIs do not represent an XML specification
</t>
</list>
<t>
Registration for the TTL XML schema:
</t>
<list>
<t>
<strong>URI:</strong> <tt>urn:ietf:params:xml:schema:epp:ttl-1.0</tt>
</t>
<t>
<strong>Registrant Contact:</strong> IESG
</t>
<t>
<strong>XML:</strong> See the "<xref target="formal-syntax" format="title"/>" section of this document
</t>
</list>
</section>
<section title="EPP extension registry">
<t>
The EPP extension described in this document is to be registered by IANA in the Extensions for the "Extensible Provisioning Protocol (EPP)" registry described in <xref target="RFC7451"/>.
The details of the registration are as follows:
</t>
<list>
<t>
<strong>Name of Extension:</strong> Extensible Provisioning Protocol (EPP) Mapping for DNS Time-To-Live (TTL) values
</t>
<t>
<strong>Document Status:</strong> Standards Track
</t>
<t>
<strong>Reference:</strong> URL of this document
</t>
<t>
<strong>Registrant Name and Email Address:</strong> IESG
</t>
<t>
<strong>TLDs:</strong> Any
</t>
<t>
<strong>IPR Disclosure:</strong> None
</t>
<t>
<strong>Status:</strong> Active
</t>
<t>
<strong>Notes:</strong> None
</t>
</list>
</section>
</section>
<section anchor="formal-syntax" title="Formal syntax">
<t>
The formal syntax presented here is a complete schema representation of the extension suitable for automated validation of EPP XML instances.
</t>
<sourcecode><xi:include parse="text" href="ttl-1.0.xsd"/></sourcecode>
</section>
<section anchor="implementation-status" title="Implementation status" removeInRFC="true">
<section title="Verisign EPP SDK">
<t>
<strong>Organization:</strong> Verisign Inc.
</t>
<t>
<strong>Name:</strong> Verisign EPP SDK
</t>
<t>
<strong>Description:</strong> The Verisign EPP SDK includes both a full client implementation and a full server stub implementation of this specification.
</t>
<t>
<strong>Level of maturity:</strong> Development
</t>
<t>
<strong>Coverage:</strong> All aspects of the protocol are implemented.
</t>
<t>
<strong>Licensing:</strong> GNU Lesser General Public License
</t>
<t>
<strong>Contact:</strong> [email protected]
</t>
<t>
<strong>URL:</strong> https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks
</t>
</section>
<section title="Pepper EPP Client">
<t>
<strong>Name:</strong> Pepper EPP Client
</t>
<t>
<strong>Description:</strong> The Pepper EPP client fully implements this specification.
The underlying <tt>Net::EPP::</tt> Perl module also implements this specification.
</t>
<t>
<strong>Level of maturity:</strong> Development
</t>
<t>
<strong>Coverage:</strong> All aspects of the protocol will be implemented.
</t>
<t>
<strong>Licensing:</strong> Perl Artistic License
</t>
<t>
<strong>Contact:</strong> The author of this document.
</t>
<t>
<strong>URL:</strong> https://github.com/gbxyz/pepper
</t>
</section>
</section>
<section title="Change log" anchor="change_log" removeInRFC="true">
<section title="Changes from 17 to 18"><ol>
<li>
Add a space after the <tt>C:</tt> and <tt>S:</tt> line prefixes in examples.
</li>
<li>
Fixed the prefixing of lines in the example in Section 2.1.1.2 (thanks Tim Bray).
</li>
<li>
Fixed broken end tags in examples in Section 1.2.2 and the capitalisation of IPv6 addresses (thanks Erik Kline).
</li>
<li>
Added normative reference to <xref target="IANA-RRTYPES"/>.
</li>
<li>
Replaced references to "command/response frames" with "EPP commands/responses".
</li>
<li>
Minor wording change in paragraph 2 of <xref target="ttl_element"/>.
</li>
<li>
Clarified wording in <xref target="supported-dns-record-types"/>.
</li>
</ol></section>
<section title="Changes from 16 to 17"><ol>
<li>
Further updates as suggested during IESG review.
</li>
</ol></section>
<section title="Changes from 15 to 16"><ol>
<li>
Updates as suggested during IESG review.
</li>
</ol></section>
<section title="Changes from 14 to 15"><ol>
<li>
Updates as suggested during AD review.
</li>
<li>
In the last paragraph of Section 3.2, make both lists of RR types be the same.
</li>
<li>
Update error codes to be consistent: 2004 (range error) when the TTL value is outside the permitted range,
and 2306 (policy error) for an invalid record type.
</li>
<li>
Correct section in reference to RFC 6895 (thanks Jasdip Singh).
</li>
<li>
Minor typographic fixes (thanks Jasdip Singh).
</li>
</ol></section>
<section title="Changes from 13 to 14"><ol>
<li>
Resolve remaining nit before IESG submission.
</li>
</ol></section>
<section title="Changes from 12 to 13"><ol>
<li>
Updates as per the document shepherd's suggestions.
</li>
</ol></section>
<section title="Changes from 11 to 12"><ol>
<li>
Updates as per the document shepherd's email to the list of 2024-06-10.
</li>
</ol></section>
<section title="Changes from 10 to 11"><ol>
<li>
Fix double word in <xref target="using_ttl_values"/>.
</li>
</ol></section>
<section title="Changes from 09 to 10">
<t>
Changes resulting from the Dnsdir review:
</t>
<ol>
<li>
Fixed example IPv6 addresses to use the preferred prefix 2001:DB8::.
</li>
<li>
Added paragraph to <xref target="permitted-types"/> describing how clients can use the Policy Mode <tt><info></tt> command (<xref target="policy-mode"/>) to discover the DNS record types supported by the server.
</li>
</ol>
</section>
<section title="Changes from 08 to 09"><ol>
<li>
Some wording changes suggested by James Gould and Tim Wicinski.
</li>
</ol></section>
<section title="Changes from 07 to 08"><ol>
<li>
Some wording changes suggested by Rick Wilhelm.
</li>
</ol></section>
<section title="Changes from 06 to 07"><ol>
<li>
Minor wording changes and nits reported by JG.
</li>
</ol></section>
<section title="Changes from 05 to 06"><ol>
<li>
Changed how <tt><info></tt> commands work so that a <tt><ttl:info></tt> element is required in order for <tt><ttl:ttl></tt> elements to be included in the response.
Thanks to JG for this feedback.
</li>
</ol></section>
<section title="Changes from 04 to 05"><ol>
<li>
removed the erroneous <tt>required="true"</tt> attribute from the <tt>min</tt>, <tt>default</tt> and <tt>max</tt> attributes of the <tt>responseTTLType</tt> type (thanks JG).
</li>
<li>
fixed the reference to RFC 6895 (thanks HS).
</li>
</ol></section>
<section title="Changes from 04 to 05"><ol>
<li>
Add the Verisign EPP SDK to <xref target="implementation-status"/>.
</li>
<li>
Add the <tt><ttl:info></tt> element and document how it affects server <tt><info></tt> responses.
</li>
<li>
Updated examples to exercise more of the schema.
</li>
<li>
Minor schema issue fixed.
</li>
</ol></section>
<section title="Changes from 03 to 04"><ol>
<li>
Changed the <tt>for</tt> attribute to be an enumeration and added the <tt>custom</tt> attribute.
</li>
<li>
Added the <tt>min</tt>, <tt>default</tt> and <tt>max</tt> attributes.