-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-dickson-dnsop-glueless-00.xml
180 lines (157 loc) · 9.97 KB
/
draft-dickson-dnsop-glueless-00.xml
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
<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-dickson-dnsop-glueless-00" submissionType="IETF" category="info" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" indexInclude="false" consensus="true">
<front>
<title abbrev="Glueless DNS">Operating a Glueless DNS Authority Server</title><seriesInfo value="draft-dickson-dnsop-glueless-00" stream="IETF" status="informational" name="Internet-Draft"></seriesInfo>
<author initials="B." surname="Dickson" fullname="Brian Dickson"><organization>GoDaddy</organization><address><postal><street></street>
</postal><email>[email protected]</email>
</address></author><date/>
<area>Internet</area>
<workgroup></workgroup>
<abstract>
<t>This Internet Draft proposes a Best Current Practice for protecting authority servers against MITM and poisoning attacks, using a domain naming strategy to not require glue A/AAAA records and use of DNSSEC.</t>
<t>This BCP assumes the use of validating resolvers, which should already be a BCP itself.</t>
<t>MITM and poisoning attacks should only be effective/possible against unsigned domains.</t>
<t>However, until all domains are signed, this guidance is relevant, in that it can limit the attack surface of unsigned domains.</t>
<t>This guidance should be combined with <xref target="I-D.dickson-dnsop-ds-hack"></xref></t>
</abstract>
</front>
<middle>
<section anchor="introduction"><name>Introduction</name>
<t>DNS Security extensions (DNSSEC) are additions to the DNS protocol which provide data integrity and authenticity protections, but do not provide privacy.</t>
</section>
<section anchor="conventions-and-definitions"><name>Conventions and Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref>
when, and only when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="background"><name>Background</name>
<t>Use of DNSSEC requires upgrades to software for authorative servers, resolvers, and optionally clients, in order to benefit from these protections. It also requires that DNS operators actually sign their zones.</t>
<t>When a given zone is unsigned, those protections to the zone contents are not available.</t>
<t>Any unsigned zone is trivially able to be altered by an on-path attacker.</t>
<t>An off-path attacker is limited to use of cache poisoning attacks.</t>
<t>However, some class of cache poisoning attacks target unsigned delegation data. These records consist of the necessary NS records, and when necessary, "glue" records for IP address corresponding to these NS records.</t>
<t>The impact to successful cache poisoning of delegation records is that the attacker may substitute their own name servers for the legitimate name server. In other words, the attacker is able to promote itself to being effectively on-path, and trivially modify unsigned domain results.</t>
</section>
<section anchor="proposed-solutions"><name>Proposed Solutions</name>
<t>There are two delegation record types that require protection against off-path attackers, for unsigned domains.</t>
<t>For protecting NS records used in delegations, there is a new proposal for use of a new DS record. See <xref target="I-D.dickson-dnsop-ds-hack"></xref> for details.</t>
<t>The present draft addresses the "glue" records, by recommending methods to make them unnecessary. If there is no delegation glue data, an attacker cannot poison that data. The resolver cache would contain only authoritative data, which cannot be pre-empted by such poisoning attacks.</t>
</section>
<section anchor="recommendations"><name>Recommendations</name>
<t>The following practice is RECOMMENDED for unsigned zones:</t>
<ul>
<li>Do not use in-bailiwick name server names for unsigned zones.</li>
<li>Use out-of-zone names for the name servers for unsigned zones</li>
</ul>
<t>Example:</t>
<artwork>Do NOT do the following (delegations requiring glue):
unsigned-zone.example NS ns1.unsigned-zone.example
unsigned-zone.example NS ns2.unsigned-zone.example
// glue
ns1.unsigned-zone.example A (IP address)
ns1.unsigned-zone.example AAAA (IP address)
ns2.unsigned-zone.example A (IP address)
ns2.unsigned-zone.example AAAA (IP address)
Instead, do the following (glueless delegations):
unsigned-zone.example NS ns1.nameserver-signed-zone.example
unsigned-zone.example NS ns2.nameserver-signed-zone.example
//
// Delegation to signed zone containing name server names
nameserver-signed-zone.example NS ns1.nameserver-signed-zone.example
nameserver-signed-zone.example NS ns2.nameserver-signed-zone.example
nameserver-signed-zone.example DS (DS record data)
// glue records for this delegation
ns1.nameserver-signed-zone.example A (IP address)
ns1.nameserver-signed-zone.example A (IP address)
ns2.nameserver-signed-zone.example AAAA (IP address)
ns2.nameserver-signed-zone.example AAAA (IP address)
</artwork>
<t>The following practice is RECOMMENDED (for signed name server name zones, i.e. large operators' zones):</t>
<ul>
<li>For name server name zones (zones containing data for name servers), use dedicated name server names for the zone itself</li>
<li>Consider use of another zone for the dedicated name server names, to make the name server name zone itself fully glueless</li>
<li>For this additional zone, also consider using a different name server <em>name</em> for its delegation's exclusive use</li>
<li>Decoupling the respective NS names, ensures changes and updates to the zone that uses glue, don't affect any other zones</li>
<li>Depending on parent zone policy (e.g. TLD database policy), renaming or renumbering name servers may affect delegations using them (NS entries)</li>
<li>A single zone with non-reused NS names guarantees side effects of this sort are not possible</li>
<li>Additional lookups are required on the initial reference to any NS in the main glueless zone</li>
<li>Subsequent (new) queries for the IP addresses of glueless name servers only require single queries</li>
</ul>
<t>Example:</t>
<artwork>Entries in the example TLD
//
// Same unsigned zone uses the same name servers
// However, the name server is in its own glueless zone
unsigned-zone.example NS ns1.nameserver-signed-zone.example
unsigned-zone.example NS ns2.nameserver-signed-zone.example
//
nameserver-signed-zone.example NS ns1.separate-zone.example
nameserver-signed-zone.example NS ns2.separate-zone.example
nameserver-signed-zone.example DS (DS record data)
//
separate-zone.example NS special-ns1.separate-zone.example
separate-zone.example NS special-ns2.separate-zone.example
separate-zone.example DS (DS record data)
// glue for special-ns1 and -2
// special-ns1 and -2 are used only for/by separate-zone
special-ns1.separate-zone.example A (IP address)
special-ns1.separate-zone.example AAAA (IP address)
special-ns2.separate-zone.example A (IP address)
special-ns2.separate-zone.example AAAA (IP address)
Zone file for nameserver-signed-zone:
nameserver-signed-zone.example SOA (soa record data)
// glueless NS are used
nameserver-signed-zone.example NS ns1.separate-zone.example
nameserver-signed-zone.example NS ns2.separate-zone.example
// actual glueless address records for "real" name server names
ns1.nameserver-signed-zone.example A (IP address)
ns1.nameserver-signed-zone.example AAAA (IP address)
ns2.nameserver-signed-zone.example A (IP address)
ns2.nameserver-signed-zone.example AAAA (IP address)
// etc etc etc
Zone file for separate-zone:
separate-zone.example SOA (soa record data)
// This is the only non-glueless NS in use
// NB: matches glue in parent
separate-zone.example NS special-ns1.separate-zone.example
separate-zone.example NS special-ns2.separate-zone.example
special-ns1.separate-zone.example A (IP address)
special-ns1.separate-zone.example AAAA (IP address)
special-ns2.separate-zone.example A (IP address)
special-ns2.separate-zone.example AAAA (IP address)
// actual address records for "real" name server name
// (only used by nameserver-signed-zone)
ns1.separate-zone.example A (IP address)
ns1.separate-zone.example AAAA (IP address)
ns2.separate-zone.example A (IP address)
ns2.separate-zone.example AAAA (IP address)
</artwork>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>This guidance is not a substitute for use of DNSSEC for DNS domains.</t>
<t>This guidance is useful in preventing off-path attackers from poisoning DNS cache entries necessary for delegations.</t>
<t>However, an on-path attacker is still able to manipulate DNS responses sent over UDP or unencrypted TCP.</t>
<t>Use of an encrypted transport is one potential method of preventing MITM attacks (i.e. DNS over TLS from resolver to authoritative server, aka ADoT), but this is still less secure than use of DNSSEC.</t>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references><name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.dickson-dnsop-ds-hack.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
</references>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>Thanks to everyone who helped create the tools that let everyone use Markdown to create
Internet Drafts, and the RFC Editor for xml2rfc.</t>
<t>Thanks to Dan York for his Tutorial on using Markdown (specifically mmark) for writing IETF drafts.</t>
<t>Thanks to YOUR NAME HERE for contributions, reviews, etc.</t>
</section>
</back>
</rfc>