1 Internet Engineering Task Force (IETF) L. Howard
2 Request for Comments: 8501 Retevia
3 Category: Informational November 2018
4 ISSN: 2070-1721
5
6
7 Reverse DNS in IPv6 for Internet Service Providers
8
9 Abstract
10
11 In IPv4, Internet Service Providers (ISPs) commonly provide
12 IN-ADDR.ARPA information for their customers by prepopulating the
13 zone with one PTR record for every available address. This practice
14 does not scale in IPv6. This document analyzes different approaches
15 and considerations for ISPs in managing the IP6.ARPA zone.
16
17 Status of This Memo
18
19 This document is not an Internet Standards Track specification; it is
20 published for informational purposes.
21
22 This document is a product of the Internet Engineering Task Force
23 (IETF). It represents the consensus of the IETF community. It has
24 received public review and has been approved for publication by the
25 Internet Engineering Steering Group (IESG). Not all documents
26 approved by the IESG are candidates for any level of Internet
27 Standard; see Section 2 of RFC 7841.
28
29 Information about the current status of this document, any errata,
30 and how to provide feedback on it may be obtained at
31 https://www.rfc-editor.org/info/rfc8501.
32
33 Copyright Notice
34
35 Copyright (c) 2018 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
37
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (https://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document. Code Components extracted from this document must
44 include Simplified BSD License text as described in Section 4.e of
45 the Trust Legal Provisions and are provided without warranty as
46 described in the Simplified BSD License.
47
48
49
50
51
52 Howard Informational [Page 1]
53 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3
60 1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 4
61 2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4
62 2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4
63 2.2. Wildcard Match . . . . . . . . . . . . . . . . . . . . . 5
64 2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5
65 2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6
66 2.3.2. Dynamic DNS through Residential Gateways . . . . . . 7
67 2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7
68 2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8
69 2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8
70 2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8
71 2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 9
72 2.5. Dynamically Generate PTR When Queried ("On the Fly") . . 9
73 3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 10
74 4. Considerations and Recommendations . . . . . . . . . . . . . 10
75 5. Security and Privacy Considerations . . . . . . . . . . . . . 11
76 5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11
77 5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11
78 5.3. Considerations for Other Uses of the DNS . . . . . . . . 12
79 5.4. Privacy Considerations . . . . . . . . . . . . . . . . . 12
80 5.5. User Creativity . . . . . . . . . . . . . . . . . . . . . 12
81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
83 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
84 7.2. Informative References . . . . . . . . . . . . . . . . . 14
85 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
87
88 1. Introduction
89
90 [RFC1912] recommended that "every Internet-reachable host should have
91 a name" and says "Failure to have matching PTR and A records can
92 cause loss of Internet services similar to not being registered in
93 the DNS at all". While the need for a PTR record and for it to match
94 is debatable as a best practice, some network services (see
95 Section 4) still do rely on PTR lookups, and some check the source
96 address of incoming connections and verify that the PTR and A records
97 match before providing service.
98
99 Individual Internet users on the residential or consumer scale,
100 including small and home businesses, are constantly connecting to or
101 moving around the Internet. For large ISPs who serve residential
102 users, maintenance of individual PTR records is impractical.
103
104
105
106
107 Howard Informational [Page 2]
108 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
109
110
111 Administrators at ISPs should consider whether customer PTR records
112 are needed, and if so, evaluate methods for responding to reverse DNS
113 queries in IPv6.
114
115 1.1. Reverse DNS in IPv4
116
117 ISPs that provide access to many residential users typically assign
118 one or a few IPv4 addresses to each of those users and populate an
119 IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some
120 ISPs also configure forward zones with matching A records so that
121 lookups match. For instance, if an ISP Example.com aggregated
122 192.0.2.0/24 at a network hub in one region, the reverse zone might
123 look like:
124
125 1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com.
126
127 2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com.
128
129 3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com.
130
131 .
132
133 .
134
135 .
136
137 254.2.0.192.IN-ADDR.ARPA. IN PTR 254.string.region.example.com.
138
139 The conscientious Example.com might then also have a zone:
140
141 1.string.region.example.com. IN A 192.0.2.1
142
143 2.string.region.example.com. IN A 192.0.2.2
144
145 3.string.region.example.com. IN A 192.0.2.3
146
147 .
148
149 .
150
151 .
152
153 254.string.region.example.com. IN A 192.0.2.254
154
155 Many ISPs generate PTR records for all IP addresses used for
156 customers, and many create the matching A record.
157
158
159
160
161
162 Howard Informational [Page 3]
163 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
164
165
166 1.2. Reverse DNS Considerations in IPv6
167
168 A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be:
169
170 a.9.8.7.6.5.e.f.f.f.4.3.2.1.0.0.0.0.0.0.0.0.f.0.8.b.d.0.1.0.0.2
171 .IP6.ARPA. IN PTR 1.string.region.example.com.
172
173 ISPs will often delegate an IPv6 prefix to their customers. Since
174 2^^80 possible addresses could be configured in a single /48 zone
175 alone, it is impractical to write a zone with every possible address
176 entered, even with automation. If 1000 entries could be written per
177 second, the zone would still not be complete after 38 trillion years.
178
179 Furthermore, it is often impossible to associate hostnames and
180 addresses, since the 64 bits in the Interface Identifier portion of
181 the address are frequently assigned using Stateless Address
182 Autoconfiguration (SLAAC) [RFC4862] when the host comes online, and
183 they may be short-lived.
184
185 [RFC1912] is an Informational RFC that says "PTR records must point
186 back to a valid A record" and further that the administrator should
187 "Make sure your PTR and A records match." Herein are considerations
188 for how to follow this advice for AAAA and PTR records.
189
190 2. Alternatives in IPv6
191
192 Several options exist for providing reverse DNS in IPv6. All of
193 these options also exist for IPv4, but the scaling problem is much
194 less severe in IPv4. Each option should be evaluated for its scaling
195 ability, compliance with existing standards and best practices, and
196 availability in common systems.
197
198 2.1. Negative Response
199
200 Some ISP DNS administrators may choose to provide only an NXDOMAIN
201 response to PTR queries for subscriber addresses. In some ways, this
202 is the most accurate response, since no name information is known
203 about the host. However, providing a negative response to PTR
204 queries does not satisfy the expectation in [RFC1912] for entries to
205 match. Users of services that are dependent on a successful lookup
206 will have a poor experience. For instance, some web services and
207 Secure Shell (SSH) connections wait for a DNS response, even
208 NXDOMAIN, before responding. For the best user experience, then, it
209 is important to return a response, rather than time out with no
210 answer. On the other hand, external mail servers are likely to
211 reject connections, which might be an advantage in fighting spam.
212
213
214
215
216
217 Howard Informational [Page 4]
218 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
219
220
221 When evaluating this option, DNS administrators should consider the
222 uses for reverse DNS records and the number of services affecting the
223 number of users.
224
225 2.2. Wildcard Match
226
227 The use of wildcards in the DNS is described in [RFC4592], and their
228 use in IPv6 reverse DNS is described in [RFC4472].
229
230 While recording all possible addresses is not scalable, it may be
231 possible to record a wildcard entry for each prefix assigned to a
232 customer. Consider also that "inclusion of wildcard NS RRSets in a
233 zone is discouraged, but not barred". [RFC4592]
234
235 This solution generally scales well. However, since the response
236 will match any address in the wildcard range (/48, /56, /64, etc.), a
237 forward DNS lookup on the response given will not be able to return
238 the same hostname. This method therefore fails the expectation in
239 [RFC1912] that forward and reverse will match. DNSSEC [RFC4035]
240 scalability is limited to signing the wildcard zone, which may be
241 satisfactory.
242
243 2.3. Dynamic DNS
244
245 One way to ensure that forward and reverse records match is for hosts
246 to update DNS servers dynamically once interface configuration is
247 complete (whether by SLAAC, DHCPv6, or other means), as described in
248 [RFC4472]. Hosts would need to provide both AAAA and PTR updates and
249 would need to know which servers would accept the information.
250
251 This option should scale as well or as poorly as IPv4 dynamic DNS
252 (DDNS) does. Dynamic DNS may not scale effectively in large ISP
253 networks that have no single master name server, but a single master
254 server is not best practice. The ISP's DNS system may provide a
255 point for Denial-of-Service attacks, including many attempted DDNS
256 updates. Accepting updates only from authenticated sources may
257 mitigate this risk, but only if authentication itself does not
258 require excessive overhead. No authentication of dynamic DNS updates
259 is inherently provided. Implementers should therefore consider use
260 of TSIG [RFC2845], or at least ingress filtering, so that updates are
261 only accepted from customer address space from internal network
262 interfaces. They should also rate limit the number of updates from a
263 customer per second and consider impacts on scalability. UDP is
264 allowed per [RFC2136], so connection reliability is not assured,
265 though the host should expect an ERROR or NOERROR message from the
266 server; TCP provides transmission control, but the updating host
267 would need to be configured to use TCP.
268
269
270
271
272 Howard Informational [Page 5]
273 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
274
275
276 Administrators may want to consider user creativity if they provide
277 hostnames, as described in Section 5.5, "User Creativity".
278
279 There is no assurance of uniqueness if multiple hosts try to update
280 with the same name ("mycomputer.familyname.org"). There is no
281 standard way to indicate to a host what server it should send DDNS
282 updates to; the master listed in the SOA is often assumed to be a
283 DDNS server, but this may not scale.
284
285 2.3.1. Dynamic DNS from Individual Hosts
286
287 In the simplest case, a residential user will have a single host
288 connected to the ISP. Since the typical residential user cannot
289 configure IPv6 addresses or resolving name servers on their hosts,
290 the ISP should provide address information conventionally -- i.e.,
291 using their normal combination of Router Advertisements (RAs), DHCP,
292 etc. The ISP should also provide a DNS Recursive Name Server and
293 Domain Search List as described in [RFC3646] or [RFC8106]. In
294 determining its Fully Qualified Domain Name (FQDN), a host will
295 typically use a domain from the Domain Search List. This is an
296 overloading of the parameter; multiple domains could be listed, since
297 hosts may need to search for unqualified names in multiple domains
298 without necessarily being a member of those domains. Administrators
299 should consider whether the Domain Search List actually provides an
300 appropriate DNS suffix(es) when considering use of this option. For
301 the purposes of dynamic DNS, the host would concatenate its local
302 hostname (e.g., "hostname") plus the domain(s) in the Domain Search
303 List (e.g., "customer.example.com"), as in
304 "hostname.customer.example.com".
305
306 Once it learns its address and has a resolving name server, the host
307 must perform an SOA lookup on the IP6.ARPA record to be added in
308 order to find the owner and eventually the server that is
309 authoritative for the zone (which might accept dynamic updates).
310 Several recursive lookups may be required to find the longest prefix
311 that has been delegated. The DNS administrator must designate the
312 Primary Master Server for the longest match required. Once found,
313 the host sends dynamic AAAA and PTR updates using the concatenation
314 defined above ("hostname.customer.example.com").
315
316 In order to use this alternative, hosts must be configured to use
317 dynamic DNS. This is not default behavior for many hosts, which is
318 an inhibitor for a large ISP. This option may be scalable, although
319 registration following an outage may cause significant load, and
320 hosts using privacy extensions [RFC4941] may update records daily.
321 It is up to the host to provide matching forward and reverse records
322 and update them when the address changes.
323
324
325
326
327 Howard Informational [Page 6]
328 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
329
330
331 2.3.2. Dynamic DNS through Residential Gateways
332
333 Residential customers may have a gateway, which may provide DHCPv6
334 service to hosts from a delegated prefix. ISPs should provide a DNS
335 Recursive Name Server and Domain Search List to the gateway, as
336 described above and in [RFC3646] and [RFC8106]. There are two
337 options for how the gateway uses this information. The first option
338 is for the gateway to respond to DHCPv6 requests with the same DNS
339 Recursive Name Server and Domain Search List provided by the ISP.
340 The alternate option is for the gateway to relay dynamic DNS updates
341 from hosts to the servers and domain provided by the ISP. Host
342 behavior is unchanged; the host sends the same dynamic updates,
343 either to the ISP's server (as provided by the gateway) or to the
344 gateway for it to forward. The gateway would need to be capable of
345 and configured to use dynamic DNS.
346
347 2.3.3. Automatic DNS Delegations
348
349 An ISP may delegate authority for a subdomain, such as
350 "customer12345.town.AW.customer.example.com" or
351 "customer12345.example.com", to the customer's gateway. Each domain
352 thus delegated must be unique within the DNS. The ISP may also then
353 delegate the IP6.ARPA zone for the prefix delegated to the customer,
354 as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA".
355 Then, the customer could provide updates to their own gateway, with
356 forward and reverse. However, individual hosts connected directly to
357 the ISP rarely have the capability to run DNS for themselves;
358 therefore, an ISP can only delegate to customers with gateways
359 capable of being authoritative name servers. If a device requests a
360 DHCPv6 Prefix Delegation, that may be considered a reasonably
361 reliable indicator that it is a gateway, rather than an individual
362 host. It is not necessarily an indicator that the gateway is capable
363 of providing DNS services and therefore cannot be relied upon as a
364 way to test whether this option is feasible. In fact, this kind of
365 delegation will not work for devices complying with [RFC6092], which
366 includes the requirement, "By DEFAULT, inbound DNS queries received
367 on exterior interfaces MUST NOT be processed by any integrated DNS
368 resolving server".
369
370 If the customer's gateway is the name server, it provides its own
371 information to hosts on the network, as described in [RFC2136], which
372 is often done for enterprise networks.
373
374 An ISP could provide authoritative responses as a secondary server to
375 the customer's master server. For instance, the home gateway name
376 server could be the master server, with the ISP providing the only
377 published NS authoritative servers.
378
379
380
381
382 Howard Informational [Page 7]
383 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
384
385
386 To implement this alternative, users' residential gateways must be
387 capable of acting as authoritative name servers capable of dynamic
388 DNS updates. There is no mechanism for an ISP to dynamically
389 communicate to a user's equipment that a zone has been delegated, so
390 user action would be required. Most users have neither the equipment
391 nor the expertise to run DNS servers, so this option is unavailable
392 to the residential ISP.
393
394 2.3.4. Generate Dynamic Records
395
396 An ISP's name server that receives a dynamic forward or reverse DNS
397 update may create a matching entry. Since a host capable of updating
398 one is generally capable of updating the other, this should not be
399 required, but redundant record creation will ensure that a record
400 exists. ISPs implementing this method should check whether a record
401 already exists before accepting or creating updates.
402
403 This method is also dependent on hosts being capable of providing
404 dynamic DNS updates, which is not default behavior for many hosts.
405
406 2.3.5. Populate from DHCP Server
407
408 An ISP's DHCPv6 server may populate the forward and reverse zones
409 when the DHCP request is received if the request contains enough
410 information [RFC4704].
411
412 However, this method will only work for a single host address
413 (IA_NA); the ISP's DHCP server would not have enough information to
414 update all records for a prefix delegation. If the zone authority is
415 delegated to a home gateway that used this method, the gateway could
416 update records for residential hosts. To implement this alternative,
417 users' residential gateways would have to support the FQDN DHCP
418 option and would have to either have the zones configured or send
419 DDNS messages to the ISP's name server.
420
421 2.3.6. Populate from RADIUS Server
422
423 A user may receive an address or prefix from a RADIUS server
424 [RFC2865], the details of which may be recorded via RADIUS Accounting
425 data [RFC2866]. The ISP may populate the forward and reverse zones
426 from the accounting data if it contains enough information. This
427 solution allows the ISP to populate data concerning allocated
428 prefixes as per Section 2.2 (wildcards) and customer premise
429 equipment (CPE) endpoints. However, as with Section 2.3.5, it does
430 not allow the ISP to populate information concerning individual
431 hosts.
432
433
434
435
436
437 Howard Informational [Page 8]
438 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
439
440
441 2.4. Delegate DNS
442
443 For customers who are able to run their own DNS servers, such as
444 commercial customers, often the best option is to delegate the
445 reverse DNS zone to them, as described in [RFC2317] (for IPv4).
446 However, since most residential users have neither the equipment nor
447 the expertise to run DNS servers, this method is unavailable to
448 residential ISPs.
449
450 This is a general case of the specific case described in
451 Section 2.3.3. All of the same considerations still apply.
452
453 2.5. Dynamically Generate PTR When Queried ("On the Fly")
454
455 Common practice in IPv4 is to provide PTR records for all addresses,
456 regardless of whether a host is actually using the address. In IPv6,
457 ISPs may generate PTR records for all IPv6 addresses as the records
458 are requested. Several DNS servers are capable of this.
459
460 An ISP using this option should generate a PTR record on demand and
461 cache or prepopulate the forward (AAAA) entry for the duration of the
462 Time to Live of the PTR. Similarly, the ISP would prepopulate the
463 PTR following a AAAA query. To reduce exposure to a Denial-of-
464 Service attack, state or storage should be limited. Alternatively,
465 if an algorithm is used to generate a unique name, it can be employed
466 on the fly in both directions. This option has the advantage of
467 assuring matching forward and reverse entries while being simpler
468 than dynamic DNS. Administrators should consider whether the lack of
469 user-specified hostnames is a drawback. It may be possible to allow
470 user-specified hostnames for some records and generate others on the
471 fly; looking up a record before generating on the fly may slow
472 responses or may not scale well.
473
474 DNSSEC [RFC4035] signing records on the fly may increase load;
475 unsigned records can indicate that these records are less trusted,
476 which might be acceptable.
477
478 Another consideration is that the algorithm used for generating the
479 record must be the same on all servers for a zone. In other words,
480 any server for the zone must produce the same response for a given
481 query. Administrators managing a variety of rules within a zone
482 might find it difficult to keep those rules synchronized on all
483 servers.
484
485
486
487
488
489
490
491
492 Howard Informational [Page 9]
493 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
494
495
496 3. Manual User Updates
497
498 It is possible to create a user interface, such as a web page, that
499 would allow end users to enter a hostname to associate with an
500 address. Such an interface would need to be authenticated; only the
501 authorized user could add/change/delete entries. If the ISP changes
502 prefixes assigned to customers, the interface would need to specify
503 only the host bits. The backend would therefore need to be
504 integrated with prefix assignments so that when a new prefix was
505 assigned to a customer, the DNS service would look up user-generated
506 hostnames, delete the old record, and create the new one.
507
508 Considerations about some records being static and others dynamic or
509 dynamically generated (Section 2.5) and the creativity of users
510 (Section 5.5) still apply.
511
512 4. Considerations and Recommendations
513
514 There are six common uses for PTR lookups:
515
516 Rejecting mail: A PTR with a certain string may indicate "This host
517 is not a mail server", which may be useful for rejecting probable
518 spam. The absence of a PTR leads to the desired behavior.
519
520 Serving ads: "This host is probably in town.province." An ISP that
521 does not provide PTR records might affect somebody else's geolocation
522 (also see privacy consideration about location).
523
524 Accepting SSH connections: The presence of a PTR may be inferred to
525 mean "This host has an administrator with enough clue to set up
526 forward and reverse DNS". This is a poor inference.
527
528 Log files: Many systems will record the PTR of remote hosts in their
529 log files to make it easier when reading logs later to see what
530 network the remote host uses.
531
532 Traceroute: The ability to identify an interface and name of any
533 intermediate node or router is important for troubleshooting.
534
535 Service discovery: [RFC6763] specifies "DNS-Based Service Discovery",
536 and Section 11 specifically describes how PTRs are used.
537
538 As a general guideline, when address assignment and name are under
539 the same authority, or when a host has a static address and name,
540 AAAA and PTR records should exist and match. For residential users,
541 if these use cases are important to the ISP, the administrator will
542 then need to consider how to provide PTR records.
543
544
545
546
547 Howard Informational [Page 10]
548 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
549
550
551 The best accuracy would be achieved if ISPs delegated authority along
552 with address delegation, but residential users rarely have domain
553 names or authoritative name servers.
554
555 Dynamic DNS updates can provide accurate data, but there is no
556 standard way to indicate to residential devices where to send
557 updates, whether the hosts support DDNS, or whether it scales.
558
559 An ISP has no knowledge of its residential users' hostnames and
560 therefore can either provide a wildcard response or a dynamically
561 generated response. A valid negative response (such as NXDOMAIN) is
562 a valid response if the four cases above are not essential;
563 delegation where no name server exists should be avoided.
564
565 5. Security and Privacy Considerations
566
567 5.1. Using Reverse DNS for Security
568
569 Some people think the existence of reverse DNS records, or matching
570 forward and reverse DNS records, provides useful information about
571 the hosts with those records. For example, one might infer that the
572 administrator of a network with properly configured DNS records was
573 better informed, and by further inference more responsible, than the
574 administrator of a less thoroughly configured network. For instance,
575 most email providers will not accept incoming connections on port 25
576 unless forward and reverse DNS entries match. If they match, but
577 information higher in the stack (for instance, mail source) is
578 inconsistent, the packet is questionable. However, these records may
579 be easily forged unless DNSSEC or other measures are taken. The
580 string of inferences is questionable and may become unneeded if other
581 means for evaluating trustworthiness (such as positive reputations)
582 become predominant in IPv6.
583
584 Providing location information in PTR records is useful for
585 troubleshooting, law enforcement, and geolocation services, but for
586 the same reasons, it can be considered sensitive information.
587
588 5.2. DNS Security with Dynamic DNS
589
590 The security considerations for using dynamic DNS are described in
591 [RFC3007]. DNS Security Extensions are documented in [RFC4033].
592
593 Interactions with DNSSEC are described throughout this document.
594
595
596
597
598
599
600
601
602 Howard Informational [Page 11]
603 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
604
605
606 5.3. Considerations for Other Uses of the DNS
607
608 Several methods exist for providing encryption keys in the DNS. Any
609 of the options presented here may interfere with these key
610 techniques.
611
612 5.4. Privacy Considerations
613
614 Given the considerations in [RFC8117], hostnames that provide
615 information about a user compromise that user's privacy. Some users
616 may want to identify their hosts using user-specified hostnames, but
617 the default behavior should not be to identify a user, their
618 location, their connectivity, or other information in a PTR record.
619
620 5.5. User Creativity
621
622 Though not precisely a security consideration, administrators may
623 want to consider what domain will contain the records and who will
624 provide the names. If subscribers provide hostnames, they may
625 provide inappropriate strings. Consider "ihate.example.com" or
626 "badword.customer.example.com" or
627 "celebrityname.committed.illegal.acts.example.com".
628
629 6. IANA Considerations
630
631 This document has no IANA actions.
632
633 7. References
634
635 7.1. Normative References
636
637 [RFC1912] Barr, D., "Common DNS Operational and Configuration
638 Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,
639 <https://www.rfc-editor.org/info/rfc1912>.
640
641 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
642 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
643 RFC 2136, DOI 10.17487/RFC2136, April 1997,
644 <https://www.rfc-editor.org/info/rfc2136>.
645
646 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and
647 B. Wellington, "Secret Key Transaction Authentication for
648 DNS (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
649 <https://www.rfc-editor.org/info/rfc2845>.
650
651
652
653
654
655
656
657 Howard Informational [Page 12]
658 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
659
660
661 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
662 "Remote Authentication Dial In User Service (RADIUS)",
663 RFC 2865, DOI 10.17487/RFC2865, June 2000,
664 <https://www.rfc-editor.org/info/rfc2865>.
665
666 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
667 DOI 10.17487/RFC2866, June 2000,
668 <https://www.rfc-editor.org/info/rfc2866>.
669
670 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
671 Update", RFC 3007, DOI 10.17487/RFC3007, November 2000,
672 <https://www.rfc-editor.org/info/rfc3007>.
673
674 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
675 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
676 DOI 10.17487/RFC3646, December 2003,
677 <https://www.rfc-editor.org/info/rfc3646>.
678
679 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and
680 S. Rose, "DNS Security Introduction and Requirements",
681 RFC 4033, DOI 10.17487/RFC4033, March 2005,
682 <https://www.rfc-editor.org/info/rfc4033>.
683
684 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and
685 S. Rose, "Protocol Modifications for the DNS Security
686 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
687 <https://www.rfc-editor.org/info/rfc4035>.
688
689 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
690 System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
691 <https://www.rfc-editor.org/info/rfc4592>.
692
693 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
694 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
695 Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
696 <https://www.rfc-editor.org/info/rfc4704>.
697
698 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
699 Address Autoconfiguration", RFC 4862,
700 DOI 10.17487/RFC4862, September 2007,
701 <https://www.rfc-editor.org/info/rfc4862>.
702
703 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
704 Extensions for Stateless Address Autoconfiguration in
705 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
706 <https://www.rfc-editor.org/info/rfc4941>.
707
708
709
710
711
712 Howard Informational [Page 13]
713 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
714
715
716 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
717 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
718 <https://www.rfc-editor.org/info/rfc6763>.
719
720 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
721 "IPv6 Router Advertisement Options for DNS Configuration",
722 RFC 8106, DOI 10.17487/RFC8106, March 2017,
723 <https://www.rfc-editor.org/info/rfc8106>.
724
725 7.2. Informative References
726
727 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless
728 IN-ADDR.ARPA delegation", BCP 20, RFC 2317,
729 DOI 10.17487/RFC2317, March 1998,
730 <https://www.rfc-editor.org/info/rfc2317>.
731
732 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
733 Considerations and Issues with IPv6 DNS", RFC 4472,
734 DOI 10.17487/RFC4472, April 2006,
735 <https://www.rfc-editor.org/info/rfc4472>.
736
737 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
738 Capabilities in Customer Premises Equipment (CPE) for
739 Providing Residential IPv6 Internet Service", RFC 6092,
740 DOI 10.17487/RFC6092, January 2011,
741 <https://www.rfc-editor.org/info/rfc6092>.
742
743 [RFC8117] Huitema, C., Thaler, D., and R. Winter, "Current Hostname
744 Practice Considered Harmful", RFC 8117,
745 DOI 10.17487/RFC8117, March 2017,
746 <https://www.rfc-editor.org/info/rfc8117>.
747
748 Acknowledgements
749
750 The author would like to thank Alain Durand, JINMEI Tatuya, David
751 Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis,
752 John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence,
753 Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, Chris
754 Roosenraad, Fernando Gont, John Levine, and many others who discussed
755 and provided suggestions for this document.
756
757
758
759
760
761
762
763
764
765
766
767 Howard Informational [Page 14]
768 RFC 8501 Reverse DNS in IPv6 for ISPs November 2018
769
770
771 Author's Address
772
773 Lee Howard
774 Retevia
775 Fairfax, VA 22032
776 United States of America
777
778 Email: lee.howard@retevia.net
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 Howard Informational [Page 15]
823
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.