idnits 2.17.1 draft-ietf-dnsop-isp-ip6rdns-06.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 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 318: '...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 (September 05, 2018) is 2059 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1033' is defined on line 543, 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) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Howard 2 Internet-Draft Retevia 3 Intended status: Informational September 05, 2018 4 Expires: March 9, 2019 6 Reverse DNS in IPv6 for Internet Service Providers 7 draft-ietf-dnsop-isp-ip6rdns-06 9 Abstract 11 In IPv4, Internet Service Providers (ISPs) commonly provide IN- 12 ADDR.ARPA information for their customers by prepopulating the zone 13 with one PTR record for every available address. This practice does 14 not scale in IPv6. This document analyzes different approaches and 15 considerations for ISPs in managing the IP6.ARPA zone. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on March 9, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Reverse DNS in IPv4 . . . . . . . . . . . . . . . . . . . 3 53 1.2. Reverse DNS Considerations in IPv6 . . . . . . . . . . . 4 54 2. Alternatives in IPv6 . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Negative Response . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Wildcard match . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3.1. Dynamic DNS from Individual Hosts . . . . . . . . . . 6 59 2.3.2. Dynamic DNS through Residential Gateways . . . . . . 7 60 2.3.3. Automatic DNS Delegations . . . . . . . . . . . . . . 7 61 2.3.4. Generate Dynamic Records . . . . . . . . . . . . . . 8 62 2.3.5. Populate from DHCP Server . . . . . . . . . . . . . . 8 63 2.3.6. Populate from RADIUS Server . . . . . . . . . . . . . 8 64 2.4. Delegate DNS . . . . . . . . . . . . . . . . . . . . . . 9 65 2.5. Dynamically Generate PTR When Queried ('On the Fly') . . 9 66 3. Manual User Updates . . . . . . . . . . . . . . . . . . . . . 9 67 4. Considerations and Recommendations . . . . . . . . . . . . . 10 68 5. Security and Privacy Considerations . . . . . . . . . . . . . 11 69 5.1. Using Reverse DNS for Security . . . . . . . . . . . . . 11 70 5.2. DNS Security with Dynamic DNS . . . . . . . . . . . . . . 11 71 5.3. Considerations for Other Uses of the DNS . . . . . . . . 11 72 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 77 9.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 [RFC1912] recommended that "every internet-reachable host should have 83 a name" and says "Failure to have matching PTR and A records can 84 cause loss of Internet services similar to not being registered in 85 the DNS at all." While the need for a PTR record and for it to match 86 is debatable as a best practice, some network services [see 87 Section 3] still do rely on PTR lookups, and some check the source 88 address of incoming connections and verify that the PTR and A records 89 match before providing service. 91 Individual Internet users in the residential or consumer scale, 92 including small and home businesses, are constantly joining or moving 93 on the Internet. For large Internet service providers who serve 94 residential users, maintenance of individual PTR records is 95 impractical. Administrators at ISPs should consider whether customer 96 PTR records are needed, and if so, evaluate methods for responding to 97 reverse DNS queries in IPv6. 99 1.1. Reverse DNS in IPv4 101 ISPs that provide access to many residential users typically assign 102 one or a few IPv4 addresses to each of those users, and populate an 103 IN-ADDR.ARPA zone with one PTR record for every IPv4 address. Some 104 ISPs also configure forward zones with matching A records, so that 105 lookups match. For instance, if an ISP Example.com aggregated 106 192.0.2.0/24 at a network hub in one region, the reverse zone might 107 look like: 109 1.2.0.192.IN-ADDR.ARPA. IN PTR 1.string.region.example.com. 111 2.2.0.192.IN-ADDR.ARPA. IN PTR 2.string.region.example.com. 113 3.2.0.192.IN-ADDR.ARPA. IN PTR 3.string.region.example.com. 115 . 117 . 119 . 121 254.2.0.192.IN-ADDR.ARPA. IN PTR 254.string.region.example.com. 123 The conscientious Example.com might then also have a zone: 125 1.string.region.example.com. IN A 192.0.2.1 127 2.string.region.example.com. IN A 192.0.2.2 129 3.string.region.example.com. IN A 192.0.2.3 131 . 133 . 135 . 137 254.string.region.example.com. IN A 192.0.2.254 139 Many ISPs generate PTR records for all IP addresses used for 140 customers, and many create the matching A record. 142 1.2. Reverse DNS Considerations in IPv6 144 A sample entry for 2001:0db8:0f00:0000:0012:34ff:fe56:789a might be: 146 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 147 .IP6.ARPA. IN PTR 1.string.region.example.com. 149 ISPs will often delegate an IPv6 prefix to their customers. Since 150 2^^80 possible addresses could be configured in an single /48 zone 151 alone, even with automation it is impractical to write a zone with 152 every possible address entered. If 1000 entries could be written per 153 second, the zone would still not be complete after 38 trillion years. 155 Furthermore, it is often impossible to associate host names and 156 addresses, since the 64 bits in the Interface Identifier portion of 157 the address are frequently assigned using SLAAC [RFC4862] when the 158 host comes online, and may be short-lived. 160 [RFC1912] is an informational document that says "PTR records must 161 point back to a valid A record" and further that the administrator 162 should "Make sure your PTR and A records match." [RFC1912] This 163 document considers how to follow this advice for AAAA and PTR 164 records. 166 2. Alternatives in IPv6 168 Several options exist for providing reverse DNS in IPv6. All of 169 these options also exist for IPv4, but the scaling problem is much 170 less severe in IPv4. Each option should be evaluated for its scaling 171 ability, its compliance with existing standards and best practices, 172 and its availability in common systems. 174 2.1. Negative Response 176 Some ISP DNS administrators may choose to provide only a NXDomain 177 response to PTR queries for subscriber addresses. In some ways, this 178 is the most accurate response, since no name information is known 179 about the host. Providing a negative response in response to PTR 180 queries does not satisfy the expectation in [RFC1912] for entries to 181 match. Users of services which are dependent on a successful lookup 182 will have a poor experience. For instance, some web services and SSH 183 connections wait for a DNS response, even NXDOMAIN, before 184 responding. For best user experience, then, it is important to 185 return a response, rather than have a lame delegation. On the other 186 hand, external mail servers are likely to reject connections, which 187 might be an advantage in fighting spam. DNS administrators should 188 consider the uses for reverse DNS records and the number of services 189 affecting the number of users when evaluating this option. 191 2.2. Wildcard match 193 The use of wildcards in the DNS is described in [RFC4592], and their 194 use in IPv6 reverse DNS is described in [RFC4472]. 196 While recording all possible addresses is not scalable, it may be 197 possible to record a wildcard entry for each prefix assigned to a 198 customer. Consider also that "inclusion of wildcard NS RRSets in a 199 zone is discouraged, but not barred." [RFC4035] 201 This solution generally scales well. However, since the response 202 will match any address in the wildcard range (/48, /56, /64, etc.), a 203 forward DNS lookup on that response given will not be able to return 204 the same hostname. This method therefore fails the expectation in 205 [RFC1912] for forward and reverse to match. DNSSEC [RFC4035] 206 scalability is limited to signing the wildcard zone, which may be 207 satisfactory. 209 2.3. Dynamic DNS 211 One way to ensure forward and reverse records match is for hosts to 212 update DNS servers dynamically, once interface configuration (whether 213 SLAAC, DHCPv6, or other means) is complete, as described in 214 [RFC4472]. Hosts would need to provide both AAAA and PTR updates, 215 and would need to know which servers would accept the information. 217 This option should scale as well or as poorly as IPv4 dynamic DNS 218 does. Dynamic DNS may not scale effectively in large ISP networks 219 which have no single master name server, but a single master server 220 is not best practice. The ISP's DNS system may provide a point for 221 Denial of Service attacks, including many attempted dDNS updates. 222 Accepting updates only from authenticated sources may mitigate this 223 risk, but only if authentication itself does not require excessive 224 overhead. No authentication of dynamic DNS updates is inherently 225 provided; implementers should consider use of TSIG [RFC2845], or at 226 least ingress filtering so updates are only accepted from customer 227 address space from internal network interfaces, rate limit the number 228 of updates from a customer per second, and consider impacts on 229 scalability. UDP is allowed per [RFC2136] so transmission control is 230 not assured, though the host should expect an ERROR or NOERROR 231 message from the server [RFC2136]; TCP provides transmission control, 232 but the updating host would need to be configured to use TCP. 234 Administrators should consider what domain will contain the records, 235 and who will provide the names. If subscribers provide hostnames, 236 they may provide inappropriate strings. Consider "ihate.example.com" 237 or "badword.customer.example.com" or 238 "celebrityname.committed.illegal.acts.example.com." 239 There is no assurance of uniqueness if multiple hosts try to update 240 with the same name ("mycomputer.familyname.org"). There is no 241 standard way to indicate to a host what server it should send dDNS 242 updates to; the master listed in the SOA is often assumed to be a 243 dDNS server, but this may not scale. 245 2.3.1. Dynamic DNS from Individual Hosts 247 In the simplest case, a residential user will have a single host 248 connected to the ISP. Since the typical residential user cannot 249 configure IPv6 addresses and resolving name servers on their hosts, 250 the ISP should provide address information conventionally (i.e., 251 their normal combination of RAs, DHCP, etc.), and should provide a 252 DNS Recursive Name Server and Domain Search List as described in 253 [RFC3646] or [RFC6106]. In determining its Fully Qualified Domain 254 Name, a host will typically use a domain from the Domain Search List. 255 This is an overloading of the parameter; multiple domains could be 256 listed, since hosts may need to search for unqualified names in 257 multiple domains, without necessarily being a member of those 258 domains. Administrators should consider whether the domain search 259 list actually provides an appropriate DNS suffix(es) when considering 260 use of this option. For purposes of dynamic DNS, the host would 261 concatenate its local hostname (e.g., "hostname") plus the domain(s) 262 in the Domain Search List (e.g., "customer.example.com"), as in 263 "hostname.customer.example.com." 265 Once it learns its address, and has a resolving name server, the host 266 must perform an SOA lookup on the IP6.ARPA record to be added, to 267 find the owner, eventually to find the server authoritative for the 268 zone (which might accept dynamic updates). Several recursive lookups 269 may be required to find the longest prefix which has been delegated. 270 The DNS administrator must designate the Primary Master Server for 271 the longest match required. Once found, the host sends dynamic AAAA 272 and PTR updates using the concatenation defined above 273 ("hostname.customer.example.com"). 275 In order to use this alternative, hosts must be configured to use 276 dynamic DNS. This is not default behavior for many hosts, which is 277 an inhibitor for the large ISP. This option may be scalable, 278 although registration following an outage may cause significant load, 279 and hosts using privacy extensions [RFC4941] may update records 280 daily. It is up to the host to provide matching forward and reverse 281 records, and to update them when the address changes. 283 2.3.2. Dynamic DNS through Residential Gateways 285 Residential customers may have a gateway, which may provide DHCPv6 286 service to hosts from a delegated prefix. ISPs should provide a DNS 287 Recursive Name Server and Domain Search List to the gateway, as 288 described above and in [RFC3646] and [RFC6106]. There are two 289 options for how the gateway uses this information. The first option 290 is for the gateway to respond to DHCPv6 requests with the same DNS 291 Recursive Name Server and Domain Search List provided by the ISP. 292 The alternate option is for the gateway to relay dynamic DNS updates 293 from hosts to the servers and domain provided by the ISP. Host 294 behavior is unchanged; the host sends the same dynamic updates, 295 either to the ISP's server (as provided by the gateway), or to the 296 gateway for it to forward. 298 2.3.3. Automatic DNS Delegations 300 An ISP may delegate authority for a subdomain such as 301 "customer12345.town.AW.customer.example.com" or 302 "customer12345.example.com" to the customer's gateway. Each domain 303 thus delegated must be unique within the DNS. The ISP may also then 304 delegate the IP6.ARPA zone for the prefix delegated to the customer, 305 as in (for 2001:db8:f00::/48) "0.0.f.0.8.b.d.0.1.0.0.2.IP6.ARPA." 306 Then the customer could provide updates to their own gateway, with 307 forward and reverse. However, individual hosts connected directly to 308 the ISP rarely have the capability to run DNS for themselves; 309 therefore, an ISP can only delegate to customers with gateways 310 capable of being authoritative name servers. If a device requests a 311 DHCPv6 Prefix Delegation, that may be considered a reasonably 312 reliable indicator that it is a gateway, rather than an individual 313 host. It is not necessarily an indicator that the gateway is capable 314 of providing DNS services, and therefore cannot be relied upon as a 315 way to test whether this option is feasible. In fact, this kind of 316 delegation will not work for devices complying with [RFC6092], which 317 includes the requirement, "By DEFAULT, inbound DNS queries received 318 on exterior interfaces MUST NOT be processed by any integrated DNS 319 resolving server." 321 If the customer's gateway is the name server, it provides its own 322 information to hosts on the network, as often done for enterprise 323 networks, and as described in [RFC2136]. 325 An ISP could provide authoritative responses as a secondary server to 326 the customer's master server. For instance, the home gateway name 327 server could be the master server, with the ISP providing the only 328 published NS authoritative servers. 330 To implement this alternative, users' residential gateways must be 331 capable of acting as authoritative name servers capable of dynamic 332 DNS updates. There is no mechanism for an ISP to dynamically 333 communicate to a user's equipment that a zone has been delegated, so 334 user action would be required. Most users have neither the equipment 335 nor the expertise to run DNS servers, so this option is unavailable 336 to the residential ISP. 338 2.3.4. Generate Dynamic Records 340 An ISP's name server that receives a dynamic forward or reverse DNS 341 update may create a matching entry. Since a host capable of updating 342 one is generally capable of updating the other, this should not be 343 required, but redundant record creation will ensure a record exists. 344 ISPs implementing this method should check whether a record already 345 exists before accepting or creating updates. 347 This method is also dependent on hosts being capable of providing 348 dynamic DNS updates, which is not default behavior for many hosts. 350 2.3.5. Populate from DHCP Server 352 A ISP's DHCPv6 server may populate the forward and reverse zones when 353 the DHCP request is received, if the request contains enough 354 information. [RFC4704] 356 However, this method will only work for a single host address 357 (IA_NA); the ISP's DHCP server would not have enough information to 358 update all records for a prefix delegation. If the zone authority is 359 delegated to a home gateway which used this method, the gateway could 360 update records for residential hosts. To implement this alternative, 361 users' residential gateways would have to support the FQDN DHCP 362 option, and would have to either have the zones configured, or send 363 dDNS messages to the ISP's name server. 365 2.3.6. Populate from RADIUS Server 367 A user may receive an address or prefix from a RADIUS [RFC2865] 368 server, the details of which may be recorded via RADIUS Accounting 369 [RFC2866] data. The ISP may populate the forward and reverse zones 370 from the accounting data if it contains enough information. This 371 solution allows the ISP to populate data concerning allocated 372 prefixes (as per 2.2 (wildcards)) and CPE endpoints, but as with 373 2.3.5 does not allow the ISP to populate information concerning 374 individual hosts. 376 2.4. Delegate DNS 378 For customers who are able to run their own DNS servers, such as 379 commercial customers, often the best option is to delegate the 380 reverse DNS zone to them, as described in [RFC2317] (for IPv4). 381 However, since most residential users have neither the equipment nor 382 the expertise to run DNS servers, this method is unavailable to 383 residential ISPs. 385 This is a general case of the specific case described in 386 Section 2.3.3. All of the same considerations still apply. 388 2.5. Dynamically Generate PTR When Queried ('On the Fly') 390 Common practice in IPv4 is to provide PTR records for all addresses, 391 regardless of whether a host is actually using the address. In IPv6, 392 ISPs may generate PTR records for all IPv6 addresses as the records 393 are requested. Several DNS servers are capable of this. 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. It may be possible to allow user-specified 404 hostnames for some records and generate others on the fly; looking up 405 a record before generating on the fly may slow responses or may not 406 scale well. 408 DNSSEC [RFC4035] signing records on the fly may increase load; 409 unsigned records can indicate that these records are less trusted, 410 which might 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. Manual User Updates 421 It is possible to create a user interface, such as a web page, that 422 would allow end users to enter a hostname to associate with an 423 address. Such an interface would need to be authenticated (only the 424 authorized user could add/change/delete entries). It would need to 425 specify only the host bits if the ISP changes prefixes assigned to 426 customers, and the back end would therefore need to be integrated 427 with prefix assignments, so that when a new prefix was assigned to a 428 customer, the DNS service would look up user-generated hostnames and 429 delete the old record and create the new one. 431 Considerations about some records being static and others dynamic or 432 dynamically generated (section 2.5) and the creativity of users 433 (section 2.3) still apply. 435 4. Considerations and Recommendations 437 There are six common uses for PTR lookups: 439 Rejecting mail: A PTR with a certain string or missing may indicate 440 "This host is not a mail server," which may be useful for rejecting 441 probable spam. The absence of a PTR leads to the desired behavior. 443 Serving ads: "This host is probably in town.province." An ISP that 444 does not provide PTR records might affect somebody else's 445 geolocation. 447 Accepting SSH connections: The presence of a PTR may be inferred to 448 mean "This host has an administrator with enough clue to set up 449 forward and reverse DNS." This is a poor inference. 451 Log files: Many systems will record the PTR of remote hosts in their 452 log files, to make it easier to see what network the remote host uses 453 when reading logs later. 455 Traceroute: The ability to identify an interface and name of any 456 intermediate node or router is important for troubleshooting. 458 Service discovery: [RFC6763] specifies "DNS-based Service Discovery" 459 and section 11 specifically describes how PTRs are used. 461 As a general guideline, when address assignment and name are under 462 the same authority, or when a host has a static address and name, 463 AAAA and PTR records should exist and match. For residential users, 464 if these four use cases are important to the ISP, the administrator 465 will then need to consider how to provide PTR records. 467 The best accuracy would be achieved if ISPs delegate authority along 468 with address delegation, but residential users rarely have domain 469 names or authoritative name servers. 471 Dynamic DNS updates can provide accurate data, but there is no 472 standard way to indicate to residential devices where to send 473 updates, if the hosts support it, and if it scales. 475 An ISP has no knowledge of its residential users' hostnames, and 476 therefore can either provide a wildcard response or a dynamically 477 generated response. A valid negative response (such as NXDomain) is 478 a valid response, if the four cases above are not essential; lame 479 delegation should be avoided. 481 5. Security and Privacy Considerations 483 5.1. Using Reverse DNS for Security 485 Some people think the existence of reverse DNS records, or matching 486 forward and reverse DNS records, provides useful information about 487 the hosts with those records. For example, one might infer that the 488 administrator of a network with properly configured DNS records was 489 better-informed, and by further inference more responsible, than the 490 administrator of a less-thoroughly configured network. For instance, 491 most email providers will not accept incoming connections on port 25 492 unless forward and reverse DNS entries match. If they match, but 493 information higher in the stack (for instance, mail source) is 494 inconsistent, the packet is questionable. These records may be 495 easily forged though, unless DNSSEC or other measures are taken. The 496 string of inferences is questionable, and may become unneeded if 497 other means for evaluating trustworthiness (such as positive 498 reputations) become predominant in IPv6. 500 Providing location information in PTR records is useful for 501 troubleshooting, law enforcement, and geolocation services, but for 502 the same reasons can be considered sensitive information. 504 5.2. DNS Security with Dynamic DNS 506 Security considerations of using dynamic DNS are described in 507 [RFC3007]. DNS Security Extensions are documented in [RFC4033]. 509 Interactions with DNSSEC are described throughout this document. 511 5.3. Considerations for Other Uses of the DNS 513 Several methods exist for providing encryption keys in the DNS. Any 514 of the options presented here may interfere with these key 515 techniques. 517 6. Privacy Considerations 519 Given considerations in [hostname], hostnames that provide 520 information about a user compromises that user's privacy. Some users 521 may want to identify their hosts using user-specified hostnames, but 522 the default behavior should not be to identify a user, their 523 location, their connectivity, or other information in a PTR record. 525 7. Acknowledgements 527 The author would like to thank Alain Durand, JINMEI Tatuya, David 528 Freedman, Andrew Sullivan, Chris Griffiths, Darryl Tanner, Ed Lewis, 529 John Brzozowski, Chris Donley, Wes George, Jason Weil, John Spence, 530 Ted Lemon, Stephan Lagerholm, Steinar Haug, Mark Andrews, Chris 531 Roosenraad, Fernando Gont, John Levine, and many others who discussed 532 and provided suggestions for this document. 534 8. IANA Considerations 536 There are no IANA considerations or implications that arise from this 537 document. 539 9. References 541 9.1. Normative References 543 [RFC1033] Lottor, M., "Domain Administrators Operators Guide", 544 November 1987. 546 [RFC1912] Barr, D., "Common DNS Operational and Configuration 547 Errors", February 1996. 549 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 550 "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1917. 552 [RFC2845] "Secret Key Transaction Authentication for DNS (TSIG)". 554 [RFC2865] "Remote Authentication Dial In User Service (RADIUS)". 556 [RFC2866] "RADIUS Accounting". 558 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 559 Update", November 2000. 561 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host 562 Configuration Protocol for IPv6 (DHCPv6)", December 2003. 564 [RFC4033] "DNS Security Introduction and Requirements". 566 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 567 Rose, "Protocol Modifications for the DNS Security Extensions", March 568 2005. 570 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 571 System", July 2006. 573 [RFC4704] Stapp, M., Volz, Y., and Y. Rekhter, "The Dynamic Host 574 Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified 575 Domain Name (FQDN) Option". 577 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 578 Address Autoconfiguration", September 2007. 580 [RFC4941] "Privacy Extensions for Stateless Address Autoconfiguration 581 in IPv6". 583 [RFC6106] "IPv6 Router Advertisement Options for DNS Configuration". 585 [RFC6763] Cheshire, S., and Krochmal, M., "DNS-Based Service 586 Discovery", February 2013. 588 9.2. Informative References 590 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 591 ADDR.ARPA delegation", March 1998. 593 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 594 Considerations and Issues with IPv6 DNS", April 2006. 596 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 597 Customer Premises Equipment (CPE) for Providing Residential IPv6 598 Internet Service", January 2011. 600 [inaddr-reqd] Senie, D., "draft-ietf-dnsop-inaddr-required-07", 601 August 2005. 603 [rmap-consider] Senie, D. and A. Sullivan, "draft-ietf-dnsop- 604 reverse-mapping-considerations-06", March 2008. 606 [hostname] Huitema, C., Thaler, D., and R. Winter, "draft-ietf- 607 intarea-hostname-practice", February 2017. 609 Author's Address 610 Lee Howard 611 Retevia 612 Fairfax, VA 22032 613 USA 615 Email: lee.howard@retevia.net