7
INTERNET-DRAFT D. Senie
8
Category: BCP Amaranth Networks Inc.
9
Expires in six months July 2005
11
Encouraging the use of DNS IN-ADDR Mapping
12
draft-ietf-dnsop-inaddr-required-07.txt
16
By submitting this Internet-Draft, each author represents that any
17
applicable patent or other IPR claims of which he or she is aware
18
have been or will be disclosed, and any of which he or she becomes
19
aware will be disclosed, in accordance with Section 6 of BCP 79.
21
Internet-Drafts are working documents of the Internet Engineering
22
Task Force (IETF), its areas, and its working groups. Note that
23
other groups may also distribute working documents as Internet-
26
Internet-Drafts are draft documents valid for a maximum of six months
27
and may be updated, replaced, or obsoleted by other documents at any
28
time. It is inappropriate to use Internet-Drafts as reference
29
material or to cite them other than as "work in progress."
31
The list of current Internet-Drafts can be accessed at
32
http://www.ietf.org/ietf/1id-abstracts.txt
34
The list of Internet-Draft Shadow Directories can be accessed at
35
http://www.ietf.org/shadow.html
39
Mapping of addresses to names has been a feature of DNS. Many sites,
40
implement it, many others don't. Some applications attempt to use it
41
as a part of a security strategy. The goal of this document is to
42
encourage proper deployment of address to name mappings, and provide
43
guidance for their use.
47
Copyright (C) The Internet Society. (2005)
51
The Domain Name Service has provision for providing mapping of IP
52
addresses to host names. It is common practice to ensure both name to
53
address, and address to name mappings are provided for networks. This
54
practice, while documented, has never been required, though it is
55
generally encouraged. This document both encourages the presence of
61
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
64
these mappings and discourages reliance on such mappings for security
67
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
68
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
69
document are to be interpreted as described in RFC 2119 [RFC2119].
74
From the early days of the Domain Name Service [RFC883] a special
75
domain has been set aside for resolving mappings of IP addresses to
76
domain names. This was refined in [RFC1035], describing the .IN-
77
ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA
78
was added [RFC3152]. This document uses IPv4 CIDR block sizes and
79
allocation strategy where there are differences and uses IPv4
80
terminology. Aside from these differences, this document can and
81
should be applied to both address spaces.
83
The assignment of blocks of IP address space was delegated to three
84
regional registries. Guidelines for the registries are specified in
85
[RFC2050], which requires regional registries to maintain IN-ADDR
86
records on the large blocks of space issued to ISPs and others.
88
ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
89
allocations. For smaller allocations, ARIN can provide IN-ADDR for
90
/24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
91
update IN-ADDR, however the present version of its policy document
92
for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
93
copies of this document. As of this writing, it appears APNIC has no
94
actual policy on IN-ADDR. RIPE appears to have the strongest policy
95
in this area [RIPE302] indicating Local Internet Registries should
96
provide IN-ADDR services, and delegate those as appropriate when
97
address blocks are delegated.
99
As we can see, the regional registries have their own policies for
100
recommendations and/or requirements for IN-ADDR maintenance. It
101
should be noted, however, that many address blocks were allocated
102
before the creation of the regional registries, and thus it is
103
unclear whether any of the policies of the registries are binding on
104
those who hold blocks from that era.
106
Registries allocate address blocks on CIDR [RFC1519] boundaries.
107
Unfortunately the IN-ADDR zones are based on classful allocations.
108
Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
109
exist, but are not always implemented.
111
3. Examples of impact of missing IN-ADDR
117
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
120
These are some examples of problems that may be introduced by
123
Some applications use DNS lookups for security checks. To ensure
124
validity of claimed names, some applications will look up IN-ADDR
125
records to get names, and then look up the resultant name to see if
126
it maps back to the address originally known. Failure to resolve
127
matching names is seen as a potential security concern.
129
Some FTP sites will flat-out reject users, even for anonymous FTP, if
130
the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
131
itself resolved, does not match. Some Telnet servers also implement
134
Web sites are in some cases using IN-ADDR checks to verify whether
135
the client is located within a certain geopolitical entity. This
136
approach has been employed for downloads of crypto software, for
137
example, where export of that software is prohibited to some locales.
138
Credit card anti-fraud systems also use these methods for geographic
141
The popular TCP Wrappers program found on most Unix and Linux systems
142
has options to enforce IN-ADDR checks and to reject any client that
143
does not resolve. This program also has a way to check to see that
144
the name given by a PTR record then resolves back to the same IP
145
address. This method provdes more comfort but no appreciable
148
Some anti-spam (anti junk email) systems use IN-ADDR to verify the
149
presence of a PTR record, or validate the PTR value points back to
152
Many web servers look up the IN-ADDR of visitors to be used in log
153
analysis. This adds to the server load, but in the case of IN-ADDR
154
unavailability, it can lead to delayed responses for users.
156
Traceroutes with descriptive IN-ADDR naming proves useful when
157
debugging problems spanning large areas. When this information is
158
missing, the traceroutes take longer, and it takes additional steps
159
to determine that network is the cause of problems.
161
Wider-scale implementation of IN-ADDR on dialup, wireless access and
162
other such client-oriented portions of the Internet would result in
163
lower latency for queries (due to lack of negative caching), and
164
lower name server load and DNS traffic.
173
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
176
4.1 Delegation Recommendations
179
Regional Registries and any Local Registries to whom they delegate
180
should establish and convey a policy to those to whom they delegate
181
blocks that IN-ADDR mappings are recommended. Policies should
182
recommend those receiving delegations to provide IN-ADDR service
183
and/or delegate to downstream customers.
185
Network operators should define and implement policies and procedures
186
which delegate IN-ADDR to their clients who wish to run their own IN-
187
ADDR DNS services, and provide IN-ADDR services for those who do not
188
have the resources to do it themselves. Delegation mechanisms should
189
permit the downstream customer to implement and comply with IETF
190
recommendations application of IN-ADDR to CIDR [RFC2317].
192
All IP address space assigned and in use should be resolved by IN-
193
ADDR records. All PTR records must use canonical names.
195
All IP addresses in use within a block should have an IN-ADDR
196
mapping. Those addresses not in use, and those that are not valid for
197
use (zeros or ones broadcast addresses within a CIDR block) need not
200
It should be noted that due to CIDR, many addresses that appear to be
201
otherwise valid host addresses may actually be zeroes or ones
202
broadcast addresses. As such, attempting to audit a site's degree of
203
compliance may only be done with knowledge of the internal subnet
204
architecture of the site. It can be assumed, however, any host that
205
originates an IP packet necessarily will have a valid host address,
206
and must therefore have an IN-ADDR mapping.
208
4.2 Application Recommendations
211
Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
212
of IN-ADDR, sometimes in conjunction with a lookup of the name
213
resulting from the PTR record provides no real security, can lead to
214
erroneous results and generally just increases load on DNS servers.
215
Further, in cases where address block holders fail to properly
216
configure IN-ADDR, users of those blocks are penalized.
218
5. Security Considerations
220
This document has no negative impact on security. While it could be
221
argued that lack of PTR record capabilities provides a degree of
222
anonymity, this is really not valid. Trace routes, whois lookups and
223
other sources will still provide methods for discovering identity.
229
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
232
By recommending applications avoid using IN-ADDR as a security
233
mechanism this document points out that this practice, despite its
234
use by many applications, is an ineffective form of security.
235
Applications should use better mechanisms of authentication.
237
6. IANA Considerations
239
There are no IANA considerations for this document.
243
7.1 Normative References
245
[RFC883] P.V. Mockapetris, "Domain names: Implementation
246
specification," RFC883, November 1983.
248
[RFC1035] P.V. Mockapetris, "Domain Names: Implementation
249
Specification," RFC 1035, November 1987.
251
[RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
252
an Address Assignment and Aggregation Strategy," RFC 1519, September
255
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
256
RFC 2026, BCP 9, October 1996.
258
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
259
Requirement Levels", RFC 2119, BCP 14, March 1997.
261
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
262
Guidelines", RFC2050, BCP 12, Novebmer 1996.
264
[RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
265
RFC 2317, March 1998.
267
[RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
270
7.2 Informative References
272
[ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
273
unknown, http://www.arin.net/regserv/initial-isp.html
275
[APNIC] "Policies For IPv4 Address Space Management in the Asia
276
Pacific Region," APNIC-086, 13 January 2003.
278
[RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
279
Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
285
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
288
2004. http://www.ripe.net//ripe/docs/rev-del.html
294
Thanks to Peter Koch and Gary Miller for their input, and to many
295
people who encouraged me to write this document.
300
Amaranth Networks Inc.
304
Phone: (978) 779-5100
308
10. Full Copyright Statement
310
Copyright (C) The Internet Society (2005).
312
This document is subject to the rights, licenses and restrictions
313
contained in BCP 78, and except as set forth therein, the authors
314
retain all their rights.
316
This document and the information contained herein are provided
317
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
318
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
319
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
320
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
321
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
322
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
325
Intellectual Property
327
The IETF takes no position regarding the validity or scope of any
328
Intellectual Property Rights or other rights that might be claimed
329
to pertain to the implementation or use of the technology
330
described in this document or the extent to which any license
331
under such rights might or might not be available; nor does it
332
represent that it has made any independent effort to identify any
333
such rights. Information on the procedures with respect to
334
rights in RFC documents can be found in BCP 78 and BCP 79.
341
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
344
Copies of IPR disclosures made to the IETF Secretariat and any
345
assurances of licenses to be made available, or the result of an
346
attempt made to obtain a general license or permission for the use
347
of such proprietary rights by implementers or users of this
348
specification can be obtained from the IETF on-line IPR repository
349
at http://www.ietf.org/ipr.
351
The IETF invites any interested party to bring to its attention
352
any copyrights, patents or patent applications, or other
353
proprietary rights that may cover technology that may be required
354
to implement this standard. Please address the information to the
355
IETF at ietf-ipr@ietf.org.
357
Internet-Drafts are working documents of the
358
Internet Engineering Task Force (IETF), its areas, and its
359
working groups. Note that other groups may also distribute
360
working documents as Internet-Drafts.
362
Internet-Drafts are draft documents valid for a maximum of
363
six months and may be updated, replaced, or obsoleted by
364
other documents at any time. It is inappropriate to use
365
Internet-Drafts as reference material or to cite them other
366
than as "work in progress."
368
The list of current Internet-Drafts can be accessed at
369
http://www.ietf.org/1id-abstracts.html
371
The list of Internet-Draft Shadow Directories can be
372
accessed at http://www.ietf.org/shadow.html
376
Funding for the RFC Editor function is currently provided by the
added
removed
doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
