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