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
|
<pre>Independent Submission W. Kumari
Request for Comments: 7304 Google
Category: Informational July 2014
ISSN: 2070-1721
<span class="h1">A Method for Mitigating Namespace Collisions</span>
Abstract
This document outlines a possible, but not recommended, method to
mitigate the effect of collisions in the DNS namespace by providing a
means for end users to disambiguate the conflict.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7304">http://www.rfc-editor.org/info/rfc7304</a>.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.
<span class="grey">Kumari Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7304">RFC 7304</a> DNS Collision Mitigation July 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction/Background . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Mitigation . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3">3</a>. Implementation/Disclaimers . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-5">5</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction/Background</span>
Collisions in the DNS occur in multiple ways. One common case is
that an organization has used a subdomain (foo) of its primary domain
(example.com) for corporate infrastructure, and then the string 'foo'
is delegated as a Top-Level Domain (TLD). When an employee of the
organization enters 'www.foo', is the goal to reach a machine in the
internal namespace (www.foo.example.com) or the hostname 'www' in the
'foo' TLD?
This document describes a means of disambiguating this and similar
cases.
Implementation of this method is not recommended; it is documented
here to explain some of the pitfalls with such an approach.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Mitigation</span>
The mitigation described in this document involves presenting
multiple options to the user and allowing them to indicate which of
the names is the one they are trying to reach.
The mitigation would look up the name in multiple namespaces. If a
conflict is detected, it would then provide a means for the user to
indicate which one of the colliding names they wish to connect to,
and return the disambiguated answer to the application. An
additional feature of mitigation could be to cache the user's choice
and/or provide a means to set priorities.
This could be accomplished in a number of ways, including:
o Intercepting the resolution requests from the application in a
"shim" type library
o Replacing the resolver library entirely
o Integrating this type of mitigation into applications (some web
browsers already do something similar to this)
<span class="grey">Kumari Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7304">RFC 7304</a> DNS Collision Mitigation July 2014</span>
o Proxying the request to a server that provides an interstitial
page that allows the user to indicate the intended name (for
applications such as HTTP)
There are a number of issues with this solution, including but not
limited to:
o There may not be a human available to disambiguate the answer
(unattended machines, mail servers, etc.).
o The human/user may have no idea which is the correct choice,
especially in the case of a phishing attack or other malicious
intent.
o The additional latency introduced may cause the originating
application to time out.
o The experience would be time consuming for users as they must
select each site and subsite intended (e.g., www.intranet,
images.intranet, etc.).
o Caching the responses could lead to problems when the user changes
location (internal sites would fail when offsite or otherwise lead
to incorrect sites being loaded).
For these and other reasons, implementation of this technique is not
recommended.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Implementation/Disclaimers</span>
This document does not reference an implementation. Due to the
numerous issues described above, we do not recommend that this
solution be implemented. This is a very slight mitigation, and we do
not recommend that it be viewed as a solution to the namespace
collision problem.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
While this method may make some users more aware of which version of
a name they are going to use (and so careful users may avoid some
phishing attacks), the security risks described above outweigh this
potential benefit.
There are numerous security implications in this approach, including
leaking internal names (e.g., secret-project.corp.example.com), users
being tricked into selecting the incorrect choice when trying to
disambiguate answers, etc.
<span class="grey">Kumari Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7304">RFC 7304</a> DNS Collision Mitigation July 2014</span>
For these reasons, it is not recommended that this solution be
deployed.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgements</span>
The author wishes to thank the following individuals: Fred Baker, Bob
Braden, Carsten Bormann, Nevil Brownlee, Eric Burger, Brian
Carpenter, Benoit Claise, Keith Drage, Martin J. Duerst, David
Harrington, Paul Hoffamn, John Levine, and Ted Lemon.
Author's Address
Warren Kumari
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
EMail: warren@kumari.net
Kumari Informational [Page 4]
</pre>
|
