idnits 2.17.1 draft-howard-isp-ip6rdns-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 315: '...erior interfaces MUST NOT be processed...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 14, 2015) is 3242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2535' is defined on line 563, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Howard 3 Internet-Draft Time Warner Cable 4 Intended status: Informational May 14, 2015 5 Expires: November 15, 2015 7 Reverse DNS in IPv6 for Internet Service Providers 8 draft-howard-isp-ip6rdns-08 10 Abstract 12 In IPv4, Internet Service Providers (ISPs) commonly provide IN- 13 ADDR.ARPA information for their customers by prepopulating the zone 14 with one PTR record for every available address. This practice does 15 not scale in IPv6. This document analyzes different approaches and 16 considerations for ISPs in managing the ip6.arpa zone for IPv6 17 address space assigned to many customers. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 15, 2015. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3 55 1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 3 56 2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Wildcard match . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6 61 2.3.2. Dynamic DNS through Residential Gateways . . . . . . 6 62 2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7 63 2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8 64 2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8 65 2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8 66 2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 8 67 2.5. Dynamically Generate PTR When Queried ('On the Fly') . . 9 68 3. Considerations and Recommendations . . . . . . . . . . . . . 9 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 4.1. Using Reverse DNS for Security . . . . . . . . . . . . . 10 71 4.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11 72 4.3. Considerations for Other Uses of the DNS . . . . . . . . 11 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 7.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Best practice is that "Every Internet-reachable host should have a 83 name" [RFC1912] that is recorded with a PTR resource record in the 84 .ARPA zone, and "PTR's should use official names and not aliases" 85 [RFC1033]. Some network services perform a PTR lookup on the source 86 address of incoming packets before performing services. 88 Individual Internet users in the residential or consumer scale, 89 including small and home businesses, are constantly joining or moving 90 on the Internet. For large Internet service providers who serve 91 residential users, maintenance of individual PTR records is 92 impractical. Administrators at ISPs should consider the need for PTR 93 records and evaluate methods for responding to reverse DNS queries in 94 IPv6. 96 1.1. Reverse DNS in IPv4 98 ISPs that provide access to many residential users typically assign 99 one or a few IPv4 addresses to each of those users, and populate an 100 \%IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some 101 ISPs also configure forward zones with matching A records, so that 102 lookups match. For instance, if an ISP Example.com aggregated 103 192.0.2.0/24 at a network hub in Town in the province of AnyWhere, 104 the reverse zone might look like: 106 1.2.0.192.IN-ADDR.ARPA. IN PTR 1.user.town.AW.example.com. 108 2.2.0.192.IN-ADDR.ARPA. IN PTR 2.user.town.AW.example.com. 110 3.2.0.192.IN-ADDR.ARPA. IN PTR 3.user.town.AW.example.com. 112 . 114 . 116 . 118 254.2.0.192.IN-ADDR.ARPA. IN PTR 254.user.town.AW.example.com. 120 The conscientious Example.com might then also have a zone: 122 1.user.town.AW.example.com. IN A 192.0.2.1 124 2.user.town.AW.example.com. IN A 192.0.2.2 126 3.user.town.AW.example.com. IN A 192.0.2.3 128 \. 130 \. 132 \. 134 254.user.town.AW.example.com. IN A 192.0.2.254 136 Many ISPs generate PTR records for all IP addresses used for 137 customers, and many create the matching A record. 139 1.2. Reverse DNS Considerations in IPv6 141 A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be: 143 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 144 .IP6.ARPA. IN PTR 1.user.town.AW.example.com. 146 ISPs will often delegate an IPv6 prefix to their customers. Since 147 2^^80 possible addresses could be configured in an example 148 2001:db8:f00/48 zone alone, even with automation it is impractical to 149 write a zone with every possible address entered. If 1000 entries 150 could be written per second, the zone would still not be complete 151 after 38 trillion years. 153 Furthermore, it is often impossible to associate host names and 154 addresses, since the 64 bits in the Interface Identifier portion of 155 the address are frequently assigned using SLAAC [RFC4862] when the 156 host comes online, and may be short-lived. 158 [RFC1912] is an informational document that says "PTR records must 159 point back to a valid A record" and further that the administrator 160 should "Make sure your PTR and A records match." [RFC1912] This 161 document considers how to follow this advice for AAAA and PTR 162 records. 164 2. Alternatives in IPv6 166 Several options exist for providing reverse DNS in IPv6. All of 167 these options also exist for IPv4, but the scaling problem is much 168 less severe in IPv4. Each option should be evaluated for its scaling 169 ability, its compliance with existing standards and best practices, 170 and its availability in common systems. 172 2.1. Negative Response 174 Some ISP DNS administrators may choose to provide only a NXDomain 175 response to PTR queries for subscriber addresses. In some ways, this 176 is the most accurate response, since no name information is known 177 about the host. Providing a negative response in response to PTR 178 queries does not satisfy the expectation in [RFC1912] for entries to 179 match. Users of services which are dependent on a successful lookup 180 will have a poor experience. For instance, some web services and SSH 181 connections wait for a DNS response, even NXDOMAIN, before 182 responding. For best user experience, then, it is important to 183 return a response, rather than have a lame delegation. On the other 184 hand, external mail servers are likely to reject connections, which 185 might be an advantage in fighting spam. DNS administrators should 186 consider the uses for reverse DNS records and the number of services 187 affecting the number of users when evaluating this option. 189 2.2. Wildcard match 191 The use of wildcards in the DNS is described in [RFC4592], and their 192 use in IPv6 reverse DNS is described in [RFC4472]. 194 While recording all possible addresses is not scalable, it may be 195 possible to record a wildcard entry for each prefix assigned to a 196 customer. Consider also that "inclusion of wildcard NS RRSets in a 197 zone is discouraged, but not barred." [RFC4035] 199 This solution generally scales well. However, since the response 200 will match any address in the wildcard range (/48, /56, /64, etc.), a 201 forward DNS lookup on that response given will not be able to return 202 the same hostname. This method therefore fails the expectation in 203 [RFC1912] for forward and reverse to match. DNSsec [RFC4035] 204 scalability is limited to signing the wildcard zone, which may be 205 satisfactory. 207 2.3. Dynamic DNS 209 One way to ensure forward and reverse records match is for hosts to 210 update DNS servers dynamically, once interface configuration (whether 211 SLAAC, DHCPv6, or other means) is complete, as described in 212 [RFC4472]. Hosts would need to provide both AAAA and PTR updates, 213 and would need to know which servers would accept the information. 215 This option should scale as well or as poorly as IPv4 dynamic DNS 216 does. Dynamic DNS may not scale effectively in large ISP networks 217 which have no single master name server, but a single master server 218 is not best practice. The ISP's DNS system may provide a point for 219 Denial of Service attacks, including many attempted dDNS updates. 220 Accepting updates only from authenticated sources may mitigate this 221 risk, but only if authentication itself does not require excessive 222 overhead. No authentication of dynamic DNS updates is inherently 223 provided; implementers should consider use of TSIG [RFC2845], or at 224 least ingress filtering so updates are only accepted from customer 225 address space from internal network interfaces, rate limit the number 226 of updates from a customer per second, and consider impacts on 227 scalability. UDP is allowed per [RFC2136] so transmission control is 228 not assured, though the host should expect an ERROR or NOERROR 229 message from the server [RFC2136]; TCP provides transmission control, 230 but the updating host would need to be configured to use TCP. 232 Administrators should consider what domain will contain the records, 233 and who will provide the names. If subscribers provide hostnames, 234 they may provide inappropriate strings. Consider "ihate.example.com" 235 or "badword.customer.example.com" or 236 "celebrityname.committed.illegal.acts.example.com." 237 There is no assurance of uniqueness if multiple hosts try to update 238 with the same name ("mycomputer.familyname.org"). There is no 239 standard way to indicate to a host what server it should send dDNS 240 updates to. 242 2.3.1. Dynamic DNS from Individual Hosts 244 In the simplest case, a residential user will have a single host 245 connected to the ISP. Since the typical residential user cannot 246 configure IPv6 addresses and resolving name servers on their hosts, 247 the ISP should provide address information conventionally (i.e., 248 their normal combination of RAs, DHCP, etc.), and should provide a 249 DNS Recursive Name Server and Domain Search List as described in 250 [RFC3646] or [RFC6106]. In determining its Fully Qualified Domain 251 Name, a host will typically use a domain from the Domain Search List. 252 This is an overloading of the parameter; multiple domains could be 253 listed, since hosts may need to search for unqualified names in 254 multiple domains, without necessarily being a member of those 255 domains. Administrators should consider whether the domain search 256 list actually provides an appropriate DNS suffix(es) when considering 257 use of this option. For purposes of dynamic DNS, the host would 258 concatenate its local hostname (e.g., "hostname") plus the domain(s) 259 in the Domain Search List (e.g., "customer.example.com"), as in 260 "hostname.customer.example.com." 262 Once it learns its address, and has a resolving name server, the host 263 must perform an SOA lookup on the ip6.arpa record to be added, to 264 find the owner, eventually to find the server authoritative for the 265 zone (which might accept dynamic updates). Several recursive lookups 266 may be required to find the longest prefix which has been delegated. 267 The DNS administrator must designate the Primary Master Server for 268 the longest match required. Once found, the host sends dynamic AAAA 269 and PTR updates using the concatenation defined above 270 ("hostname.customer.example.com"). 272 In order to use this alternative, hosts must be configured to use 273 dynamic DNS. This is not default behavior for many hosts, which is 274 an inhibitor for the large ISP. This option may be scalable, 275 although registration following an outage may cause significant load, 276 and hosts using privacy extensions [RFC4941] may update records 277 daily. It is up to the host to provide matching forward and reverse 278 records, and to update them when the address changes. 280 2.3.2. Dynamic DNS through Residential Gateways 282 Residential customers may have a gateway, which may provide DHCPv6 283 service to hosts from a delegated prefix. ISPs should provide a DNS 284 Recursive Name Server and Domain Search List to the gateway, as 285 described above and in [RFC3646] and [RFC6106]. There are two 286 options for how the gateway uses this information. The first option 287 is for the gateway to respond to DHCPv6 requests with the same DNS 288 Recursive Name Server and Domain Search List provided by the ISP. 289 The alternate option is for the gateway to relay dynamic DNS updates 290 from hosts to the servers and domain provided by the ISP. Host 291 behavior is unchanged; the host sends the same dynamic updates, 292 either to the ISP's server (as provided by the gateway), or to the 293 gateway for it to forward. 295 2.3.3. Automatic DNS Delegations 297 An ISP may delegate authority for a subdomain such as 298 "customer12345.town.AW.customer.example.com" or 299 "customer12345.example.com" to the customer's gateway. Each domain 300 thus delegated must be unique within the DNS. The ISP may also then 301 delegate the ip6.arpa zone for the prefix delegated to the customer, 302 as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa." 303 Then the customer could provide updates to their own gateway, with 304 forward and reverse. However, individual hosts connected directly to 305 the ISP rarely have the capability to run DNS for themselves; 306 therefore, an ISP can only delegate to customers with gateways 307 capable of being authoritative name servers. If a device requests a 308 DHCPv6 Prefix Delegation, that may be considered a reasonably 309 reliable indicator that it is a gateway, rather than an individual 310 host. It is not necessarily an indicator that the gateway is capable 311 of providing DNS services, and therefore cannot be relied upon as a 312 way to test whether this option is feasible. In fact, this kind of 313 delegation will not work for devices complying with [RFC6092], which 314 includes the requirement, "By DEFAULT, inbound DNS queries received 315 on exterior interfaces MUST NOT be processed by any integrated DNS 316 resolving server." 318 If the customer's gateway is the name server, it provides its own 319 information to hosts on the network, as often done for enterprise 320 networks, and as described in [RFC2136]. 322 An ISP could provide authoritative responses as a secondary server to 323 the customer's master server. For instance, the home gateway name 324 server could be the master server, with the ISP providing the only 325 published NS authoritative servers. 327 To implement this alternative, users' residential gateways must be 328 capable of acting as authoritative name servers capable of dynamic 329 DNS updates. There is no mechanism for an ISP to dynamically 330 communicate to a user's equipment that a zone has been delegated, so 331 user action would be required. Most users have neither the equipment 332 nor the expertise to run DNS servers, so this option is unavailable 333 to the residential ISP. 335 2.3.4. Generate Dynamic Records 337 An ISP's name server that receives a dynamic forward or reverse DNS 338 update may create a matching entry. Since a host capable of updating 339 one is generally capable of updating the other, this should not be 340 required, but redundant record creation will ensure a record exists. 341 ISPs implementing this method should check whether a record already 342 exists before accepting or creating updates. 344 This method is also dependent on hosts being capable of providing 345 dynamic DNS updates, which is not default behavior for many hosts. 347 2.3.5. Populate from DHCP Server 349 A ISP's DHCPv6 server may populate the forward and reverse zones when 350 the DHCP request is received, if the request contains enough 351 information. [RFC4704] 353 However, this method will only work for a single host address 354 (IA_NA); the ISP's DHCP server would not have enough information to 355 update all records for a prefix delegation. If the zone authority is 356 delegated to a home gateway which used this method, the gateway could 357 update records for residential hosts. To implement this alternative, 358 users' residential gateways would have to support the FQDN DHCP 359 option, and would have to either have the zones configured, or send 360 dDNS messages to the ISP's name server. 362 2.3.6. Populate from RADIUS Server 364 A user may receive an address or prefix from a RADIUS [RFC2865] 365 server, the details of which may be recorded via RADIUS Accounting 366 [RFC2866] data. The ISP may populate the forward and reverse zones 367 from the accounting data if it contains enough information. This 368 solution allows the ISP to populate data concerning allocated 369 prefixes (as per 2.2 (wildcards)) and CPE endpoints, but as with 370 2.3.5 does not allow the ISP to populate information concerning 371 individual hosts. 373 2.4. Delegate DNS 375 For customers who are able to run their own DNS servers, such as 376 commercial customers, often the best option is to delegate the 377 reverse DNS zone to them, as described in [RFC2317] (for IPv4). 378 However, since most residential users have neither the equipment nor 379 the expertise to run DNS servers, this method is unavailable to 380 residential ISPs. 382 This is a general case of the specific case described in 383 Section 2.3.3. All of the same considerations still apply. 385 2.5. Dynamically Generate PTR When Queried ('On the Fly') 387 Common practice in IPv4 is to provide PTR records for all addresses, 388 regardless of whether a host is actually using the address. In IPv6, 389 ISPs may generate PTR records for all IPv6 addresses as the records 390 are requested. Configuring records "on the fly" may consume more 391 processor resource than other methods, but only on demand. A denial 392 of service is therefore possible, which may be mitigated with rate- 393 limiting and normal countermeasures. 395 An ISP using this option should generate a PTR record on demand, and 396 cache or prepopulate the forward (AAAA) entry for the duration of the 397 \%time-to-live of the PTR. Similarly, the ISP would prepopulate the 398 PTR following a AAAA query. Alternatively, if an algorithm is used 399 to generate unique name, it can be employed on the fly in both 400 directions. This option has the advantage of assuring matching 401 forward and reverse entries, while being simpler than dynamic DNS. 402 Administrators should consider whether the lack of \%user-specified 403 hostnames is a drawback. 405 This method may not scale well in conjunction with DNSsec [RFC4035], 406 because of the additional load, but since keys may be pregenerated 407 for zones, and not for each record, the risk is moderate. Signing 408 records on the fly may increase load, and may not scale; unsigned 409 records can indicate that these records are less trusted, which might 410 be acceptable. 412 Another consideration is that the algorithm used for generating the 413 record must be the same on all servers for a zone. In other words, 414 any server for the zone must produce the same response for a given 415 query. Administrators managing a variety of rules within a zone 416 might find it difficult to keep those rules synchronized on all 417 servers. 419 3. Considerations and Recommendations 421 There are four common uses for PTR lookups: 423 Reject mail: A PTR with a certain string or missing may indicate 424 "This host is not a mail server," which may be useful for rejecting 425 probable spam. The absence of a PTR leads to the desired behavior. 427 Serving ads: "This host is probably in town.province." An ISP that 428 does not provide PTR records might affect somebody else's 429 geolocation. 431 Accepting SSH connections: The absence of a PTR may be inferred to 432 mean "This host has an administrator with enough clue to set up 433 forward and reverse DNS." This is a poor inference. 435 Log files. Many systems will record the PTR of remote hosts in their 436 log files, to make it easier to see what network the remote host uses 437 when reading logs later. 439 Traceroute. The ability to identify an interface and name of any 440 intermediate node or router is important for troubleshooting. 442 As a general guideline, when address assignment and name are under 443 the same authority, or when a host has a static address and name, 444 AAAA and PTR records should exist and match. For residential users, 445 if these four use cases are important to the ISP, the administrator 446 will then need to consider how to provide PTR records. 448 The best accuracy would be achieved if ISPs delegate authority along 449 with address delegation, but residential users rarely have domain 450 names or authoritative name servers. 452 Dynamic DNS updates can provide accurate data, but there is no 453 standard way to indicate to residential devices where to send 454 updates, if the hosts support it, and if it scales. 456 An ISP has no knowledge of its residential users' hostnames, and 457 therefore can either provide a wildcard response or a dynamically 458 generated response. A valid negative response (such as NXDomain) is 459 a valid response, if the four cases above are not essential; lame 460 delegation should be avoided. 462 4. Security Considerations 464 4.1. Using Reverse DNS for Security 466 Some people think the existence of reverse DNS records, or matching 467 forward and reverse DNS records, provides useful information about 468 the hosts with those records. For example, one might infer that the 469 administrator of a network with properly configured DNS records was 470 \%better-informed, and by further inference more responsible, than 471 the administrator of a less-thoroughly configured network. For 472 instance, most email providers will not accept incoming connections 473 on port 25 unless forward and reverse DNS entries match. If they 474 match, but information higher in the stack (for instance, mail 475 source) is inconsistent, the packet is questionable. These records 476 may be easily forged though, unless DNSsec or other measures are 477 taken. The string of inferences is questionable, and may become 478 unneeded if other means for evaluating trustworthiness (such as 479 positive reputations) become predominant in IPv6. 481 Providing location information in PTR records is useful for 482 troubleshooting, law enforcement, and geolocation services, but for 483 the same reasons can be considered sensitive information. 485 4.2. DNS Security with Dynamic DNS 487 Security considerations of using dynamic DNS are described in 488 [RFC3007]. DNS Security Extensions are documented in [RFC4033]. 490 Interactions with DNSsec are described throughout this document. 492 4.3. Considerations for Other Uses of the DNS 494 Several methods exist for providing encryption keys in the DNS. Any 495 of the options presented here may interfere with these key 496 techniques. 498 5. Acknowledgements 500 The author would like to thank Alain Durand, JINMEI Tatuya, David 501 Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis, 502 John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence, 503 Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, and Chris 504 Roosenraad, Fernando Gont, John Levine, and many others who discussed 505 and provided suggestions for this document. 507 6. IANA Considerations 509 There are no IANA considerations or implications that arise from this 510 document. 512 7. References 514 7.1. Normative References 516 [RFC1033] Lottor, M., "Domain Administrators Operators Guide", 517 November 1987. 519 [RFC1912] Barr, D., "Common DNS Operational and Configuration 520 Errors", February 1996. 522 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 523 "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1917. 525 [RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)". 527 [RFC2865] "Remote Authentication Dial In User Service (RADIUS)". 529 [RFC2866] "RADIUS Accounting". 531 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 532 Update", November 2000. 534 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host 535 Configuration Protocol for IPv6 (DHCPv6)", December 2003. 537 [RFC4033] "DNS Security Introduction and Requirements". 539 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 540 Rose, "Protocol Modifications for the DNS Security Extensions", March 541 2005. 543 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 544 System", July 2006. 546 [RFC4704] Stapp, M., Volz, Y., and Y. Rekhter, "The Dynamic Host 547 Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified 548 Domain Name (FQDN) Option". 550 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 551 Address Autoconfiguration", September 2007. 553 [RFC4941] "Privacy Extensions for Stateless Address Autoconfiguration 554 in IPv6". 556 [RFC6106] "IPv6 Router Advertisement Options for DNS Configuration". 558 7.2. Informative References 560 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 561 ADDR.ARPA delegation", March 1998. 563 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 564 March 1999. 566 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 567 Considerations and Issues with IPv6 DNS", April 2006. 569 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 570 Customer Premises Equipment (CPE) for Providing Residential IPv6 571 Internet Service", January 2011. 573 [inaddr-reqd] Senie, D., "draft-ietf-dnsop-inaddr-required-07", 574 August 2005. 576 [rmap-consider] Senie, D. and A. Sullivan, \%"draft-ietf-dnsop- 577 reverse-mapping-considerations-06", March 2008. Author's Address 579 Lee Howard Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 580 20171 US 582 Email: lee.howard@twcable.com 584 Author's Address 586 Lee Howard 587 Time Warner Cable 588 13820 Sunrise Valley Dr. 589 Herndon, VA 20171 590 USA 592 Email: lee.howard@twcable.com