RFC 4472
Operational Considerations and Issues with IPv6 DNS
📜 RFC 4472: Operational Considerations and Issues with IPv6 DNS 🌸
okay bestie, this one is RFC 4472 💖 (RFC = Request for Comments, the docs that define how the internet works). It's titled Operational Considerations and Issues with IPv6 DNS. It's from the Network Working Group and was written by A. Durand (Comcast), J. Ihren (Autonomica), and P. Savola (CSC/FUNET). It's marked Category: Informational and dated April 2006 ✨. It doesn't list anything it obsoletes or updates, so it's a standalone doc 🫶
Status of This Memo
this memo gives info to the internet community 🧚 it does not specify an Internet standard of any kind. distribution of this memo is unlimited 🦋
Copyright Notice
Copyright (C) The Internet Society (2006). 💅
Abstract
so the abstract is giving full overview 🔥 it covers operational considerations and issues with IPv6 DNS, like a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations for doing DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. it's aimed at people who already know IPv4 DNS and want a summary of the IPv6 stuff 🍓
Table of Contents
1. Introduction ....................................................3
1.1. Representing IPv6 Addresses in DNS Records .................3
1.2. Independence of DNS Transport and DNS Records ..............4
1.3. Avoiding IPv4/IPv6 Name Space Fragmentation ................4
1.4. Query Type '*' and A/AAAA Records ..........................4
2. DNS Considerations about Special IPv6 Addresses .................5
2.1. Limited-Scope Addresses ....................................5
2.2. Temporary Addresses ........................................5
2.3. 6to4 Addresses .............................................5
2.4. Other Transition Mechanisms ................................5
3. Observed DNS Implementation Misbehavior .........................6
3.1. Misbehavior of DNS Servers and Load-balancers ..............6
3.2. Misbehavior of DNS Resolvers ...............................6
4. Recommendations for Service Provisioning Using DNS ..............7
4.1. Use of Service Names instead of Node Names .................7
4.2. Separate vs. the Same Service Names for IPv4 and IPv6 ......8
4.3. Adding the Records Only When Fully IPv6-enabled ............8
4.4. The Use of TTL for IPv4 and IPv6 RRs .......................9
4.4.1. TTL with Courtesy Additional Data ...................9
4.4.2. TTL with Critical Additional Data ..................10
4.5. IPv6 Transport Guidelines for DNS Servers .................10
5. Recommendations for DNS Resolver IPv6 Support ..................10
5.1. DNS Lookups May Query IPv6 Records Prematurely ............10
5.2. Obtaining a List of DNS Recursive Resolvers ...............12
5.3. IPv6 Transport Guidelines for Resolvers ...................12
6. Considerations about Forward DNS Updating ......................13
6.1. Manual or Custom DNS Updates ..............................13
6.2. Dynamic DNS ...............................................13
7. Considerations about Reverse DNS Updating ......................14
7.1. Applicability of Reverse DNS ..............................14
7.2. Manual or Custom DNS Updates ..............................15
7.3. DDNS with Stateless Address Autoconfiguration .............16
7.4. DDNS with DHCP ............................................17
7.5. DDNS with Dynamic Prefix Delegation .......................17
8. Miscellaneous DNS Considerations ...............................18
8.1. NAT-PT with DNS-ALG .......................................18
8.2. Renumbering Procedures and Applications' Use of DNS .......18
9. Acknowledgements ...............................................19
10. Security Considerations .......................................19
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................22
Appendix A. Unique Local Addressing Considerations for DNS ........24
Appendix B. Behavior of Additional Data in IPv4/IPv6
Environments ..........................................24
B.1. Description of Additional Data Scenarios ..................24
B.2. Which Additional Data to Keep, If Any? ....................26
B.3. Discussion of the Potential Problems ......................271. Introduction ✨
this memo is an extensive summary and a list of pointers for more info about IPv6 DNS considerations, written for people who already know IPv4 DNS 💅
the purpose of this doc is to share info about various issues and considerations for DNS operations with IPv6. it is not meant to be a normative specification or standard for IPv6 DNS 🎀
the first section gives a quick overview of how IPv6 addresses and names are represented in DNS, how transport protocols and resource records (don't) relate, and what IPv4/IPv6 name space fragmentation means and how to avoid it. all of this is covered in more depth in other docs 🦋
the second section covers the special IPv6 address types and how they relate to DNS. the third section describes DNS implementation misbehaviors that have a varying effect on using IPv6 records with DNS 🙈 the fourth section has recommendations and considerations for provisioning services with DNS. the fifth section looks at recommendations for providing IPv6 support in resolvers. the sixth and seventh sections cover forward and reverse DNS updates, respectively. the eighth section brings in some miscellaneous IPv6 issues related to DNS that didn't have a better home 🌈 Appendix A takes a quick look at the requirements for unique local addressing, and Appendix B talks about additional data 💜
1.1. Representing IPv6 Addresses in DNS Records
in forward zones, IPv6 addresses are represented with AAAA records. in reverse zones, IPv6 addresses are represented with PTR records in the nibble format under the ip6.arpa. tree. see [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152] for background info ⭐
one thing to note: using A6 records in the forward tree or Bitlabels in the reverse tree is not recommended [RFC3363]. using DNAME records is not recommended in the reverse tree together with A6 records. the document did not mean to take a stance on any other use of DNAME records [RFC3364] 🔥
1.2. Independence of DNS Transport and DNS Records
DNS was designed to present a single, globally unique name space [RFC2826]. this property should be maintained, as described here and in Section 1.3 🫶
the IP version used to transport DNS queries and responses is independent of the records being queried: AAAA records can be queried over IPv4, and A records over IPv6. the DNS servers must not make any assumptions about what data to return for Answer and Authority sections based on the underlying transport used in a query 🙅♀️
however, there's some debate about whether the addresses in the Additional section could be selected or filtered using hints from which transport was being used. this has some obvious problems. in many cases the transport protocol doesn't correlate with the requests, and a "bad" answer is kind of worse than no answer at all 💀 (imagine the client is led to believe a name in the additional record has no AAAA records at all, when it really does)
as stated in [RFC3596]:
The IP protocol version used for querying resource records is independent of the protocol version of the resource records; e.g., IPv4 transport can be used to query IPv6 records and vice versa.
1.3. Avoiding IPv4/IPv6 Name Space Fragmentation
to keep the DNS name space from splitting into parts that are only visible over IPv4 (or IPv6) transport, the recommendation is to always keep at least one authoritative server IPv4-enabled, and to make sure recursive DNS servers support IPv4. see DNS IPv6 transport guidelines [RFC3901] for more info 🧚
1.4. Query Type '*' and A/AAAA Records
QTYPE=* is typically only used for debugging or management purposes 🛠️ it's worth remembering that QTYPE=* ("ANY" queries) only returns whatever RRsets are available, not all the RRsets. caches don't necessarily have every RRset and have no way of guaranteeing they do. so to get both A and AAAA records reliably, two separate queries must be made 🍓
2. DNS Considerations about Special IPv6 Addresses 👑
there are a couple of IPv6 address types that are kinda special, and we're going to look at them here 🌸
2.1. Limited-Scope Addresses
the IPv6 addressing architecture [RFC4291] includes two kinds of local-use addresses: link-local (fe80::/10) and site-local (fec0::/10). site-local addresses have been deprecated [RFC3879] but are discussed with unique local addresses in Appendix A 🙈
link-local addresses should never be published in DNS (in either the forward or reverse tree), because they only have local significance to the connected link [WIP-DC2005] 🚫
2.2. Temporary Addresses
temporary addresses defined in RFC 3041 [RFC3041] (sometimes called "privacy addresses") use a random number as the interface identifier. having DNS AAAA records that are updated to always contain a node's current temporary address would defeat the purpose of the mechanism, and is not recommended 😬 however, it would still be possible to return a non-identifiable name (for example, the IPv6 address in hexadecimal format), as described in [RFC3041] 🦋
2.3. 6to4 Addresses
6to4 [RFC3056] specifies an automatic tunneling mechanism that maps a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48 🧁
if reverse DNS population would be desirable (see Section 7.1 for applicability), there are a few possible ways to do it 🤔
[WIP-H2005] aims to design an autonomous reverse-delegation system. anyone who is capable of communicating using a specific 6to4 address would be able to set up a reverse delegation to the corresponding 6to4 prefix. this could be deployed by, for example, Regional Internet Registries (RIRs). it's a practical solution, but it may have some scalability concerns 📈
2.4. Other Transition Mechanisms
6to4 is mentioned as a case of an IPv6 transition mechanism that needs special considerations. in general, mechanisms that include a special prefix may need a custom solution. otherwise, for example, when an IPv4 address is embedded as the suffix or not embedded at all, special solutions are likely not needed 💖
note that it doesn't seem feasible to provide reverse DNS with another automatic tunneling mechanism, Teredo [RFC4380]. this is because the IPv6 address is based on the IPv4 address and UDP port of the current Network Address Translation (NAT) mapping, which is likely to be relatively short-lived 🌩️
3. Observed DNS Implementation Misbehavior ✨
okay so the DNS world has a messy closet 🙈 Several classes of misbehavior in DNS servers, load-balancers, and resolvers have been observed. Most of these are pretty generic (not just an IPv6 thing!), but in some cases the consequences are extremely severe in IPv6 environments, so they deserve a shoutout 📣.
3.1. Misbehavior of DNS Servers and Load-balancers
There are several classes of misbehavior in certain DNS servers and load-balancers that have been noticed and documented [RFC4074]. Some implementations silently drop queries for unimplemented DNS records types, or give wrong answers to those queries instead of a proper negative reply 😭. These issues aren't limited to AAAA records, but they get worse because AAAA records are being queried instead of (mainly) A records.
The problems are serious because when you look up a DNS name, typical getaddrinfo() implementations with the AF_UNSPEC hint given first try to query the AAAA records of the name. After they get a response, they query the A records. This happens in a serial fashion, so if the first query is never responded to (instead of returning a negative answer properly), significant time-outs will occur 💀.
In consequence, this is an enormous problem for IPv6 deployments. In some cases, IPv6 support in the software has even been disabled because of these problems 🥀.
The solution is to fix or retire those misbehaving implementations, but that is likely not going to be effective. There are some possible ways to mitigate the problem, e.g., by performing the lookups somewhat in parallel and reducing the time-out as long as at least one answer has been received. But such methods remain to be investigated. Slightly more on this is included in Section 5 🔍.
3.2. Misbehavior of DNS Resolvers
Several classes of misbehavior have also been noticed in DNS resolvers [WIP-LB2005]. However, these don't seem to directly impair IPv6 use, so they're only mentioned for completeness 🫶.
4. Recommendations for Service Provisioning Using DNS
When names are added in the DNS to facilitate a service, there are several general guidelines to consider so you can do it as smoothly as possible 🎀.
4.1. Use of Service Names instead of Node Names
It makes sense to keep information about separate services logically separate in the DNS by using a different DNS hostname for each service. There are several reasons for this, for example:
- It allows more flexibility and ease for migration of (only a part of) services from one node to another,
- It allows configuring different properties (e.g., Time to Live (TTL)) for each service, and
- It allows deciding separately for each service whether or not to publish the IPv6 addresses (in cases where some services are more IPv6-ready than others) 🧚
Using SRV records [RFC2782] would avoid these problems. Unfortunately, those aren't widely used enough to be applicable in most cases 😩. So an operational technique is to use service names instead of node names (or "hostnames"). This operational technique isn't specific to IPv6, but it's required to understand the considerations described in Section 4.2 and Section 4.3.
For example, say a node named pobox.example.com provides both SMTP and IMAP service. Instead of configuring the MX records to point at pobox.example.com, and configuring the mail clients to look up the mail via IMAP from pobox.example.com, one could use, e.g., smtp.example.com for SMTP (for both message submission and mail relaying between SMTP servers) and imap.example.com for IMAP 💌. Note that in the specific case of SMTP relaying, the server itself must typically also be configured to know all its names to ensure that loops do not occur. DNS can provide a layer of indirection between service names and where the service actually is, and which addresses are used. (Obviously, when you want to reach a specific node, you should use the hostname rather than a service name 🙈.)
4.2. Separate vs. the Same Service Names for IPv4 and IPv6
The service naming can be achieved in basically two ways. When a service is named service.example.com for IPv4, the IPv6-enabled service could either be added to service.example.com, or added separately under a different name, e.g., in a sub-domain like service.ipv6.example.com 🌈.
These two methods have different characteristics. Using a different name makes service piloting easier and minimizes the disturbance to the "regular" users of the IPv4 service. However, the service wouldn't be used transparently. The user or application would have to explicitly find it and ask for it, which would be a disadvantage in most cases 😬. When the different name is under a sub-domain, if the services are deployed within a restricted network (e.g., inside an enterprise), it's possible to prefer them transparently, at least to a degree, by modifying the DNS search path. But this is a suboptimal solution. Using the same service name is the "long-term" solution, but it may degrade performance for clients whose IPv6 performance is lower than their IPv4 performance, or who don't work as well over IPv6 (see Section 4.3 for more) ⭐.
In most cases, it makes sense to pilot or test a service using separate service names, and move to using the same name once you're confident the service level won't degrade for users who are unaware of IPv6 💖.
4.3. Adding the Records Only When Fully IPv6-enabled
The recommendation is that AAAA records for a service should not be added to the DNS until all of the following are true:
- The address is assigned to the interface on the node.
- The address is configured on the interface.
- The interface is on a link that is connected to the IPv6 infrastructure.
In addition, if the AAAA record is added for the node, instead of for the service as recommended, all the services of the node should be IPv6-enabled prior to adding the resource record 🔥.
For example, if an IPv6 node is isolated from an IPv6 perspective (e.g., it is not connected to the IPv6 Internet), constraint #3 would mean that it should not have an address in the DNS 🙅♀️.
Consider the case of two dual-stack nodes, which are both IPv6-enabled, but the server does not have (global) IPv6 connectivity. When the client looks up the server's name, only A records are returned (if the recommendations above are followed). No IPv6 communication, which would have been unsuccessful, is even attempted 🧁.
The issues aren't always so black-and-white. Usually, it's important that the service offered over both protocols is of roughly equal quality, using the appropriate metrics for the service (e.g., latency, throughput, low packet loss, general reliability, etc.). This is typically very important, especially for interactive or real-time services 🎮. In many cases, the quality of IPv6 connectivity may not yet be equal to that of IPv4, at least globally. This has to be taken into consideration when enabling services 🧐.
4.4. The Use of TTL for IPv4 and IPv6 RRs
The behavior of DNS caching when different TTL values are used for different RRsets of the same name calls for explicit discussion. For example, let's consider two unrelated zone fragments:
example.com. 300 IN MX foo.example.com.
foo.example.com. 300 IN A 192.0.2.1
foo.example.com. 100 IN AAAA 2001:db8::1
...
child.example.com. 300 IN NS ns.child.example.com.
ns.child.example.com. 300 IN A 192.0.2.1
ns.child.example.com. 100 IN AAAA 2001:db8::1In the former case, we have "courtesy" additional data. In the latter, we have "critical" additional data. See a more extensive background discussion of additional data handling in Appendix B 📚.
4.4.1. TTL with Courtesy Additional Data
When a caching resolver asks for the MX record of example.com, it gets back foo.example.com. It may also get back either one or both of the A and AAAA records in the additional section. The resolver must explicitly query for both A and AAAA records [RFC2821] 🔎.
After 100 seconds, the AAAA record is removed from the cache(s) because its TTL expired. It could be argued that it's useful for caching resolvers to discard the A record when the shorter TTL (in this case, the one for the AAAA record) expires. This would avoid the situation where there's a window of 200 seconds when incomplete information is returned from the cache 🤔. Further argument for discarding is that in normal operation the TTL values are so high that the additional queries incurred would very likely not be noticeable, compared to the performance optimization obtained 🚀. The behavior in this scenario is unspecified.
4.4.2. TTL with Critical Additional Data
The difference from courtesy additional data is that the A/AAAA records served by the parent zone can't be queried explicitly. So after 100 seconds the AAAA record is removed from the cache(s), but the A record remains. Queries for the remaining 200 seconds (provided there are no further queries from the parent that could refresh the caches) only return the A record. That can lead to a potential operational situation with unreachable servers 😱.
Similar cache flushing strategies apply in this scenario, and the behavior is likewise unspecified.
4.5. IPv6 Transport Guidelines for DNS Servers
As described in Section 1.3 and [RFC3901], there should continue to be at least one authoritative IPv4 DNS server for every zone, even if the zone has only IPv6 records. (Note that obviously, having more servers with robust connectivity would be preferable, but this is the minimum recommendation. Also see [RFC2182].) 🛡️
5. Recommendations for DNS Resolver IPv6 Support
When IPv6 is enabled on a node, there are several things to consider to make sure the process is as smooth as possible 🦋.
5.1. DNS Lookups May Query IPv6 Records Prematurely ✨
okay so the system library that runs the getaddrinfo() function is a huge deal when you're thinking about whether IPv6 is robust enough to turn on. it can come in basically three flavors 💅
- the system library doesn't know whether IPv6 is enabled in the OS kernel. it might start looking up AAAA records with
getaddrinfo()and theAF_UNSPEChint as soon as the system gets upgraded to a library version that supports IPv6 💀 - the system library might only start doing IPv6 queries with
getaddrinfo()once IPv6 is enabled in the kernel. BUT that doesn't guarantee there's any useful IPv6 connectivity, bestie. the node could be isolated from the other IPv6 networks and only have link-local addresses 🙈 - the system library might have a toggle that runs some heuristics on how "IPv6-ready" the node is before it starts querying. for example, it could check whether only link-local IPv6 address(es) exist, or whether at least one global IPv6 address exists 🧚
okay, first let's talk about the general problem with unnecessary AAAA queries. when you look up everything in the DNS, AAAA records usually get tried first, and then A records. these happen in serial, so the A query doesn't even start until the AAAA response comes back. with the misbehavior of DNS servers and load-balancers from Section 3.1, that AAAA lookup delay can add extra latency and make things a little unreliable 😭
one option here is to do the queries partially in parallel. for example, if the final response to the AAAA query hasn't arrived in 0.5 seconds, start the A query while you wait for the result. (immediate parallelism might not be optimal, at least without information-sharing between the lookup threads, because that would probably lead to duplicate non-cached delegation chain lookups 🔥)
there's another concern too: address selection. in some circumstances it may prefer AAAA records over A records even when the node has no IPv6 connectivity at all [WIP-RDP2004]. in some cases the implementation may try to connect or send a datagram on a physical link [WIP-R2006], which means very long protocol time-outs instead of a quick fallback to IPv4. not it 😤
now let's look at each of the three possibilities:
in the first case, the node does a bunch of completely useless DNS lookups, because it won't be able to use the AAAA records it gets back anyway. (the only exception is when the application wants to know what's in the DNS but doesn't plan to use the result for communication 🤓) you should be able to turn these unnecessary queries off, for both latency and reliability reasons. but since IPv6 isn't enabled, connections to IPv6 addresses fail immediately, and if the application is programmed properly, it can fall back gracefully to IPv4 [RFC4038] ✨
the second case is similar to the first, but it happens to a smaller set of nodes: the ones where IPv6 is enabled but connectivity hasn't been provided yet. similar considerations apply, except that IPv6 records, when they're returned, will actually get tried first, which can lead to long time-outs 😩
the third case is a bit more complicated 🎀 optimizing away the DNS lookups for link-local-only nodes is probably safe (though it may be desirable with different lookup services that getaddrinfo() might support). the reason is that link-local addresses are typically generated automatically when IPv6 is enabled, and they don't indicate any form of IPv6 connectivity. so performing DNS lookups only when a non-link-local address has been configured on any interface could be beneficial -- that would be a sign the address came from a router advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], or manual configuration. each of those indicates at least some form of IPv6 connectivity, even though there are no guarantees 💜
these issues should be analyzed in more depth, and fixes should be agreed on, perhaps in a separate document 🌸
5.2. Obtaining a List of DNS Recursive Resolvers 🦋
when DHCPv6 is available, a host can discover a list of DNS recursive resolvers through the DHCPv6 "DNS Recursive Name Server" option [RFC3646]. this option can be passed to a host through a subset of DHCPv6 [RFC3736] ✨
the IETF is considering developing alternative mechanisms for getting the list of DNS recursive name servers when DHCPv6 is unavailable or inappropriate. as of this writing, no decision has been made about taking on that work [RFC4339] 🤔
when DHCPv6 is unavailable or inappropriate, the mechanisms under consideration for development include the use of [WIP-O2004] and the use of Router Advertisements to convey the information [WIP-J2006] 🫶
note that even though IPv6 DNS resolver discovery is a recommended procedure, it is not required for dual-stack nodes in dual-stack networks, because IPv6 DNS records can be queried over IPv4 as well as IPv6. obviously, nodes that are meant to work without manual configuration in IPv6-only networks must implement the DNS resolver discovery function 👑
5.3. IPv6 Transport Guidelines for Resolvers 🌈
as described in Section 1.3 and [RFC3901], recursive resolvers should be IPv4-only or dual-stack so they can reach any IPv4-only DNS server. this requirement is also met by an IPv6-only stub resolver pointing at a dual-stack recursive DNS resolver 💖
6. Considerations about Forward DNS Updating 🍓
forward DNS updating (how to get names mapping to the correct new addresses) isn't specific to IPv6, but it deserves extra attention now that Stateless Address Autoconfiguration [RFC2462] is here 🌟
forward DNS updates are typically more manageable than reverse ones, because the updater can often be assumed to "own" a certain DNS name. that means we can set up a kind of security relationship between the DNS name and the node that's allowed to update it to point at a new address 🔐
a more complex kind of DNS update, where you add a whole new name into a DNS zone instead of updating an existing one, is out of scope for this memo, since it could require zone-wide authentication. adding a new name to the forward zone is still being explored with IPv4, and IPv6 doesn't seem to add much new in that area 🙃
6.1. Manual or Custom DNS Updates 🛠️
DNS mappings can also be maintained by hand, in a semi-automatic fashion, or by running non-standardized protocols. this memo doesn't go into those at more length 🫠
6.2. Dynamic DNS ⚡
Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] are a standardized mechanism for updating the DNS dynamically. it works equally well with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual address configuration. it's important to think about how each of these behaves if IP address-based authentication, instead of stronger mechanisms [RFC3007], is used in the updates 👀
- manual addresses are static and can be configured.
- DHCPv6 addresses could be reasonably static or dynamic, depending on the deployment, and could or could not be configured on the DNS server for the long term.
- SLAAC addresses are typically stable for a long time, but could require work to configure and maintain.
relying on IP addresses for Dynamic DNS is rather insecure at best, so stronger authentication should always be used. however, that requires the authorization keying to be explicitly configured using unspecified operational methods 🔑
note that with DHCP, the DHCP server can also update the DNS instead of the host. the host might only indicate in the DHCP exchange which hostname it would prefer, and then the DHCP server makes the appropriate updates. this makes setting up a secure channel between the updater and the DNS server easier, but it doesn't help much with "content" security (whether the hostname was acceptable). if the DNS server doesn't include policies, they must be included in the DHCP server. for example, a regular host shouldn't be able to say its name is "www.example.com" 🙅♀️ DHCP-initiated DDNS updates have been extensively described in [WIP-SV2005], [WIP-S2005a], and [WIP-S2005b] 📚
the nodes must somehow be configured with the information about the servers where they'll try to update their addresses, enough security material to authenticate themselves to the server, and the hostname they'll be updating. unless otherwise configured, the first can be found by looking up the authoritative name servers for the hostname. the second must be configured explicitly unless someone chooses to trust IP address-based authentication (not a good idea 💀). lastly, the nodename is typically pre-configured somehow on the node, for example at install time 🧸
be careful not to use longer TTLs for addresses than the preferred lifetimes of those addresses when you update them. that way, if the node is renumbered in a managed way, the amount of stale DNS information stays to a minimum. basically, if the preferred lifetime of an address expires, the TTL of the record needs to be modified unless it was already done before the expiration ⏰ for more flexibility, the DNS TTL should be much shorter (say, a half or a third) than the address's lifetime. that way, the node can start lowering the DNS TTL if it seems like the address hasn't been renewed or refreshed in a while. some discussion on how an administrator could manage the DNS TTL is in [RFC4192], and this could be applied to (smart) hosts as well 🌷
7. Considerations about Reverse DNS Updating 🔄
updating the reverse DNS zone can be difficult because of the split authority over an address. but first we have to think about whether reverse DNS even applies in the first place 🤔✨
7.1. Applicability of Reverse DNS ✨
Okay so, some apps peek at reverse DNS to get hints about the topology behind an address (like when they're making sense of web server access logs). Others use it as a super weak security check to see if the network admin has "authorized" the address, on the premise that adding a reverse record signals some kind of authorization. 💅
A slightly more useful trick is making sure reverse and forward DNS agree. You look up the pointer name from the IP in the reverse tree, then check that a record under that name in the forward tree points back to the IP, and that it matches a name or domain you configured. 🔍 As a security check, this usually comes with other stuff like a user/password login. The main job of the reverse+forward check is to weed out most unauthorized users, and anyone who slips past it still has to authenticate "properly." 🙅♀️
It might also be desirable to store IPsec keying material for an IP address in reverse DNS, as justified and described in [RFC4025]. 🔐
Whether it makes sense to require or recommend updating reverse DNS records is genuinely unclear 🤔. Honestly, in lots of cases it just makes more sense to use proper security or topology lookup mechanisms in the first place. At the very least, apps that treat the mere existence of a record as generic authorization should be changed ASAP so they skip those lookups completely 🚨.
The applicability is discussed at more length in [WIP-S2005c]. 📚
7.2. Manual or Custom DNS Updates 🛠️
Reverse DNS can totally be updated with manual or custom methods. We're not going into those, except for one special case. 💖
One way to deploy reverse DNS is with wildcard records, like configuring one name for a whole subnet (/64) or site (/48). For example, a site (or its ISP) could point the reverses of 2001:db8:f00::/48 at one name using a wildcard record like *.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR site.example.com.. Naturally that name can't be verified from the forward DNS, but it can still give some "topological information" or "weak authorization" if that's considered useful 🌸.
Quick note: this isn't really updating the DNS, since the whole point is avoiding DNS updates entirely by manually configuring one generic name ✨.
7.3. DDNS with Stateless Address Autoconfiguration 🦋
Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in one way and harder in another, as you'll see below. 👀
The address space administrator decides whether the hosts are trusted to update their reverse DNS records. If they're trusted and deployed at the same site (not across the Internet), a simple address-based authorization is typically sufficient (i.e., check that the DNS update comes from the same IP address as the record being updated). Stronger security can also be used [RFC3007]. If hosts aren't allowed to update the reverses, no update can occur. However, address-based update authorization operationally requires that ingress filtering [RFC3704] has been set up at the border of the site where the updates happen, and as close to the updater as possible 🚧.
Address-based authorization is simpler with reverse DNS (since there's a connection between the record and the address) than with forward DNS. But when a stronger form of security is used, forward DNS updates are simpler to manage, because the host can be assumed to have an association with the domain. Users may roam to different networks and don't necessarily have any association with the owner of that address space, so assuming a stronger form of authorization for reverse DNS updates than an address association is generally infeasible 🙃.
Moreover, the reverse zones must be cleaned up by an unspecified janitorial process 🧹. The node doesn't typically know a priori that it will be disconnected, and it can't send a DNS update using the correct source address to remove a record.
Defining the clean-up process is tricky, because it's hard to make sure a specific IP address and its corresponding record are no longer being used. Considering the huge address space and the unlikelihood of collision within the 64 bits of the interface identifiers, one possible approach is a process that removes the record after no traffic has been seen from a node for a long period (e.g., a month or year) 📅.
To insert or update the record, the node has to discover the DNS server to send the update to somehow, similar to what's discussed in Section 6.2. One way to automate this is looking up the authoritative DNS server (e.g., through the SOA record) for the IP address being updated, but the security material (unless IP address-based authorization is trusted) must also be established by some other means 🔑.
One thing to note: Cryptographically Generated Addresses (CGAs) [RFC3972] may need a slightly different kind of treatment 🧚. CGAs are addresses where the interface identifier is calculated from a public key, a modifier (used as a nonce), the subnet prefix, and other data. Depending on the usage profile, CGAs might or might not be changed periodically due to, e.g., privacy reasons. As the CGA address isn't predictable, a reverse record can only reasonably be inserted in the DNS by the node that generates the address.
7.4. DDNS with DHCP 📬
With DHCPv4, the reverse DNS name is typically already inserted into the DNS, reflecting the name (e.g., dhcp-67.example.com). One can assume similar practice may become commonplace with DHCPv6 as well, and all such mappings would be pre-configured and need no updating ✨.
If more explicit control is required, similar considerations as with SLAAC apply, except that typically one must update a reverse DNS record instead of inserting one (if an address assignment policy that reassigns disused addresses is adopted), and updating a record seems like a slightly more difficult thing to secure. However, it's still uncertain how DHCPv6 is going to be used for address assignment 🤷♀️.
Note that when using DHCP, either the host or the DHCP server could perform the DNS updates. See the implications in Section 6.2 📝.
If disused addresses were to be reassigned, host-based DDNS reverse updates would need policy considerations for DNS record modification, as noted above. On the other hand, if disused addresses were not to be assigned, host-based DNS reverse updates would have similar considerations as SLAAC in Section 7.3. Server-based updates have similar properties, except that the janitorial process could be integrated with DHCP address assignment 🎀.
7.5. DDNS with Dynamic Prefix Delegation 🌈
In cases where a prefix, instead of an address, is being used and updated, you should think about where the server handling DDNS updates is located. That is, where the DNS server sits:
- At the same organization as the prefix delegator.
- At the site where the prefixes are delegated to. In this case, the authority of the DNS reverse zone corresponding to the delegated prefix is also delegated to the site.
- Elsewhere. This implies a relationship between the site and where the DNS server is located, and such a relationship should be rather straightforward to secure as well. As in the previous case, the authority of the DNS reverse zone is also delegated.
In the first case, managing the reverse DNS (delegation) is simpler, since the DNS server and the prefix delegator are in the same administrative domain (so there's no need to delegate anything at all). Alternatively, the prefix delegator might forgo DDNS reverse capability altogether and use, e.g., wildcard records (as described in Section 7.2). In the other cases, it can be a bit more difficult, particularly since the site will have to configure the DNS server to be authoritative for the delegated reverse zone, which implies automatic configuration of the DNS server, because the prefix may be dynamic 🌀.
Managing DDNS reverse updates is typically simple in the second case, since the updated server is located at the local site, and arguably IP address-based authentication could be sufficient (or, if not, setting up security relationships would be simpler). Because there's an explicit (security) relationship between the parties in the third case, setting up security relationships to allow reverse DDNS updates should be rather straightforward as well (but IP address-based authentication might not be acceptable). In the first case, however, setting up and managing such relationships might be a lot more difficult 😩.
8. Miscellaneous DNS Considerations 🧩
This section describes miscellaneous DNS considerations that seem related to IPv6, for which no better place has been found in this document 💜.
8.1. NAT-PT with DNS-ALG 🙅
The DNS-ALG component of NAT-PT [RFC2766] mangles A records to look like AAAA records to the IPv6-only nodes. Numerous problems have been identified with [WIP-AD2005]. This is a strong reason not to use NAT-PT in the first place 💀.
8.2. Renumbering Procedures and Applications' Use of DNS 🔢
One of the most difficult problems of systematic IP address renumbering procedures [RFC4192] is that an application that looks up a DNS name disregards information such as the TTL, and uses the result obtained from DNS for as long as it happens to be stored in the application's memory. For applications that run for a long time, this could be days, weeks, or even months 😱. Some applications may be clever enough to organize their data structures and functions so that lookups get refreshed now and then.
While the issue appears to have a clear solution, "fix the applications", practically this isn't reasonable immediate advice. TTL information typically isn't available in the APIs and libraries (so the advice becomes "fix the applications, APIs, and libraries"), and a lot more analysis is needed on how to practically go about achieving the ultimate goal of avoiding using names longer than expected 🧐.
9. Acknowledgements 💖
Some recommendations (Section 4.3, Section 5.1) about IPv6 service provisioning were moved here from [RFC4213] by Erik Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided useful feedback and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark Andrews helped clarify the issues regarding additional data and the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and Rob Austein provided useful feedback during the WG last call. Thomas Narten provided extensive feedback during the IESG evaluation 🫶.
10. Security Considerations 🔐✨
okay bestie, so this doc is basically a review of the IPv6 DNS operational procedures, and it doesn't have any security considerations of its own 💅
but ngl, Dynamic DNS updates are where things get messy 😭. security models based on source address validation are super weak and cannot be recommended. they could only even be considered in environments where ingress filtering [RFC3704] has been deployed 🛡️. also, setting up an authorization mechanism (like a shared secret or public-private keys) between a node and the DNS server has to be done manually, and it may take a LOT of time and expertise 🥲
to re-emphasize what we already said (because it's that important 🙈), the reverse+forward DNS check gives you very weak security at best. the only kinda questionable security use for it might be alongside other mechanisms when you're authenticating a user. periodt 💀
11. References 📚
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton,
"Selection and Operation of Secondary DNS Servers",
BCP 16, RFC 2182, July 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
August 2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
Hain, "Representing Internet Protocol version 6 (IPv6)
Addresses in the Domain Name System (DNS)", RFC 3363,
August 2002.
[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)",
RFC 3364, August 2002.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736,
April 2004.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport
Operational Guidelines", BCP 91, RFC 3901,
September 2004.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior
Against DNS Queries for IPv6 Addresses", RFC 4074,
May 2005.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day",
RFC 4192, September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4339] Jeong, J., Ed., "IPv6 Host Configuration of DNS Server
Information Approaches", RFC 4339, February 2006.11.2. Informative References
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR
for specifying the location of services (DNS SRV)",
RFC 2782, February 2000.
[RFC2826] Internet Architecture Board, "IAB Technical Comment on
the Unique DNS Root", RFC 2826, May 2000.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3972] Aura, T., "Cryptographically Generated Addresses
(CGA)", RFC 3972, March 2005.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks",
RFC 4215, October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[TC-TEST] Jinmei, T., "Thread "RFC2181 section 9.1: TC bit
handling and additional data" on DNSEXT mailing list,
Message-
Id:y7vek9j9hyo.wl%jinmei@isl.rdc.toshiba.co.jp", August
1, 2005, <http://ops.ietf.org/lists/namedroppers/
namedroppers.2005/msg01102.html>.
[WIP-AD2005] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", Work in Progress, October 2005.
[WIP-DC2005] Durand, A. and T. Chown, "To publish, or not to
publish, that is the question", Work in Progress,
October 2005.
[WIP-H2005] Huston, G., "6to4 Reverse DNS Delegation
Specification", Work in Progress, November 2005.
[WIP-J2006] Jeong, J., "IPv6 Router Advertisement Option for DNS
Configuration", Work in Progress, January 2006.
[WIP-LB2005] Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", Work in Progress, February 2006.
[WIP-O2004] Ohta, M., "Preconfigured DNS Server Addresses", Work in
Progress, February 2004.
[WIP-R2006] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
Considered Harmful", Work in Progress, January 2006.
[WIP-RDP2004] Roy, S., Durand, A., and J. Paugh, "Issues with Dual
Stack IPv6 on by Default", Work in Progress, July 2004.
[WIP-S2005a] Stapp, M., "The DHCP Client FQDN Option", Work in
Progress, March 2006.
[WIP-S2005b] Stapp, M., "A DNS RR for Encoding DHCP Information
(DHCID RR)", Work in Progress, March 2006.
[WIP-S2005c] Senie, D., "Encouraging the use of DNS IN-ADDR
Mapping", Work in Progress, August 2005.
[WIP-SV2005] Stapp, M. and B. Volz, "Resolution of FQDN Conflicts
among DHCP Clients", Work in Progress, March 2006.Appendix A. Unique Local Addressing Considerations for DNS 🏡
unique local addresses [RFC4193] have replaced the now-deprecated site-local addresses [RFC3879]. from the DNS point of view, locally generated unique local addresses (LUL) and site-local addresses have pretty similar vibes 🦋
the interactions with DNS come in two flavors: forward and reverse DNS 🍓
to actually use local addresses inside a site, you're basically signing up for a "split-faced" or fragmented DNS name space, with one view for the zones inside the site and another view for outsiders 👀. the procedures for pulling that off aren't spelled out here. the takeaway is that local addresses must not be published in the public DNS 🚫
to make reverse DNS work with local addresses (if you want it), stub resolvers have to look for DNS info from the local DNS servers, not, e.g., starting from the root servers, so the local info can be provided locally 🧚. and honestly, the experience with private addresses in IPv4 shows that the root servers get loaded with private address lookups anyway 😭. this requirement is discussed in [RFC4193].
Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments 🌈
DNS responses don't always fit in a single UDP packet, so let's look at the cases where that happens because there's just too much data in the Additional section 🫶
B.1. Description of Additional Data Scenarios
okay so there are two kinds of additional data, and knowing the difference is kinda the whole game 🎀
- "critical" additional data: this must be included in all scenarios, with all the RRsets 🔒
- "courtesy" additional data: this could be sent in full, with only a few RRsets, or with no RRsets at all. It can also be fetched separately, but that means extra queries 🫶
The responding server can figure out algorithmically which type it's dealing with by checking whether the data is at or below a zone cut ✨
Only the additional data records that meet that condition count as "critical" or real "glue" 🧚. People call basically everything "glue" (even though it's technically not always), but the official definition is the one in Section 4.2.1 of [RFC1034]. So no cap, the rule is the rule 💅
Also, remember that resource record sets (RRsets) are never broken up 🍓. If a name has 4 A records and 5 AAAA records, you can return all 9, all 4 A records, all 5 AAAA records, or nothing. That's it. Notice that for "critical" additional data, getting all the RRsets can be critical too 👑
Now here's what [RFC2181] says (in Section 9):
a. If all the "critical" RRsets don't fit, the sender should set the TC bit, and the recipient should discard the whole response and retry using a mechanism that allows larger responses, such as TCP 😭
b. "courtesy" additional data should not cause the TC bit to be set. Instead, all the non-fitting additional data RRsets should be removed 🌸
An example of "courtesy" additional data is A/AAAA records alongside MX records, as shown in Section 4.4 💖 An example of "critical" additional data looks like this (where getting both the A and AAAA RRsets is critical with respect to the NS RR):
child.example.com. IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN AAAA 2001:db8::1When there's too much "courtesy" additional data, at least the non-fitting RRsets should be removed [RFC2181]. But since the additional data isn't critical, even all of it could be safely removed 🦋
When there's too much "critical" additional data, the TC bit has to be set, and the recipient should ignore the response and retry using TCP. If some data were to be left in the UDP response, the question is which data could be kept 🤔
Here's the tea, though: the practice doesn't always match the specification 🙈 Testing and code analysis of three recent implementations [TC-TEST] confirm this. None of the tested implementations have a strict separation of critical and courtesy additional data, and some forms of additional data get treated preferentially. All of the implementations remove some (critical or courtesy) additional data RRsets without setting the TC bit when the response wouldn't otherwise fit 💀
Failing to discard the response with the TC bit, or omitting critical information without setting the TC bit, leads to an unrecoverable problem. Omitting only some of the RRsets when all of them wouldn't fit (without setting the TC bit) leads to a performance problem. We'll talk about both in the next two subsections ✨
B.2. Which Additional Data to Keep, If Any?
NOTE: omitting some critical additional data instead of setting the TC bit violates a 'should' in Section 9 of RFC2181. However, as many implementations still do that [TC-TEST], operators need to understand its implications, so we describe that behavior as well 🚨
If an implementation decides to keep as much data as possible (whether "critical" or "courtesy") in UDP responses, it might be tempting to use the transport of the DNS query as a hint in either of these cases: return the AAAA records if the query was done over IPv6, or return the A records if the query was done over IPv4. But this breaks the model of independence of DNS transport and resource records, as noted in Section 1.2. Not it, bestie 🙅♀️
With courtesy additional data, as long as enough RRsets get removed so that TC won't be set, it's allowed to send as many complete RRsets as the implementation prefers 🍰 The implementations are also free to omit all such RRsets, even complete ones. Omitting all of them (when removing only some would suffice) may create a performance penalty, where the client may need to issue one or more additional queries to get necessary and/or consistent information 🥲
With critical additional data, the options are either returning nothing (and absolutely requiring a retry with TCP), or returning something in addition to setting the TC bit. Returning something also works if the recipient doesn't discard the response and retry using TCP 🎀 If the process for selecting "something" from the critical data would otherwise be practically "flipping the coin" between A and AAAA records, it could be argued that looking at the transport of the query would have a better chance of being right than just 50/50. In other words, if the returned critical additional data has to be selected somehow, something more sophisticated than a random process would seem justifiable 🧠
So leaving in some intelligently selected critical additional data is a trade-off. It optimizes for resolvers that ignore the "should discard" recommendation, but it risks a protocol problem by spreading inconsistent information about "critical" records through the caches 😬
Similarly, leaving in the complete courtesy additional data RRsets instead of removing all the RRsets is a performance trade-off, as described in the next section 🫧
B.3. Discussion of the Potential Problems
As noted above, the temptation to omit only some of the additional data can be problematic. We'll dig into that more below 🔍
For courtesy additional data, this causes a potential performance problem, because clients have to re-query for the potentially omitted RRsets. For critical additional data, it causes a potential unrecoverable problem if the response isn't discarded and the query isn't retried with TCP, since the nameservers might be reachable only through the omitted RRsets 😱
If an implementation looks at the transport used for the query, it's worth remembering that the host using the records is often different from the node that requested them from the authoritative DNS server (or even a caching resolver) 👀 So whichever version the requestor (e.g., a recursive server in the middle) uses makes no difference to the ultimate user of the records, whose transport capabilities might differ from the requestor's. This might result in, e.g., inappropriately returning A records to an IPv6-only node, which then goes through a translation, or opens up another IP-level session (e.g., a Packet Data Protocol (PDP) context [RFC4215]) 🌈 Therefore, at least in many scenarios, it would be very useful if the information returned were consistent and complete. If that isn't feasible, leave it to the client to query again 🫶
The problem of too much additional data seems to be an operational one: the zone administrator enters too many records, which then get returned truncated (or with some RRsets missing, depending on the implementation) to the users 🙃 A protocol fix for this is using Extension Mechanisms for DNS (EDNS0) [RFC2671] to signal the capacity for larger UDP packet sizes, which pushes up the relevant threshold ⭐ Further, DNS server implementations should omit courtesy additional data completely rather than including only some RRsets [RFC2181]. An operational fix for this is having DNS server implementations return a warning when administrators create zones that would result in too much additional data being returned 🔔 Further still, DNS server implementations should warn of or disallow zone configurations that are recursive or otherwise difficult to manage by the protocol 🧚♀️
Authors' Addresses
Alain Durand
Comcast
1500 Market St.
Philadelphia, PA 19102
USA
EMail: Alain_Durand@cable.comcast.com
Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm
Sweden
EMail: johani@autonomica.se
Pekka Savola
CSC/FUNET
Espoo
Finland
EMail: psavola@funet.fiFull Copyright Statement
Copyright (C) The Internet Society (2006). 💜
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 🔐
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE ⚠️
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights 🧾 Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🗂️
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🎉🌸
📦 where this page comes from
- ietf: rfc4472 2006-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms