-
Notifications
You must be signed in to change notification settings - Fork 4
/
draft-ietf-dnsop-aname.html
1094 lines (1033 loc) · 64.7 KB
/
draft-ietf-dnsop-aname.html
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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Address-specific DNS aliases (ANAME)</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Overview">
<link href="#rfc.section.1.2" rel="Chapter" title="1.2 Terminology">
<link href="#rfc.section.2" rel="Chapter" title="2 The ANAME resource record">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Presentation and wire format">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Coexistence with other types">
<link href="#rfc.section.3" rel="Chapter" title="3 Substituting ANAME sibling address records">
<link href="#rfc.section.4" rel="Chapter" title="4 ANAME processing by primary masters">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Zone transfers">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 DNSSEC">
<link href="#rfc.section.4.3" rel="Chapter" title="4.3 TTLs">
<link href="#rfc.section.5" rel="Chapter" title="5 ANAME processing by resolvers">
<link href="#rfc.section.6" rel="Chapter" title="6 Query processing">
<link href="#rfc.section.6.1" rel="Chapter" title="6.1 Authoritative servers">
<link href="#rfc.section.6.1.1" rel="Chapter" title="6.1.1 Address queries">
<link href="#rfc.section.6.1.2" rel="Chapter" title="6.1.2 ANAME queries">
<link href="#rfc.section.6.2" rel="Chapter" title="6.2 Resolvers">
<link href="#rfc.section.6.2.1" rel="Chapter" title="6.2.1 Address queries">
<link href="#rfc.section.6.2.2" rel="Chapter" title="6.2.2 ANAME queries">
<link href="#rfc.section.7" rel="Chapter" title="7 IANA considerations">
<link href="#rfc.section.8" rel="Chapter" title="8 Security considerations">
<link href="#rfc.section.9" rel="Chapter" title="9 Acknowledgments">
<link href="#rfc.section.10" rel="Chapter" title="10 Changes since the last revision">
<link href="#rfc.section.10.1" rel="Chapter" title="10.1 Version -04">
<link href="#rfc.section.10.2" rel="Chapter" title="10.2 Version -03">
<link href="#rfc.section.10.3" rel="Chapter" title="10.3 Version -02">
<link href="#rfc.references" rel="Chapter" title="11 References">
<link href="#rfc.references.1" rel="Chapter" title="11.1 Normative References">
<link href="#rfc.references.2" rel="Chapter" title="11.2 Informative References">
<link href="#rfc.appendix.A" rel="Chapter" title="A Implementation status">
<link href="#rfc.appendix.B" rel="Chapter" title="B Historical note">
<link href="#rfc.appendix.C" rel="Chapter" title="C On preserving TTLs">
<link href="#rfc.appendix.C.1" rel="Chapter" title="C.1 Query bunching">
<link href="#rfc.appendix.C.2" rel="Chapter" title="C.2 Upstream caches">
<link href="#rfc.appendix.C.3" rel="Chapter" title="C.3 ANAME chains">
<link href="#rfc.appendix.C.4" rel="Chapter" title="C.4 ANAME substitution inside the name server">
<link href="#rfc.appendix.C.5" rel="Chapter" title="C.5 TTLs and zone transfers">
<link href="#rfc.appendix.D" rel="Chapter" title="D Alternative setups">
<link href="#rfc.appendix.D.1" rel="Chapter" title="D.1 Reducing query volume">
<link href="#rfc.appendix.D.2" rel="Chapter" title="D.2 Zone transfer scalability">
<link href="#rfc.appendix.D.3" rel="Chapter" title="D.3 Tailored responses">
<link href="#rfc.appendix.E" rel="Chapter" title="E ANAME loops">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.9.6 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Finch, T., Hunt, E., van Dijk, P., Eden, A., and W. Mekking" />
<meta name="dct.identifier" content="urn:ietf:id:draft-ietf-dnsop-aname-04" />
<meta name="dct.issued" scheme="ISO8601" content="2019-07-08" />
<meta name="dct.abstract" content="This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only for address queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to make an apex domain name into an alias in a standards compliant manner." />
<meta name="description" content="This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only for address queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to make an apex domain name into an alias in a standards compliant manner." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">DNS Operations</td>
<td class="right">T. Finch</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">University of Cambridge</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">E. Hunt</td>
</tr>
<tr>
<td class="left">Expires: January 9, 2020</td>
<td class="right">ISC</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">P. van Dijk</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">PowerDNS</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">A. Eden</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">DNSimple</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">W. Mekking</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">ISC</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">July 8, 2019</td>
</tr>
</tbody>
</table>
<p class="title">Address-specific DNS aliases (ANAME)<br />
<span class="filename">draft-ietf-dnsop-aname-04</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only for address queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to make an apex domain name into an alias in a standards compliant manner.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
<p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
<p>This Internet-Draft will expire on January 9, 2020.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<ul><li>1.1. <a href="#rfc.section.1.1">Overview</a>
</li>
<li>1.2. <a href="#rfc.section.1.2">Terminology</a>
</li>
</ul><li>2. <a href="#rfc.section.2">The ANAME resource record</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Presentation and wire format</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Coexistence with other types</a>
</li>
</ul><li>3. <a href="#rfc.section.3">Substituting ANAME sibling address records</a>
</li>
<li>4. <a href="#rfc.section.4">ANAME processing by primary masters</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">Zone transfers</a>
</li>
<li>4.2. <a href="#rfc.section.4.2">DNSSEC</a>
</li>
<li>4.3. <a href="#rfc.section.4.3">TTLs</a>
</li>
</ul><li>5. <a href="#rfc.section.5">ANAME processing by resolvers</a>
</li>
<li>6. <a href="#rfc.section.6">Query processing</a>
</li>
<ul><li>6.1. <a href="#rfc.section.6.1">Authoritative servers</a>
</li>
<ul><li>6.1.1. <a href="#rfc.section.6.1.1">Address queries</a>
</li>
<li>6.1.2. <a href="#rfc.section.6.1.2">ANAME queries</a>
</li>
</ul><li>6.2. <a href="#rfc.section.6.2">Resolvers</a>
</li>
<ul><li>6.2.1. <a href="#rfc.section.6.2.1">Address queries</a>
</li>
<li>6.2.2. <a href="#rfc.section.6.2.2">ANAME queries</a>
</li>
</ul></ul><li>7. <a href="#rfc.section.7">IANA considerations</a>
</li>
<li>8. <a href="#rfc.section.8">Security considerations</a>
</li>
<li>9. <a href="#rfc.section.9">Acknowledgments</a>
</li>
<li>10. <a href="#rfc.section.10">Changes since the last revision</a>
</li>
<ul><li>10.1. <a href="#rfc.section.10.1">Version -04</a>
</li>
<li>10.2. <a href="#rfc.section.10.2">Version -03</a>
</li>
<li>10.3. <a href="#rfc.section.10.3">Version -02</a>
</li>
</ul><li>11. <a href="#rfc.references">References</a>
</li>
<ul><li>11.1. <a href="#rfc.references.1">Normative References</a>
</li>
<li>11.2. <a href="#rfc.references.2">Informative References</a>
</li>
</ul><li>Appendix A. <a href="#rfc.appendix.A">Implementation status</a>
</li>
<li>Appendix B. <a href="#rfc.appendix.B">Historical note</a>
</li>
<li>Appendix C. <a href="#rfc.appendix.C">On preserving TTLs</a>
</li>
<ul><li>C.1. <a href="#rfc.appendix.C.1">Query bunching</a>
</li>
<li>C.2. <a href="#rfc.appendix.C.2">Upstream caches</a>
</li>
<li>C.3. <a href="#rfc.appendix.C.3">ANAME chains</a>
</li>
<li>C.4. <a href="#rfc.appendix.C.4">ANAME substitution inside the name server</a>
</li>
<li>C.5. <a href="#rfc.appendix.C.5">TTLs and zone transfers</a>
</li>
</ul><li>Appendix D. <a href="#rfc.appendix.D">Alternative setups</a>
</li>
<ul><li>D.1. <a href="#rfc.appendix.D.1">Reducing query volume</a>
</li>
<li>D.2. <a href="#rfc.appendix.D.2">Zone transfer scalability</a>
</li>
<li>D.3. <a href="#rfc.appendix.D.3">Tailored responses</a>
</li>
</ul><li>Appendix E. <a href="#rfc.appendix.E">ANAME loops</a>
</li>
<li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#introduction" id="introduction">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">It can be desirable to provide web sites (and other services) at a bare domain name (such as <samp>example.com</samp>) as well as a service-specific subdomain (<samp>www.example.com</samp>).</p>
<p id="rfc.section.1.p.2">If the web site is hosted by a third-party provider, the ideal way to provision its name in the DNS is using a CNAME record, so that the third party provider retains control over the mapping from names to IP address(es). It is now common for name-to-address mappings to be highly dynamic, dependent on client location, server load, etc.</p>
<p id="rfc.section.1.p.3">However, CNAME records cannot coexist with other records with the same owner name. (The reason why is explored in <a href="#history" class="xref">Appendix B</a>). This restriction means they cannot appear at a zone apex (such as <samp>example.com</samp>) because of the SOA, NS, and other records that have to be present there. CNAME records can also conflict at subdomains, for example, if <samp>department.example.edu</samp> has separately hosted mail and web servers.</p>
<p id="rfc.section.1.p.4">Redirecting website lookups to an alternate domain name via SRV or URI resource records would be an effective solution from the DNS point of view, but to date, browser vendors have not accepted this approach.</p>
<p id="rfc.section.1.p.5">As a result, the only widely supported and standards-compliant way to publish a web site at a bare domain is to place address records (A and/or AAAA) at the zone apex. The flexibility afforded by CNAME is not available.</p>
<p id="rfc.section.1.p.6">This document specifies a new RR type "ANAME", which provides similar functionality to CNAME, but only for address queries (i.e., for type A or AAAA). The basic idea is that the address records next to an ANAME record are automatically copied from and kept in sync with the ANAME target's address records. The ANAME record can be present at any DNS node, and can coexist with most other RR types, enabling it to be present at a zone apex, or any other name where the presence of other records prevents the use of a CNAME record.</p>
<p id="rfc.section.1.p.7">Similar authoritative functionality has been implemented and deployed by a number of DNS software vendors and service providers, using names such as ALIAS, ANAME, apex CNAME, CNAME flattening, and top-level redirection. These mechanisms are proprietary, which hinders the ability of zone owners to have the same data served from multiple providers or to move from one provider to another. None of these proprietary implementations includes a mechanism for resolvers to follow the redirection chain themselves.</p>
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#overview" id="overview">Overview</a>
</h1>
<p id="rfc.section.1.1.p.1">The core functionality of this mechanism allows zone administrators to start using ANAME records unilaterally, without requiring secondary servers or resolvers to be upgraded.</p>
<p></p>
<ul>
<li>The resource record definition in <a href="#rdata" class="xref">Section 2</a> is intended to provide zone data portability between standards-compliant DNS servers and the common core functionality of existing proprietary ANAME-like facilities.</li>
<li>The zone maintenance mechanism described in <a href="#primary" class="xref">Section 4</a> keeps the ANAME's sibling address records in sync with the ANAME target.</li>
</ul>
<p> </p>
<p id="rfc.section.1.1.p.3">This definition is enough to be useful by itself. However, it can be less than optimal in certain situations: for instance, when the ANAME target uses clever tricks to provide different answers to different clients to improve latency or load balancing. The query processing rules in <a href="#queryprocessing" class="xref">Section 6</a> require to include the ANAME record so that resolvers can use this information (as described in <a href="#resolver" class="xref">Section 5</a>) to obtain answers that are tailored to the resolver rather than to the zone's primary master.</p>
<p id="rfc.section.1.1.p.4">Resolver support for ANAME is not necessary, since ANAME-oblivious resolvers can get working answers from authoritative servers. It's just an optimization that can be rolled out incrementally, and that will help ANAME to work better the more widely it is deployed.</p>
<h1 id="rfc.section.1.2">
<a href="#rfc.section.1.2">1.2.</a> <a href="#terminology" id="terminology">Terminology</a>
</h1>
<p id="rfc.section.1.2.p.1">An "address record" is a DNS resource record whose type is A or AAAA. These are referred to as "address types". "Address query" refers to a DNS query for any address type.</p>
<p id="rfc.section.1.2.p.2">When talking about "address records" we mean the entire RRset, including owner name and TTL. We treat missing address records (i.e. NXDOMAIN or NODATA) the same successfully resolving as a set of zero address records, and distinct from "failure" which covers error responses such as SERVFAIL or REFUSED.</p>
<p id="rfc.section.1.2.p.3">The "sibling address records" of an ANAME record are the address records at the same owner name as the ANAME, which are subject to ANAME substitution.</p>
<p id="rfc.section.1.2.p.4">The "target address records" of an ANAME record are the address records obtained by resolving the ultimate target of the ANAME (see <a href="#subst" class="xref">Section 3</a>).</p>
<p id="rfc.section.1.2.p.5">During the process of looking up the target address records, one or more CNAME or ANAME records may be encountered. These records are not the final target address records, and are referred in this document as "intermediate records". The target name must be replaced with the new name provided in the RDATA and the new target is resolved.</p>
<p id="rfc.section.1.2.p.6">Other DNS-related terminology can be found in <a href="#RFC8499" class="xref">[RFC8499]</a>.</p>
<p id="rfc.section.1.2.p.7">The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in <a href="#RFC2119" class="xref">[RFC2119]</a>.</p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#rdata" id="rdata">The ANAME resource record</a>
</h1>
<p id="rfc.section.2.p.1">This document defines the "ANAME" DNS resource record type, with RR TYPE value [TBD].</p>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#presentation-and-wire-format" id="presentation-and-wire-format">Presentation and wire format</a>
</h1>
<p id="rfc.section.2.1.p.1">The ANAME presentation format is identical to that of CNAME <a href="#RFC1033" class="xref">[RFC1033]</a>:</p>
<pre> owner ttl class ANAME target
</pre>
<p id="rfc.section.2.1.p.2">The wire format is also identical to CNAME <a href="#RFC1035" class="xref">[RFC1035]</a>, except that name compression is not permitted in ANAME RDATA, per <a href="#RFC3597" class="xref">[RFC3597]</a>.</p>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#coexistence" id="coexistence">Coexistence with other types</a>
</h1>
<p id="rfc.section.2.2.p.1">Only one ANAME <target> can be defined per <owner>. An ANAME RRset MUST NOT contain more than one resource record.</p>
<p id="rfc.section.2.2.p.2">An ANAME's sibling address records are under the control of ANAME processing (see <a href="#primary" class="xref">Section 4</a>) and are not first-class records in their own right. They MAY exist in zone files, but they can subsequently be altered by ANAME processing.</p>
<p id="rfc.section.2.2.p.3">An ANAME record MAY freely coexist at the same owner name with other RR types, except they MUST NOT coexist with CNAME or any other RR type that restricts the types with which it can itself coexist. That means An ANAME record can coexist at the same owner name with A and AAAA records. These are the sibling address records that are updated with the target addresses that are retrieved through the ANAME substitution process <a href="#subst" class="xref">Section 3</a>.</p>
<p id="rfc.section.2.2.p.4">Like other types, An ANAME record can coexist with DNAME records at the same owner name; in fact, the two can be used cooperatively to redirect both the owner name address records (via ANAME) and everything under it (via DNAME).</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#subst" id="subst">Substituting ANAME sibling address records</a>
</h1>
<p id="rfc.section.3.p.1">This process is used by both primary masters (see <a href="#primary" class="xref">Section 4</a>) and resolvers (see <a href="#resolver" class="xref">Section 5</a>), though they vary in how they apply the edit described in the final step. However, this process is not exclusively used by primary masters and resolvers: it may be executed as a bump in the wire, as part of the query lookup, or at any other point during query resolution.</p>
<p id="rfc.section.3.p.2">The following steps MUST be performed for each address type:</p>
<p></p>
<ol>
<li>Starting at the ANAME owner, follow the chain of ANAME and/or CNAME records as far as possible to find the ultimate target.</li>
<li>If a loop is detected, continue with an empty RRset, otherwise get the ultimate target's address records. (Ignore any sibling address records of intermediate ANAMEs.)</li>
<li>Stop if resolution failed. (Note that NXDOMAIN and NODATA count as successfully resolving an empty RRset.)</li>
<li>If one or more address records are found, replace the owner of the target address records with the owner of the ANAME record. Set the TTL to the minimum of the ANAME TTL, the TTL of each intermediate record, and the TTL of the target address records. Drop any RRSIG records.</li>
<li>Stop if this modified RRset is the same as the sibling RRset (ignoring any RRSIG records). The comparison MAY treat nearly-equal TTLs as the same.</li>
<li>Delete the sibling address RRset (if any) and replace it with the modified RRset.</li>
</ol>
<p> </p>
<p id="rfc.section.3.p.4">At this point, the substituted RRset is not signed. A primary master will proceed to sign the substituted RRset, whereas resolvers can only use the substituted RRset when an unsigned answer is appropriate. This is explained in more detail in the following sections.</p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#primary" id="primary">ANAME processing by primary masters</a>
</h1>
<p id="rfc.section.4.p.1">Each ANAME's sibling address records are kept up-to-date as if by the following process, for each address type:</p>
<p></p>
<ul>
<li>Perform ANAME sibling address record substitution as described in <a href="#subst" class="xref">Section 3</a>. Any edit performed in the final step is applied to the ANAME's zone. A primary server MAY use Dynamic Updates (DNS UPDATE) <a href="#RFC2136" class="xref">[RFC2136]</a> to update the zone.</li>
<li>If resolution failed, wait for a period before trying again. This retry time SHOULD be configurable.</li>
<li>Otherwise, wait until the target address RRset TTL has expired or is close to expiring, then repeat.</li>
</ul>
<p> </p>
<p id="rfc.section.4.p.3">It may be more efficient to manage the polling per ANAME target rather than per ANAME as specified (for example if the same ANAME target is used by multiple zones).</p>
<p id="rfc.section.4.p.4">Sibling address records are committed to the zone and stored in nonvolatile storage. This allows a server to restart without delays due to ANAME processing, use offline DNSSEC signing, and not implement special ANAME processing logic when handling a DNS query.</p>
<p><a href="#alternatives" class="xref">Appendix D</a> describes how ANAME would fit in different DNS architectures that use online signing or tailored responses.</p>
<h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#zone-transfers" id="zone-transfers">Zone transfers</a>
</h1>
<p id="rfc.section.4.1.p.1">ANAME is no more special than any other RRtype and does not introduce any special processing related to zone transfers.</p>
<p id="rfc.section.4.1.p.2">A zone containing ANAME records that point to frequently-changing targets will itself change frequently, and may see an increased number of zone transfers. Or if a very large number of zones are sharing the same ANAME target, and that changes address, that may cause a great volume of zone transfers. Guidance on dealing with ANAME in large scale implementations is provided <a href="#alternatives" class="xref">Appendix D</a>.</p>
<p id="rfc.section.4.1.p.3">Secondary servers rely on zone transfers to obtain sibling address records, just like the rest of the zone, and serve them in the usual way (see <a href="#queryprocessing" class="xref">Section 6</a>). A working DNS NOTIFY <a href="#RFC1996" class="xref">[RFC1996]</a> setup is recommended to avoid extra delays propagating updated sibling address records when they change.</p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#dnssec" id="dnssec">DNSSEC</a>
</h1>
<p id="rfc.section.4.2.p.1">A zone containing ANAME records that will update address records has to do so before signing the zone with DNSSEC <a href="#RFC4033" class="xref">[RFC4033]</a> <a href="#RFC4034" class="xref">[RFC4034]</a> <a href="#RFC4035" class="xref">[RFC4035]</a>. This means that for traditional DNSSEC signing the substitution of sibling address records must be done before signing and loading the zone into the name server. For servers that support online signing, the substitution may happen as part of the name server process, after loading the zone.</p>
<p id="rfc.section.4.2.p.2">DNSSEC signatures on sibling address records are generated in the same way as for normal (dynamic) updates.</p>
<h1 id="rfc.section.4.3">
<a href="#rfc.section.4.3">4.3.</a> <a href="#ttl" id="ttl">TTLs</a>
</h1>
<p id="rfc.section.4.3.p.1">Sibling address records are served from authoritative servers with a fixed TTL. Normally this TTL is expected to be the same as the target address records' TTL; however the exact mechanism for obtaining the target is unspecified, so cache effects, following ANAME and CNAME chains, or deliberate policies might make the sibling TTL smaller.</p>
<p id="rfc.section.4.3.p.2">This means that when adding address records into the zone as a result of ANAME processing, the TTL to use is at most that of the TTL of the address target records. If you use a higher value, this will stretch the TTL which is undesired.</p>
<p id="rfc.section.4.3.p.3">TTL stretching is hard to avoid when implementing ANAME substitution at the primary: The target address records' TTL influences the update rate of the zone, while the sibling address records' TTL determine how long a resolver may cache the address records. Thus, the end-to-end TTL (from the authoritative servers for the target address records to end-user DNS caches) is nearing twice the target address record TTL. There is a more extended discussion of TTL handling in <a href="#ttls" class="xref">Appendix C</a>.</p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#resolver" id="resolver">ANAME processing by resolvers</a>
</h1>
<p id="rfc.section.5.p.1">When a resolver makes an address query in the usual way, it might receive a response containing ANAME information in the Answer section, as described in <a href="#queryprocessing" class="xref">Section 6</a>. This informs the resolver that it MAY resolve the ANAME target address records to get answers that are tailored to the resolver rather than the ANAME's primary master.</p>
<p id="rfc.section.5.p.2">In order to provide tailored answers to clients that are ANAME-oblivious, the resolver MAY perform sibling address record substitution in the following situations:</p>
<p></p>
<ul>
<li>The resolver's client queries with DO=0. (As discussed in <a href="#security-considerations" class="xref">Section 8</a>, if the resolver finds it would downgrade a secure answer to insecure, it MAY choose not to substitute the sibling address records.)</li>
<li>The resolver's client queries with DO=1 and the ANAME and sibling address records are unsigned. (Note that this situation does not apply when the records are signed but insecure: the resolver might not be able to validate them because of a broken chain of trust, but its client could have an extra trust anchor that does allow it to validate them; if the resolver substitutes the sibling address records they will become bogus.)</li>
</ul>
<p> </p>
<p id="rfc.section.5.p.4">In these first two cases, the resolver MAY perform ANAME sibling address record substitution as described in <a href="#subst" class="xref">Section 3</a>. Any edit performed in the final step is applied to the Answer section of the response.</p>
<p id="rfc.section.5.p.5">If the resolver's client is querying using an API such as <samp>getaddrinfo</samp> <a href="#RFC3493" class="xref">[RFC3493]</a> that does not support DNSSEC validation, the resolver MAY perform ANAME sibling address record substitution as described in <a href="#subst" class="xref">Section 3</a>. Any edits performed in the final step are applied to the addresses returned by the API. (This case is for validating stub resolvers that query an upstream recursive server with DO=1, so they cannot rely on the recursive server to do ANAME substitution for them.)</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#queryprocessing" id="queryprocessing">Query processing</a>
</h1>
<h1 id="rfc.section.6.1">
<a href="#rfc.section.6.1">6.1.</a> <a href="#authoritative-servers" id="authoritative-servers">Authoritative servers</a>
</h1>
<h1 id="rfc.section.6.1.1">
<a href="#rfc.section.6.1.1">6.1.1.</a> <a href="#address-queries" id="address-queries">Address queries</a>
</h1>
<p id="rfc.section.6.1.1.p.1">When a server receives an address query for a name that has an ANAME record, the response's Answer section MUST contain the ANAME record, in addition to the sibling address queries. The ANAME record indicates to a client that it might wish to resolve the target address records itself.</p>
<h1 id="rfc.section.6.1.2">
<a href="#rfc.section.6.1.2">6.1.2.</a> <a href="#aname-queries" id="aname-queries">ANAME queries</a>
</h1>
<p id="rfc.section.6.1.2.p.1">When a server receives an query for type ANAME, regardless of whether the ANAME record exists on the queried domain, any sibling address records SHOULD be added to the Additional section. Note that the sibling address records may have been substituted already.</p>
<p id="rfc.section.6.1.2.p.2">When adding address records to the Additional section, if not all address types are present and the zone is signed, the server SHOULD include a DNSSEC proof of nonexistence for the missing address types.</p>
<h1 id="rfc.section.6.2">
<a href="#rfc.section.6.2">6.2.</a> <a href="#resolvers" id="resolvers">Resolvers</a>
</h1>
<h1 id="rfc.section.6.2.1">
<a href="#rfc.section.6.2.1">6.2.1.</a> <a href="#address-queries-1" id="address-queries-1">Address queries</a>
</h1>
<p id="rfc.section.6.2.1.p.1">When a server receives an address query for a name that has an ANAME record, the response's Answer section MUST contain the ANAME record, in addition to the sibling address queries.</p>
<p id="rfc.section.6.2.1.p.2">The Additional section MAY contain the target address records that match the query type (or the corresponding proof of nonexistence), if they are available in the cache and the target address RDATA fields differ from the sibling address RRset.</p>
<p id="rfc.section.6.2.1.p.3">An ANAME target MAY resolve to address records via a chain of CNAME and/or ANAME records; any CNAME/ANAME chain MUST be included when adding target address records to a response's Additional section.</p>
<h1 id="rfc.section.6.2.2">
<a href="#rfc.section.6.2.2">6.2.2.</a> <a href="#aname-queries-1" id="aname-queries-1">ANAME queries</a>
</h1>
<p id="rfc.section.6.2.2.p.1">When a resolver receives an query for type ANAME, any sibling address records SHOULD be added to the Additional section. Just like with an authoritative server, when adding address records to the Additional section, if not all address types are present and the zone is signed, the resolver SHOULD include a DNSSEC proof of nonexistence for the missing address types.</p>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#iana-considerations" id="iana-considerations">IANA considerations</a>
</h1>
<p id="rfc.section.7.p.1">IANA is requested to assign a DNS RR TYPE value for ANAME resource records under the "Resource Record (RR) TYPEs" subregistry under the "Domain Name System (DNS) Parameters" registry.</p>
<p id="rfc.section.7.p.2">IANA might wish to consider the creation of a registry of address types; addition of new types to such a registry would then implicitly update this specification.</p>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#security-considerations" id="security-considerations">Security considerations</a>
</h1>
<p id="rfc.section.8.p.1">When a primary master updates an ANAME's sibling address records to match its target address records, it uses its own best information as to the correct answer. The primary master might sign the updated records, but that is not a guarantee of the actual correctness of the answer. This signing can have the effect of promoting an insecure response from the ANAME <target> to a signed response from the <owner>, which can then appear to clients to be more trustworthy than it should. DNSSEC validation SHOULD be used when resolving the ANAME <target> to mitigate this possible harm. Primary masters MAY refuse to substitute ANAME sibling address records unless the <target> node is both signed and validated.</p>
<p id="rfc.section.8.p.2">When a resolver substitutes an ANAME's sibling address records, it can find that the sibling address records are secure but the target address records are insecure. Going ahead with the substitution will downgrade a secure answer to an insecure one. However this is likely to be the counterpart of the situation described in the previous paragraph, so the resolver is downgrading an answer that the ANAME's primary master upgraded. A resolver will only downgrade an answer in this way when its client is security-oblivious; however the client's path to the resolver is likely to be practically safer than the resolver's path to the ANAME target's servers. Resolvers MAY choose not to substitute sibling address records when they are more secure than the target address records.</p>
<h1 id="rfc.section.9">
<a href="#rfc.section.9">9.</a> <a href="#acknowledgments" id="acknowledgments">Acknowledgments</a>
</h1>
<p id="rfc.section.9.p.1">Thanks to Mark Andrews, Ray Bellis, Stefan Buehler, Paul Ebersman, Richard Gibson, Tatuya JINMEI, Hakan Lindqvist, Mattijs Mekking, Stephen Morris, Bjorn Mott, Richard Salts, Mukund Sivaraman, Job Snijders, Jan Vcelak, Paul Vixie, Duane Wessels, and Paul Wouters, Olli Vanhoja, Brian Dickson for discussion and feedback.</p>
<h1 id="rfc.section.10">
<a href="#rfc.section.10">10.</a> <a href="#changes-since-the-last-revision" id="changes-since-the-last-revision">Changes since the last revision</a>
</h1>
<p id="rfc.section.10.p.1">[This section is to be removed before publication as an RFC.]</p>
<p id="rfc.section.10.p.2">The full history of this draft and its issue tracker can be found at <a href="https://github.com/each/draft-aname">https://github.com/each/draft-aname</a></p>
<h1 id="rfc.section.10.1">
<a href="#rfc.section.10.1">10.1.</a> <a href="#version-04" id="version-04">Version -04</a>
</h1>
<p></p>
<ul>
<li>Split up section about Additional Section processing.</li>
<li>Update Additional Section processing requirements.</li>
<li>Clarify when ANAME resolution may happen [#43].</li>
<li>Revisit TTL considerations [#30, #34].</li>
<li>ANAME goes into the Answer section when QTYPE=A|AAAA [#62].</li>
<li>Update alternative setups section with concerns (Brian Dickson) [#68].</li>
<li>Add section on ANAME loops (open issue [#45]).</li>
</ul>
<p> </p>
<h1 id="rfc.section.10.2">
<a href="#rfc.section.10.2">10.2.</a> <a href="#version-03" id="version-03">Version -03</a>
</h1>
<p></p>
<ul>
<li>Grammar improvements (Olli Vanhoja)</li>
<li>Split up Implications section, clarify text on zone transfers and dynamic updates [#39].</li>
<li>Rewrite Alternative setup section and move to Appendix, add text on zone transfer scalibility concerns and GeoIP.</li>
</ul>
<p> </p>
<h1 id="rfc.section.10.3">
<a href="#rfc.section.10.3">10.3.</a> <a href="#version-02" id="version-02">Version -02</a>
</h1>
<p id="rfc.section.10.3.p.1">Major revamp, so authoritative servers (other than primary masters) now do not do any special ANAME processing, just Additional section processing.</p>
<h1 id="rfc.references">
<a href="#rfc.references">11.</a> References</h1>
<h1 id="rfc.references.1">
<a href="#rfc.references.1">11.1.</a> Normative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="RFC1033">[RFC1033]</b></td>
<td class="top">
<a>Lottor, M.</a>, "<a href="https://tools.ietf.org/html/rfc1033">Domain Administrators Operations Guide</a>", RFC 1033, DOI 10.17487/RFC1033, November 1987.</td>
</tr>
<tr>
<td class="reference"><b id="RFC1035">[RFC1035]</b></td>
<td class="top">
<a>Mockapetris, P.</a>, "<a href="https://tools.ietf.org/html/rfc1035">Domain names - implementation and specification</a>", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2119">[RFC2119]</b></td>
<td class="top">
<a>Bradner, S.</a>, "<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2136">[RFC2136]</b></td>
<td class="top">
<a>Vixie, P.</a>, <a>Thomson, S.</a>, <a>Rekhter, Y.</a> and <a>J. Bound</a>, "<a href="https://tools.ietf.org/html/rfc2136">Dynamic Updates in the Domain Name System (DNS UPDATE)</a>", RFC 2136, DOI 10.17487/RFC2136, April 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC3597">[RFC3597]</b></td>
<td class="top">
<a>Gustafsson, A.</a>, "<a href="https://tools.ietf.org/html/rfc3597">Handling of Unknown DNS Resource Record (RR) Types</a>", RFC 3597, DOI 10.17487/RFC3597, September 2003.</td>
</tr>
<tr>
<td class="reference"><b id="RFC4033">[RFC4033]</b></td>
<td class="top">
<a>Arends, R.</a>, <a>Austein, R.</a>, <a>Larson, M.</a>, <a>Massey, D.</a> and <a>S. Rose</a>, "<a href="https://tools.ietf.org/html/rfc4033">DNS Security Introduction and Requirements</a>", RFC 4033, DOI 10.17487/RFC4033, March 2005.</td>
</tr>
<tr>
<td class="reference"><b id="RFC4034">[RFC4034]</b></td>
<td class="top">
<a>Arends, R.</a>, <a>Austein, R.</a>, <a>Larson, M.</a>, <a>Massey, D.</a> and <a>S. Rose</a>, "<a href="https://tools.ietf.org/html/rfc4034">Resource Records for the DNS Security Extensions</a>", RFC 4034, DOI 10.17487/RFC4034, March 2005.</td>
</tr>
<tr>
<td class="reference"><b id="RFC4035">[RFC4035]</b></td>
<td class="top">
<a>Arends, R.</a>, <a>Austein, R.</a>, <a>Larson, M.</a>, <a>Massey, D.</a> and <a>S. Rose</a>, "<a href="https://tools.ietf.org/html/rfc4035">Protocol Modifications for the DNS Security Extensions</a>", RFC 4035, DOI 10.17487/RFC4035, March 2005.</td>
</tr>
<tr>
<td class="reference"><b id="RFC7871">[RFC7871]</b></td>
<td class="top">
<a>Contavalli, C.</a>, <a>van der Gaast, W.</a>, <a>Lawrence, D.</a> and <a>W. Kumari</a>, "<a href="https://tools.ietf.org/html/rfc7871">Client Subnet in DNS Queries</a>", RFC 7871, DOI 10.17487/RFC7871, May 2016.</td>
</tr>
<tr>
<td class="reference"><b id="RFC8499">[RFC8499]</b></td>
<td class="top">
<a>Hoffman, P.</a>, <a>Sullivan, A.</a> and <a>K. Fujiwara</a>, "<a href="https://tools.ietf.org/html/rfc8499">DNS Terminology</a>", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019.</td>
</tr>
</tbody></table>
<h1 id="rfc.references.2">
<a href="#rfc.references.2">11.2.</a> Informative References</h1>
<table><tbody>
<tr>
<td class="reference"><b id="RFC0882">[RFC0882]</b></td>
<td class="top">
<a>Mockapetris, P.</a>, "<a href="https://tools.ietf.org/html/rfc882">Domain names: Concepts and facilities</a>", RFC 882, DOI 10.17487/RFC0882, November 1983.</td>
</tr>
<tr>
<td class="reference"><b id="RFC0973">[RFC0973]</b></td>
<td class="top">
<a>Mockapetris, P.</a>, "<a href="https://tools.ietf.org/html/rfc973">Domain system changes and observations</a>", RFC 973, DOI 10.17487/RFC0973, January 1986.</td>
</tr>
<tr>
<td class="reference"><b id="RFC1034">[RFC1034]</b></td>
<td class="top">
<a>Mockapetris, P.</a>, "<a href="https://tools.ietf.org/html/rfc1034">Domain names - concepts and facilities</a>", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.</td>
</tr>
<tr>
<td class="reference"><b id="RFC1996">[RFC1996]</b></td>
<td class="top">
<a>Vixie, P.</a>, "<a href="https://tools.ietf.org/html/rfc1996">A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</a>", RFC 1996, DOI 10.17487/RFC1996, August 1996.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2065">[RFC2065]</b></td>
<td class="top">
<a>Eastlake 3rd, D.</a> and <a>C. Kaufman</a>, "<a href="https://tools.ietf.org/html/rfc2065">Domain Name System Security Extensions</a>", RFC 2065, DOI 10.17487/RFC2065, January 1997.</td>
</tr>
<tr>
<td class="reference"><b id="RFC2308">[RFC2308]</b></td>
<td class="top">
<a>Andrews, M.</a>, "<a href="https://tools.ietf.org/html/rfc2308">Negative Caching of DNS Queries (DNS NCACHE)</a>", RFC 2308, DOI 10.17487/RFC2308, March 1998.</td>
</tr>
<tr>
<td class="reference"><b id="RFC3493">[RFC3493]</b></td>
<td class="top">
<a>Gilligan, R.</a>, <a>Thomson, S.</a>, <a>Bound, J.</a>, <a>McCann, J.</a> and <a>W. Stevens</a>, "<a href="https://tools.ietf.org/html/rfc3493">Basic Socket Interface Extensions for IPv6</a>", RFC 3493, DOI 10.17487/RFC3493, February 2003.</td>
</tr>
</tbody></table>
<h1 id="rfc.appendix.A">
<a href="#rfc.appendix.A">Appendix A.</a> <a href="#implementation-status" id="implementation-status">Implementation status</a>
</h1>
<p id="rfc.section.A.p.1">PowerDNS currently implements a similar authoritative-only feature using "ALIAS" records, which are expanded by the primary server and transfered as address records to secondaries.</p>
<p id="rfc.section.A.p.2">[TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS, Cloudflare, Amazon, Dyn, and Akamai.]</p>
<h1 id="rfc.appendix.B">
<a href="#rfc.appendix.B">Appendix B.</a> <a href="#history" id="history">Historical note</a>
</h1>
<p id="rfc.section.B.p.1">In the early DNS <a href="#RFC0882" class="xref">[RFC0882]</a>, CNAME records were allowed to coexist with other records. However this led to coherency problems: if a resolver had no cache entries for a given name, it would resolve queries for un-cached records at that name in the usual way; once it had cached a CNAME record for a name, it would resolve queries for un-cached records using CNAME target instead.</p>
<p id="rfc.section.B.p.2">For example, given the zone contents below, the original CNAME behaviour meant that if you asked for <samp>alias.example.com TXT</samp> first, you would get the answer "owner", but if you asked for <samp>alias.example.com A</samp> then <samp>alias.example.com TXT</samp> you would get the answer "target".</p>
<pre> alias.example.com. TXT "owner"
alias.example.com. CNAME canonical.example.com.
canonical.example.com. TXT "target"
canonical.example.com. A 192.0.2.1
</pre>
<p id="rfc.section.B.p.3">This coherency problem was fixed in <a href="#RFC0973" class="xref">[RFC0973]</a> which introduced the inconvenient rule that a CNAME acts as an alias for all other RR types at a name, which prevents the coexistence of CNAME with other records.</p>
<p id="rfc.section.B.p.4">A better fix might have been to improve the cache's awareness of which records do and do not coexist with a CNAME record. However that would have required a negative cache mechanism which was not added to the DNS until later <a href="#RFC1034" class="xref">[RFC1034]</a> <a href="#RFC2308" class="xref">[RFC2308]</a>.</p>
<p id="rfc.section.B.p.5">While <a href="#RFC2065" class="xref">[RFC2065]</a> relaxed the restriction by allowing coexistence of CNAME with DNSSEC records, this exception is still not applicable to other resource records. RRSIG and NSEC exist to prove the integrity of the CNAME record; they are not intended to associate arbitrary data with the domain name. DNSSEC records avoid interoperability problems by being largely invisible to security-oblivious resolvers.</p>
<p id="rfc.section.B.p.6">Now that the DNS has negative caching, it is tempting to amend the algorithm for resolving with CNAME records to allow them to coexist with other types. Although an amended resolver will be compatible with the rest of the DNS, it will not be of much practical use because authoritative servers which rely on coexisting CNAMEs will not interoperate well with older resolvers. Practical experiments show that the problems are particularly acute when CNAME and MX try to coexist.</p>
<h1 id="rfc.appendix.C">
<a href="#rfc.appendix.C">Appendix C.</a> <a href="#ttls" id="ttls">On preserving TTLs</a>
</h1>
<p id="rfc.section.C.p.1">An ANAME's sibling address records are in an unusual situation: they are authoritative data in the owner's zone, so from that point of view the owner has the last say over what their TTL should be; on the other hand, ANAMEs are supposed to act as aliases, in which case the target should control the address record TTLs.</p>
<p id="rfc.section.C.p.2">However there are some technical constraints that make it difficult to preserve the target address record TTLs.</p>
<p id="rfc.section.C.p.3">The following subsections conclude that the end-to-end TTL (from the authoritative servers for the target address records to end-user DNS caches) is nearing twice the target address record TTL.</p>
<h1 id="rfc.appendix.C.1">
<a href="#rfc.appendix.C.1">C.1.</a> <a href="#bunching" id="bunching">Query bunching</a>
</h1>
<p id="rfc.section.C.1.p.1">If the times of end-user queries for a domain name are well distributed, then (typically) queries received by the authoritative servers for that domain are also well distributed. If the domain is popular, a recursive server will re-query for it once every TTL seconds, but the periodic queries from all the various recursive servers will not be aligned, so the queries remain well distributed.</p>
<p id="rfc.section.C.1.p.2">However, imagine that the TTLs of an ANAME's sibling address records are decremented in the same way as cache entries in recursive servers. Then all the recursive servers querying for the name would try to refresh their caches at the same time when the TTL reaches zero. They would become synchronized, and all the queries for the domain would be bunched into periodic spikes.</p>
<p id="rfc.section.C.1.p.3">This specification says that ANAME sibling address records have a normal fixed TTL derived from (e.g. equal or nearly equal to) the target address records' original TTL. There is no cache-like decrementing TTL, so there is no bunching of queries.</p>
<h1 id="rfc.appendix.C.2">
<a href="#rfc.appendix.C.2">C.2.</a> <a href="#upstream-caches" id="upstream-caches">Upstream caches</a>
</h1>
<p id="rfc.section.C.2.p.1">There are two straightforward ways to get an RRset's original TTL:</p>
<p></p>
<ul>
<li>by directly querying an authoritative server;</li>
<li>using the original TTL field from the RRset's RRGIG record(s).</li>
</ul>
<p> </p>
<p id="rfc.section.C.2.p.3">However, not all zones are signed, and a primary master might not be able to query other authoritative servers directly (e.g. if it is a hidden primary behind a strict firewall). Instead it might have to obtain an ANAME's target address records via some other recursive server.</p>
<p id="rfc.section.C.2.p.4">Querying via a separate recursive server means the primary master cannot trivially obtain the target address records' original TTLs. Fortunately this is likely to be a self-correcting problem for similar reasons to the query-bunching discussed in the previous subsection. The primary master can inspect the target address records just after the TTL expires when its upstream cache has just refreshed them, so the TTL will be nearly equal to the original TTL.</p>
<p id="rfc.section.C.2.p.5">A related consideration is that the primary master cannot in general refresh its copies of an ANAME's target address records more frequently than their TTL, without privileged control over its resolver cache.</p>
<p id="rfc.section.C.2.p.6">Combined with the requirement that sibling address records are served with a fixed TTL, this means that the end-to-end TTL will be the target address record TTL (which determines when the sibling address records are updated) plus the sibling address record TTL (which determines when end-user caches are updated). Since the sibling address record TTL is derived from the target address records' original TTL, the end-to-end TTL will be nearing twice the target address record TTL.</p>
<h1 id="rfc.appendix.C.3">
<a href="#rfc.appendix.C.3">C.3.</a> <a href="#aname-chains" id="aname-chains">ANAME chains</a>
</h1>
<p id="rfc.section.C.3.p.1">ANAME sibling address record substitution is made slightly more complicated by the requirement to follow chains of ANAME and/or CNAME records. The TTL of the substituted address records is the minimum of TTLs of the ANAME, all the intermediate records, and target records. This stops the end-to-end TTL from being inflated by each ANAME in the chain.</p>
<p id="rfc.section.C.3.p.2">With CNAME records, repeat queries for "cname.example. CNAME target.example." must not be fully answered from cache after its TTL expires, but must instead be sent to name servers authoritative for "cname.example" in case the CNAME has been updated or removed. Similarly, an ANAME at "aname.example" means that repeat queries for "aname.example" must not be fully answered from cache after its TTL expire, but must instead be sent to name servers authoritative for aname.example in case the ANAME has been updated or removed.</p>
<h1 id="rfc.appendix.C.4">
<a href="#rfc.appendix.C.4">C.4.</a> <a href="#aname-substitution-inside-the-name-server" id="aname-substitution-inside-the-name-server">ANAME substitution inside the name server</a>
</h1>
<p id="rfc.section.C.4.p.1">When ANAME substitution is performed inside the authoritative name server (as described in #alternatives) or in the resolver (as described in #resolver) the end-to-end TTL will actually be just the target address record TTL.</p>
<p id="rfc.section.C.4.p.2">An authoritative server that has control over its resolver can use a cached target address RRset and decremented TTL in the response to the client rather than using the original target address records' TTL. It SHOULD however not use TTLs in the response that are nearing zero to avoid query bunching <a href="#bunching" class="xref">Appendix C.1</a>.</p>
<p id="rfc.section.C.4.p.3">A resolver that performs ANAME substitution is able to get the original TTL from the authoritative name server and use its own cache to store the substituted address records with the appropriate TTL, thereby honoring the TTL of target address records.</p>
<h1 id="rfc.appendix.C.5">
<a href="#rfc.appendix.C.5">C.5.</a> <a href="#ttls-and-zone-transfers" id="ttls-and-zone-transfers">TTLs and zone transfers</a>
</h1>
<p id="rfc.section.C.5.p.1">When things are working properly (with secondary name servers responding to NOTIFY messages promptly) the authoritative servers will follow changes to ANAME target address records according to their TTLs. As a result the end-to-end TTL is unchanged from the previous subsection.</p>
<p id="rfc.section.C.5.p.2">If NOTIFY doesn't work, the TTLs can be stretched by the zone's SOA refresh timer. More serious breakage can stretch them up to the zone expiry time.</p>
<h1 id="rfc.appendix.D">
<a href="#rfc.appendix.D">Appendix D.</a> <a href="#alternatives" id="alternatives">Alternative setups</a>
</h1>
<p id="rfc.section.D.p.1">If you are a large scale DNS provider, ANAME may introduce some operational concerns.</p>
<h1 id="rfc.appendix.D.1">
<a href="#rfc.appendix.D.1">D.1.</a> <a href="#reducing-query-volume" id="reducing-query-volume">Reducing query volume</a>
</h1>
<p id="rfc.section.D.1.p.1">When doing ANAME target lookups, an authoritative server might want to use longer TTLs to reduce query volume, for ANAME values that do not change frequently. This is the same concern a recursive resolver may be exposed to when receiving answers with short TTLs. An authoritative server doing ANAME target lookups therefor could use the same mitigation as a recursive nameserver, that is set a configured minimum TTL usage. This may however contribute to TTL stretching as described in <a href="#ttl" class="xref">Section 4.3</a> so the configured minimum should not be too low.</p>
<h1 id="rfc.appendix.D.2">
<a href="#rfc.appendix.D.2">D.2.</a> <a href="#zone-transfer-scalability" id="zone-transfer-scalability">Zone transfer scalability</a>
</h1>
<p id="rfc.section.D.2.p.1">A frequently changing ANAME target, or a ANAME target that changes its address and is used for many zones, can lead to an increased number of zone transfers. Such DNS architectures may want to consider a zone transfer mechanism outside the DNS.</p>
<p id="rfc.section.D.2.p.2">Another way to deal with zone transfer scalability is to move the ANAME processing (<a href="#subst" class="xref">Section 3</a>) inside the name server daemon. This is not a requirement for ANAME to work, but may be a better solution in large scale implementations. These implementations usually already rely on online DNSSEC signing for similar reasons. If ANAME processing occurs inside the name server daemon, it MUST be done before any DNSSEC online signing happens.</p>
<p id="rfc.section.D.2.p.3">For example, some existing ANAME-like implementations are based on a DNS server architecture, in which a zone's published authoritative servers all perform the duties of a primary master in a distributed manner: provisioning records from a non-DNS back-end store, refreshing DNSSEC signatures, and so forth. They don't use standard standard zone transfers, and already implement their ANAME-like processing inside the name server daemon, substituting ANAME sibling address records on demand.</p>
<h1 id="rfc.appendix.D.3">
<a href="#rfc.appendix.D.3">D.3.</a> <a href="#tailored-responses" id="tailored-responses">Tailored responses</a>
</h1>
<p id="rfc.section.D.3.p.1">Some DNS providers will tailor responses based on information in the client request. Such implementations will use the source IP address or EDNS Client Subnet <a href="#RFC7871" class="xref">[RFC7871]</a> information and use geographical data (GeoIP) or network latency measurements to decide what the best answer is for a given query. Such setups won't work with traditional DNSSEC and provide DNSSEC support usually through online signing. Similar such setups should provide ANAME support through substituting ANAME sibling records on demand.</p>
<p id="rfc.section.D.3.p.2">Also, an authoritative server that uses the client address to tailor the response should obviously not use its own address when looking up ANAME targets, or it could direct clients to a suboptimal server (e.g. a wrong language, or regional restricted content). Instead the authoritative server should look up the ANAME targets on behalf of the client address. It could use for example EDNS Client Subnet for this.</p>
<p id="rfc.section.D.3.p.3">In short, the exact mechanism for obtaining the target address records in such setups is unspecified; typically they will be resolved in the DNS in the usual way, but if an ANAME implementation has special knowledge of the target it can short-cut the substitution process, or it can use clever tricks such as client-dependant answers to make the answer more optimal.</p>
<h1 id="rfc.appendix.E">
<a href="#rfc.appendix.E">Appendix E.</a> <a href="#loops" id="loops">ANAME loops</a>
</h1>
<p id="rfc.section.E.p.1">The ANAME sibling address substitution algorithm in <a href="#subst" class="xref">Section 3</a> poses a challenge of detecting a loop between two or more ANAME records. Imagine this setup: two authoritative servers X and Y performing ANAME sibling address substition on the fly (i.e. they attempt to resolve the ANAME target when the client query arrives). If server X gets a query for FOO.TEST which is an ANAME to BAR.TEST, it will send a query to server Y for BAR.TEST which is an ANAME to FOO.TEST. Server Y will then start a new query to server X, which has no way to know that it is regarding the original FOO.TEST lookup.</p>
<p id="rfc.section.E.p.2">The only indicator of the presence of the loop in the described setup is the network timeout. Ideally we would recognize the loop explicitly based on the exchanged DNS messages.</p>
<p id="rfc.section.E.p.3">On-the-fly ANAME substitution is allowed and it's just the most obvious scenario where the problem can be demonstrated, but this loop can also be encountered in other situations. The root cause is that when the server gets a query it doesn't know why and that the server always attempts to fully resolve the ANAME target before sending the response.</p>
<p id="rfc.section.E.p.4">TODO: Solve this issue [<a href="https://github.com/each/draft-aname/issues/45">https://github.com/each/draft-aname/issues/45</a>]</p>
<h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Tony Finch</span>
<span class="n hidden">
<span class="family-name">Finch</span>
</span>
</span>
<span class="org vcardline">University of Cambridge</span>
<span class="adr">
<span class="vcardline">University Information Services</span>
<span class="vcardline">Roger Needham Building</span>
<span class="vcardline">7 JJ Thomson Avenue</span>
<span class="vcardline">
<span class="locality">Cambridge</span>,
<span class="region"></span>
<span class="code">CB3 0RB</span>
</span>
<span class="country-name vcardline">England</span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>