diff options
| author | Doug Barton <dougb@FreeBSD.org> | 2010-02-07 22:14:10 +0000 |
|---|---|---|
| committer | Doug Barton <dougb@FreeBSD.org> | 2010-02-07 22:14:10 +0000 |
| commit | e6787144c0a7f2ccb1b75e05abbd390f0fd225cd (patch) | |
| tree | 50d7895dd5f9a44b6f2457ee55c873eba97cd43a /doc/rfc | |
| parent | fd8f060cacf6f8a8f24ef704e9c2b81f1063ac14 (diff) | |
Notes
Diffstat (limited to 'doc/rfc')
| -rw-r--r-- | doc/rfc/index | 21 | ||||
| -rw-r--r-- | doc/rfc/rfc1912.txt | 899 | ||||
| -rw-r--r-- | doc/rfc/rfc3755.txt | 507 | ||||
| -rw-r--r-- | doc/rfc/rfc4294.txt | 1123 | ||||
| -rw-r--r-- | doc/rfc/rfc4339.txt | 1459 | ||||
| -rw-r--r-- | doc/rfc/rfc4471.txt | 1291 | ||||
| -rw-r--r-- | doc/rfc/rfc4472.txt | 1627 | ||||
| -rw-r--r-- | doc/rfc/rfc4509.txt | 395 | ||||
| -rw-r--r-- | doc/rfc/rfc4635.txt | 451 | ||||
| -rw-r--r-- | doc/rfc/rfc4697.txt | 1011 | ||||
| -rw-r--r-- | doc/rfc/rfc4892.txt | 451 | ||||
| -rw-r--r-- | doc/rfc/rfc4955.txt | 395 | ||||
| -rw-r--r-- | doc/rfc/rfc4956.txt | 955 | ||||
| -rw-r--r-- | doc/rfc/rfc5001.txt | 619 | ||||
| -rw-r--r-- | doc/rfc/rfc5011.txt | 787 | ||||
| -rw-r--r-- | doc/rfc/rfc5205.txt | 955 | ||||
| -rw-r--r-- | doc/rfc/rfc5452.txt | 1011 | ||||
| -rw-r--r-- | doc/rfc/rfc5507.txt | 1011 | ||||
| -rw-r--r-- | doc/rfc/rfc5625.txt | 675 | ||||
| -rw-r--r-- | doc/rfc/rfc5702.txt | 563 |
20 files changed, 16206 insertions, 0 deletions
diff --git a/doc/rfc/index b/doc/rfc/index index fea5f7181928..5d48ee4e6eef 100644 --- a/doc/rfc/index +++ b/doc/rfc/index @@ -20,6 +20,7 @@ 1750: Randomness Recommendations for Security 1876: A Means for Expressing Location Information in the Domain Name System 1886: DNS Extensions to support IP version 6 +1912: Common DNS Operational and Configuration Errors 1982: Serial Number Arithmetic 1995: Incremental Zone Transfer in DNS 1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) @@ -91,6 +92,7 @@ Secret Key Transaction Authentication for DNS (GSS-TSIG) 3655: Redefinition of DNS Authenticated Data (AD) bit 3658: Delegation Signer (DS) Resource Record (RR) +3755: Legacy Resolver Compatibility for Delegation Signer (DS) 3757: Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag 3833: Threat Analysis of the Domain Name System (DNS) @@ -104,6 +106,8 @@ 4159: Deprecation of "ip6.int" 4193: Unique Local IPv6 Unicast Addresses 4255: Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints +4294: IPv6 Node Requirements +4339: IPv6 Host Configuration of DNS Server Information Approaches 4343: Domain Name System (DNS) Case Insensitivity Clarification 4367: What's in a Name: False Assumptions about DNS Names 4398: Storing Certificates in the Domain Name System (DNS) @@ -111,9 +115,26 @@ 4408: Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 4470: Minimally Covering NSEC Records and DNSSEC On-line Signing +4471: Derivation of DNS Name Predecessor and Successor +4472: Operational Considerations and Issues with IPv6 DNS +4509: Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) 4634: US Secure Hash Algorithms (SHA and HMAC-SHA) +4635: HMAC SHA TSIG Algorithm Identifiers 4641: DNSSEC Operational Practices 4648: The Base16, Base32, and Base64 Data Encodings +4697: Observed DNS Resolution Misbehavior 4701: A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) +4892: Requirements for a Mechanism Identifying a Name Server Instance +4955: DNS Security (DNSSEC) Experiments +4956: DNS Security (DNSSEC) Opt-In +5001: DNS Name Server Identifier (NSID) Option +5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors 5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence +5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extension +5395: Domain Name System (DNS) IANA Considerations +5452: Measures for Making DNS More Resilient against Forged Answers +5507: Design Choices When Expanding the DNS +5625: DNS Proxy Implementation Guidelines +5702: Use of SHA-2 Algorithms with RSA in + DNSKEY and RRSIG Resource Records for DNSSEC diff --git a/doc/rfc/rfc1912.txt b/doc/rfc/rfc1912.txt new file mode 100644 index 000000000000..8ace7d267481 --- /dev/null +++ b/doc/rfc/rfc1912.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group D. Barr +Request for Comments: 1912 The Pennsylvania State University +Obsoletes: 1537 February 1996 +Category: Informational + + + Common DNS Operational and Configuration Errors + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + This memo describes errors often found in both the operation of + Domain Name System (DNS) servers, and in the data that these DNS + servers contain. This memo tries to summarize current Internet + requirements as well as common practice in the operation and + configuration of the DNS. This memo also tries to summarize or + expand upon issues raised in [RFC 1537]. + +1. Introduction + + Running a nameserver is not a trivial task. There are many things + that can go wrong, and many decisions have to be made about what data + to put in the DNS and how to set up servers. This memo attempts to + address many of the common mistakes and pitfalls that are made in DNS + data as well as in the operation of nameservers. Discussions are + also made regarding some other relevant issues such as server or + resolver bugs, and a few political issues with respect to the + operation of DNS on the Internet. + +2. DNS Data + + This section discusses problems people typically have with the DNS + data in their nameserver, as found in the zone data files that the + nameserver loads into memory. + +2.1 Inconsistent, Missing, or Bad Data + + Every Internet-reachable host should have a name. The consequences + of this are becoming more and more obvious. Many services available + on the Internet will not talk to you if you aren't correctly + registered in the DNS. + + + + + +Barr Informational [Page 1] + +RFC 1912 Common DNS Errors February 1996 + + + Make sure your PTR and A records match. For every IP address, there + should be a matching PTR record in the in-addr.arpa domain. If a + host is multi-homed, (more than one IP address) make sure that all IP + addresses have a corresponding PTR record (not just the first one). + Failure to have matching PTR and A records can cause loss of Internet + services similar to not being registered in the DNS at all. Also, + PTR records must point back to a valid A record, not a alias defined + by a CNAME. It is highly recommended that you use some software + which automates this checking, or generate your DNS data from a + database which automatically creates consistent data. + + DNS domain names consist of "labels" separated by single dots. The + DNS is very liberal in its rules for the allowable characters in a + domain name. However, if a domain name is used to name a host, it + should follow rules restricting host names. Further if a name is + used for mail, it must follow the naming rules for names in mail + addresses. + + Allowable characters in a label for a host name are only ASCII + letters, digits, and the `-' character. Labels may not be all + numbers, but may have a leading digit (e.g., 3com.com). Labels must + end and begin only with a letter or digit. See [RFC 1035] and [RFC + 1123]. (Labels were initially restricted in [RFC 1035] to start with + a letter, and some older hosts still reportedly have problems with + the relaxation in [RFC 1123].) Note there are some Internet + hostnames which violate this rule (411.org, 1776.com). The presence + of underscores in a label is allowed in [RFC 1033], except [RFC 1033] + is informational only and was not defining a standard. There is at + least one popular TCP/IP implementation which currently refuses to + talk to hosts named with underscores in them. It must be noted that + the language in [1035] is such that these rules are voluntary -- they + are there for those who wish to minimize problems. Note that the + rules for Internet host names also apply to hosts and addresses used + in SMTP (See RFC 821). + + If a domain name is to be used for mail (not involving SMTP), it must + follow the rules for mail in [RFC 822], which is actually more + liberal than the above rules. Labels for mail can be any ASCII + character except "specials", control characters, and whitespace + characters. "Specials" are specific symbols used in the parsing of + addresses. They are the characters "()<>@,;:\".[]". (The "!" + character wasn't in [RFC 822], however it also shouldn't be used due + to the conflict with UUCP mail as defined in RFC 976) However, since + today almost all names which are used for mail on the Internet are + also names used for hostnames, one rarely sees addresses using these + relaxed standard, but mail software should be made liberal and robust + enough to accept them. + + + + +Barr Informational [Page 2] + +RFC 1912 Common DNS Errors February 1996 + + + You should also be careful to not have addresses which are valid + alternate syntaxes to the inet_ntoa() library call. For example 0xe + is a valid name, but if you were to type "telnet 0xe", it would try + to connect to IP address 0.0.0.14. It is also rumored that there + exists some broken inet_ntoa() routines that treat an address like + x400 as an IP address. + + Certain operating systems have limitations on the length of their own + hostname. While not strictly of issue to the DNS, you should be + aware of your operating system's length limits before choosing the + name of a host. + + Remember that many resource records (abbreviated RR) take on more + than one argument. HINFO requires two arguments, as does RP. If you + don't supply enough arguments, servers sometime return garbage for + the missing fields. If you need to include whitespace within any + data, you must put the string in quotes. + +2.2 SOA records + + In the SOA record of every zone, remember to fill in the e-mail + address that will get to the person who maintains the DNS at your + site (commonly referred to as "hostmaster"). The `@' in the e-mail + must be replaced by a `.' first. Do not try to put an `@' sign in + this address. If the local part of the address already contains a + `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by + preceding it with `\' character. (e.g., to become + John\.Smith.widget.xx) Alternately (and preferred), you can just use + the generic name `hostmaster', and use a mail alias to redirect it to + the appropriate persons. There exists software which uses this field + to automatically generate the e-mail address for the zone contact. + This software will break if this field is improperly formatted. It + is imperative that this address get to one or more real persons, + because it is often used for everything from reporting bad DNS data + to reporting security incidents. + + Even though some BIND versions allow you to use a decimal in a serial + number, don't. A decimal serial number is converted to an unsigned + 32-bit integer internally anyway. The formula for a n.m serial + number is n*10^(3+int(0.9+log10(m))) + m which translates to + something rather unexpected. For example it's routinely possible + with a decimal serial number (perhaps automatically generated by + SCCS) to be incremented such that it is numerically larger, but after + the above conversion yield a serial number which is LOWER than + before. Decimal serial numbers have been officially deprecated in + recent BIND versions. The recommended syntax is YYYYMMDDnn + (YYYY=year, MM=month, DD=day, nn=revision number. This won't + overflow until the year 4294. + + + +Barr Informational [Page 3] + +RFC 1912 Common DNS Errors February 1996 + + + Choose logical values for the timer values in the SOA record (note + values below must be expressed as seconds in the zone data): + + Refresh: How often a secondary will poll the primary server to see + if the serial number for the zone has increased (so it knows + to request a new copy of the data for the zone). Set this to + how long your secondaries can comfortably contain out-of-date + data. You can keep it short (20 mins to 2 hours) if you + aren't worried about a small increase in bandwidth used, or + longer (2-12 hours) if your Internet connection is slow or is + started on demand. Recent BIND versions (4.9.3) have optional + code to automatically notify secondaries that data has + changed, allowing you to set this TTL to a long value (one + day, or more). + + Retry: If a secondary was unable to contact the primary at the + last refresh, wait the retry value before trying again. This + value isn't as important as others, unless the secondary is on + a distant network from the primary or the primary is more + prone to outages. It's typically some fraction of the refresh + interval. + + + Expire: How long a secondary will still treat its copy of the zone + data as valid if it can't contact the primary. This value + should be greater than how long a major outage would typically + last, and must be greater than the minimum and retry + intervals, to avoid having a secondary expire the data before + it gets a chance to get a new copy. After a zone is expired a + secondary will still continue to try to contact the primary, + but it will no longer provide nameservice for the zone. 2-4 + weeks are suggested values. + + Minimum: The default TTL (time-to-live) for resource records -- + how long data will remain in other nameservers' cache. ([RFC + 1035] defines this to be the minimum value, but servers seem + to always implement this as the default value) This is by far + the most important timer. Set this as large as is comfortable + given how often you update your nameserver. If you plan to + make major changes, it's a good idea to turn this value down + temporarily beforehand. Then wait the previous minimum value, + make your changes, verify their correctness, and turn this + value back up. 1-5 days are typical values. Remember this + value can be overridden on individual resource records. + + + + + + + +Barr Informational [Page 4] + +RFC 1912 Common DNS Errors February 1996 + + + As you can see, the typical values above for the timers vary widely. + Popular documentation like [RFC 1033] recommended a day for the + minimum TTL, which is now considered too low except for zones with + data that vary regularly. Once a DNS stabilizes, values on the order + of 3 or more days are recommended. It is also recommended that you + individually override the TTL on certain RRs which are often + referenced and don't often change to have very large values (1-2 + weeks). Good examples of this are the MX, A, and PTR records of your + mail host(s), the NS records of your zone, and the A records of your + nameservers. + +2.3 Glue A Records + + Glue records are A records that are associated with NS records to + provide "bootstrapping" information to the nameserver. For example: + + podunk.xx. in ns ns1.podunk.xx. + in ns ns2.podunk.xx. + ns1.podunk.xx. in a 1.2.3.4 + ns2.podunk.xx. in a 1.2.3.5 + + Here, the A records are referred to as "Glue records". + + Glue records are required only in forward zone files for nameservers + that are located in the subdomain of the current zone that is being + delegated. You shouldn't have any A records in an in-addr.arpa zone + file (unless you're using RFC 1101-style encoding of subnet masks). + + If your nameserver is multi-homed (has more than one IP address), you + must list all of its addresses in the glue to avoid cache + inconsistency due to differing TTL values, causing some lookups to + not find all addresses for your nameserver. + + Some people get in the bad habit of putting in a glue record whenever + they add an NS record "just to make sure". Having duplicate glue + records in your zone files just makes it harder when a nameserver + moves to a new IP address, or is removed. You'll spend hours trying + to figure out why random people still see the old IP address for some + host, because someone forgot to change or remove a glue record in + some other file. Newer BIND versions will ignore these extra glue + records in local zone files. + + Older BIND versions (4.8.3 and previous) have a problem where it + inserts these extra glue records in the zone transfer data to + secondaries. If one of these glues is wrong, the error can be + propagated to other nameservers. If two nameservers are secondaries + for other zones of each other, it's possible for one to continually + pass old glue records back to the other. The only way to get rid of + + + +Barr Informational [Page 5] + +RFC 1912 Common DNS Errors February 1996 + + + the old data is to kill both of them, remove the saved backup files, + and restart them. Combined with that those same versions also tend + to become infected more easily with bogus data found in other non- + secondary nameservers (like the root zone data). + +2.4 CNAME records + + A CNAME record is not allowed to coexist with any other data. In + other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you + can't also have an MX record for suzy.podunk.edu, or an A record, or + even a TXT record. Especially do not try to combine CNAMEs and NS + records like this!: + + + podunk.xx. IN NS ns1 + IN NS ns2 + IN CNAME mary + mary IN A 1.2.3.4 + + + This is often attempted by inexperienced administrators as an obvious + way to allow your domain name to also be a host. However, DNS + servers like BIND will see the CNAME and refuse to add any other + resources for that name. Since no other records are allowed to + coexist with a CNAME, the NS entries are ignored. Therefore all the + hosts in the podunk.xx domain are ignored as well! + + If you want to have your domain also be a host, do the following: + + podunk.xx. IN NS ns1 + IN NS ns2 + IN A 1.2.3.4 + mary IN A 1.2.3.4 + + Don't go overboard with CNAMEs. Use them when renaming hosts, but + plan to get rid of them (and inform your users). However CNAMEs are + useful (and encouraged) for generalized names for servers -- `ftp' + for your ftp server, `www' for your Web server, `gopher' for your + Gopher server, `news' for your Usenet news server, etc. + + Don't forget to delete the CNAMEs associated with a host if you + delete the host it is an alias for. Such "stale CNAMEs" are a waste + of resources. + + + + + + + + +Barr Informational [Page 6] + +RFC 1912 Common DNS Errors February 1996 + + + Don't use CNAMEs in combination with RRs which point to other names + like MX, CNAME, PTR and NS. (PTR is an exception if you want to + implement classless in-addr delegation.) For example, this is + strongly discouraged: + + podunk.xx. IN MX mailhost + mailhost IN CNAME mary + mary IN A 1.2.3.4 + + + [RFC 1034] in section 3.6.2 says this should not be done, and [RFC + 974] explicitly states that MX records shall not point to an alias + defined by a CNAME. This results in unnecessary indirection in + accessing the data, and DNS resolvers and servers need to work more + to get the answer. If you really want to do this, you can accomplish + the same thing by using a preprocessor such as m4 on your host files. + + Also, having chained records such as CNAMEs pointing to CNAMEs may + make administration issues easier, but is known to tickle bugs in + some resolvers that fail to check loops correctly. As a result some + hosts may not be able to resolve such names. + + Having NS records pointing to a CNAME is bad and may conflict badly + with current BIND servers. In fact, current BIND implementations + will ignore such records, possibly leading to a lame delegation. + There is a certain amount of security checking done in BIND to + prevent spoofing DNS NS records. Also, older BIND servers reportedly + will get caught in an infinite query loop trying to figure out the + address for the aliased nameserver, causing a continuous stream of + DNS requests to be sent. + +2.5 MX records + + It is a good idea to give every host an MX record, even if it points + to itself! Some mailers will cache MX records, but will always need + to check for an MX before sending mail. If a site does not have an + MX, then every piece of mail may result in one more resolver query, + since the answer to the MX query often also contains the IP addresses + of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to + support the MX mechanism. + + Put MX records even on hosts that aren't intended to send or receive + e-mail. If there is a security problem involving one of these hosts, + some people will mistakenly send mail to postmaster or root at the + site without checking first to see if it is a "real" host or just a + terminal or personal computer that's not set up to accept e-mail. If + you give it an MX record, then the e-mail can be redirected to a real + person. Otherwise mail can just sit in a queue for hours or days + + + +Barr Informational [Page 7] + +RFC 1912 Common DNS Errors February 1996 + + + until the mailer gives up trying to send it. + + Don't forget that whenever you add an MX record, you need to inform + the target mailer if it is to treat the first host as "local". (The + "Cw" flag in sendmail, for example) + + If you add an MX record which points to an external host (e.g., for + the purposes of backup mail routing) be sure to ask permission from + that site first. Otherwise that site could get rather upset and take + action (like throw your mail away, or appeal to higher authorities + like your parent DNS administrator or network provider.) + +2.6 Other Resource Records + +2.6.1 WKS + + WKS records are deprecated in [RFC 1123]. They serve no known useful + function, except internally among LISP machines. Don't use them. + +2.6.2 HINFO + + On the issue HINFO records, some will argue that these is a security + problem (by broadcasting what vendor hardware and operating system + you so people can run systematic attacks on known vendor security + holes). If you do use them, you should keep up to date with known + vendor security problems. However, they serve a useful purpose. + Don't forget that HINFO requires two arguments, the hardware type, + and the operating system. + + HINFO is sometimes abused to provide other information. The record + is meant to provide specific information about the machine itself. + If you need to express other information about the host in the DNS, + use TXT. + +2.6.3 TXT + + TXT records have no specific definition. You can put most anything + in them. Some use it for a generic description of the host, some put + specific information like its location, primary user, or maybe even a + phone number. + +2.6.4 RP + + RP records are relatively new. They are used to specify an e-mail + address (see first paragraph of section 2.2) of the "Responsible + Person" of the host, and the name of a TXT record where you can get + more information. See [RFC 1183]. + + + + +Barr Informational [Page 8] + +RFC 1912 Common DNS Errors February 1996 + + +2.7 Wildcard records + + Wildcard MXs are useful mostly for non IP-connected sites. A common + mistake is thinking that a wildcard MX for a zone will apply to all + hosts in the zone. A wildcard MX will apply only to names in the + zone which aren't listed in the DNS at all. e.g., + + podunk.xx. IN NS ns1 + IN NS ns2 + mary IN A 1.2.3.4 + *.podunk.xx. IN MX 5 sue + + Mail for mary.podunk.xx will be sent to itself for delivery. Only + mail for jane.podunk.xx or any hosts you don't see above will be sent + to the MX. For most Internet sites, wildcard MX records are not + useful. You need to put explicit MX records on every host. + + Wildcard MXs can be bad, because they make some operations succeed + when they should fail instead. Consider the case where someone in + the domain "widget.com" tries to send mail to "joe@larry". If the + host "larry" doesn't actually exist, the mail should in fact bounce + immediately. But because of domain searching the address gets + resolved to "larry.widget.com", and because of the wildcard MX this + is a valid address according to DNS. Or perhaps someone simply made + a typo in the hostname portion of the address. The mail message then + gets routed to the mail host, which then rejects the mail with + strange error messages like "I refuse to talk to myself" or "Local + configuration error". + + Wildcard MX records are good for when you have a large number of + hosts which are not directly Internet-connected (for example, behind + a firewall) and for administrative or political reasons it is too + difficult to have individual MX records for every host, or to force + all e-mail addresses to be "hidden" behind one or more domain names. + In that case, you must divide your DNS into two parts, an internal + DNS, and an external DNS. The external DNS will have only a few + hosts and explicit MX records, and one or more wildcard MXs for each + internal domain. Internally the DNS will be complete, with all + explicit MX records and no wildcards. + + Wildcard As and CNAMEs are possible too, and are really confusing to + users, and a potential nightmare if used without thinking first. It + could result (due again to domain searching) in any telnet/ftp + attempts from within the domain to unknown hosts to be directed to + one address. One such wildcard CNAME (in *.edu.com) caused + Internet-wide loss of services and potential security nightmares due + to unexpected interactions with domain searching. It resulted in + swift fixes, and even an RFC ([RFC 1535]) documenting the problem. + + + +Barr Informational [Page 9] + +RFC 1912 Common DNS Errors February 1996 + + +2.8 Authority and Delegation Errors (NS records) + + You are required to have at least two nameservers for every domain, + though more is preferred. Have secondaries outside your network. If + the secondary isn't under your control, periodically check up on them + and make sure they're getting current zone data from you. Queries to + their nameserver about your hosts should always result in an + "authoritative" response. If not, this is called a "lame + delegation". A lame delegations exists when a nameserver is + delegated responsibility for providing nameservice for a zone (via NS + records) but is not performing nameservice for that zone (usually + because it is not set up as a primary or secondary for the zone). + + The "classic" lame delegation can be illustrated in this example: + + podunk.xx. IN NS ns1.podunk.xx. + IN NS ns0.widget.com. + + "podunk.xx" is a new domain which has recently been created, and + "ns1.podunk.xx" has been set up to perform nameservice for the zone. + They haven't quite finished everything yet and haven't made sure that + the hostmaster at "ns0.widget.com" has set up to be a proper + secondary, and thus has no information about the podunk.xx domain, + even though the DNS says it is supposed to. Various things can + happen depending on which nameserver is used. At best, extra DNS + traffic will result from a lame delegation. At worst, you can get + unresolved hosts and bounced e-mail. + + Also, sometimes a nameserver is moved to another host or removed from + the list of secondaries. Unfortunately due to caching of NS records, + many sites will still think that a host is a secondary after that + host has stopped providing nameservice. In order to prevent lame + delegations while the cache is being aged, continue to provide + nameservice on the old nameserver for the length of the maximum of + the minimum plus refresh times for the zone and the parent zone. + (See section 2.2) + + Whenever a primary or secondary is removed or changed, it takes a + fair amount of human coordination among the parties involved. (The + site itself, it's parent, and the site hosting the secondary) When a + primary moves, make sure all secondaries have their named.boot files + updated and their servers reloaded. When a secondary moves, make + sure the address records at both the primary and parent level are + changed. + + It's also been reported that some distant sites like to pick popular + nameservers like "ns.uu.net" and just add it to their list of NS + records in hopes that they will magically perform additional + + + +Barr Informational [Page 10] + +RFC 1912 Common DNS Errors February 1996 + + + nameservice for them. This is an even worse form of lame delegation, + since this adds traffic to an already busy nameserver. Please + contact the hostmasters of sites which have lame delegations. + Various tools can be used to detect or actively find lame + delegations. See the list of contributed software in the BIND + distribution. + + Make sure your parent domain has the same NS records for your zone as + you do. (Don't forget your in-addr.arpa zones too!). Do not list + too many (7 is the recommended maximum), as this just makes things + harder to manage and is only really necessary for very popular top- + level or root zones. You also run the risk of overflowing the 512- + byte limit of a UDP packet in the response to an NS query. If this + happens, resolvers will "fall back" to using TCP requests, resulting + in increased load on your nameserver. + + It's important when picking geographic locations for secondary + nameservers to minimize latency as well as increase reliability. + Keep in mind network topologies. For example if your site is on the + other end of a slow local or international link, consider a secondary + on the other side of the link to decrease average latency. Contact + your Internet service provider or parent domain contact for more + information about secondaries which may be available to you. + +3. BIND operation + + This section discusses common problems people have in the actual + operation of the nameserver (specifically, BIND). Not only must the + data be correct as explained above, but the nameserver must be + operated correctly for the data to be made available. + +3.1 Serial numbers + + Each zone has a serial number associated with it. Its use is for + keeping track of who has the most current data. If and only if the + primary's serial number of the zone is greater will the secondary ask + the primary for a copy of the new zone data (see special case below). + + Don't forget to change the serial number when you change data! If + you don't, your secondaries will not transfer the new zone + information. Automating the incrementing of the serial number with + software is also a good idea. + + If you make a mistake and increment the serial number too high, and + you want to reset the serial number to a lower value, use the + following procedure: + + + + + +Barr Informational [Page 11] + +RFC 1912 Common DNS Errors February 1996 + + + Take the `incorrect' serial number and add 2147483647 to it. If + the number exceeds 4294967296, subtract 4294967296. Load the + resulting number. Then wait 2 refresh periods to allow the zone + to propagate to all servers. + + Repeat above until the resulting serial number is less than the + target serial number. + + Up the serial number to the target serial number. + + This procedure won't work if one of your secondaries is running an + old version of BIND (4.8.3 or earlier). In this case you'll have to + contact the hostmaster for that secondary and have them kill the + secondary servers, remove the saved backup file, and restart the + server. Be careful when editing the serial number -- DNS admins + don't like to kill and restart nameservers because you lose all that + cached data. + +3.2 Zone file style guide + + Here are some useful tips in structuring your zone files. Following + these will help you spot mistakes, and avoid making more. + + Be consistent with the style of entries in your DNS files. If your + $ORIGIN is podunk.xx., try not to write entries like: + + mary IN A 1.2.3.1 + sue.podunk.xx. IN A 1.2.3.2 + + or: + + bobbi IN A 1.2.3.2 + IN MX mary.podunk.xx. + + + Either use all FQDNs (Fully Qualified Domain Names) everywhere or + used unqualified names everywhere. Or have FQDNs all on the right- + hand side but unqualified names on the left. Above all, be + consistent. + + Use tabs between fields, and try to keep columns lined up. It makes + it easier to spot missing fields (note some fields such as "IN" are + inherited from the previous record and may be left out in certain + circumstances.) + + + + + + + +Barr Informational [Page 12] + +RFC 1912 Common DNS Errors February 1996 + + + Remember you don't need to repeat the name of the host when you are + defining multiple records for one host. Be sure also to keep all + records associated with a host together in the file. It will make + things more straightforward when it comes time to remove or rename a + host. + + Always remember your $ORIGIN. If you don't put a `.' at the end of + an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then + the nameserver will append $ORIGIN to the name. Double check, triple + check, those trailing dots, especially in in-addr.arpa zone files, + where they are needed the most. + + Be careful with the syntax of the SOA and WKS records (the records + which use parentheses). BIND is not very flexible in how it parses + these records. See the documentation for BIND. + +3.3 Verifying data + + Verify the data you just entered or changed by querying the resolver + with dig (or your favorite DNS tool, many are included in the BIND + distribution) after a change. A few seconds spent double checking + can save hours of trouble, lost mail, and general headaches. Also be + sure to check syslog output when you reload the nameserver. If you + have grievous errors in your DNS data or boot file, named will report + it via syslog. + + It is also highly recommended that you automate this checking, either + with software which runs sanity checks on the data files before they + are loaded into the nameserver, or with software which checks the + data already loaded in the nameserver. Some contributed software to + do this is included in the BIND distribution. + +4. Miscellaneous Topics + +4.1 Boot file setup + + Certain zones should always be present in nameserver configurations: + + primary localhost localhost + primary 0.0.127.in-addr.arpa 127.0 + primary 255.in-addr.arpa 255 + primary 0.in-addr.arpa 0 + + These are set up to either provide nameservice for "special" + addresses, or to help eliminate accidental queries for broadcast or + local address to be sent off to the root nameservers. All of these + files will contain NS and SOA records just like the other zone files + you maintain, the exception being that you can probably make the SOA + + + +Barr Informational [Page 13] + +RFC 1912 Common DNS Errors February 1996 + + + timers very long, since this data will never change. + + The "localhost" address is a "special" address which always refers to + the local host. It should contain the following line: + + localhost. IN A 127.0.0.1 + + The "127.0" file should contain the line: + + 1 PTR localhost. + + There has been some extensive discussion about whether or not to + append the local domain to it. The conclusion is that "localhost." + would be the best solution. The reasons given include: + + "localhost" by itself is used and expected to work in some + systems. + + Translating 127.0.0.1 into "localhost.dom.ain" can cause some + software to connect back to the loopback interface when it didn't + want to because "localhost" is not equal to "localhost.dom.ain". + + The "255" and "0" files should not contain any additional data beyond + the NS and SOA records. + + Note that future BIND versions may include all or some of this data + automatically without additional configuration. + +4.2 Other Resolver and Server bugs + + Very old versions of the DNS resolver have a bug that cause queries + for names that look like IP addresses to go out, because the user + supplied an IP address and the software didn't realize that it didn't + need to be resolved. This has been fixed but occasionally it still + pops up. It's important because this bug means that these queries + will be sent directly to the root nameservers, adding to an already + heavy DNS load. + + While running a secondary nameserver off another secondary nameserver + is possible, it is not recommended unless necessary due to network + topologies. There are known cases where it has led to problems like + bogus TTL values. While this may be caused by older or flawed DNS + implementations, you should not chain secondaries off of one another + since this builds up additional reliability dependencies as well as + adds additional delays in updates of new zone data. + + + + + + +Barr Informational [Page 14] + +RFC 1912 Common DNS Errors February 1996 + + +4.3 Server issues + + DNS operates primarily via UDP (User Datagram Protocol) messages. + Some UNIX operating systems, in an effort to save CPU cycles, run + with UDP checksums turned off. The relative merits of this have long + been debated. However, with the increase in CPU speeds, the + performance considerations become less and less important. It is + strongly encouraged that you turn on UDP checksumming to avoid + corrupted data not only with DNS but with other services that use UDP + (like NFS). Check with your operating system documentation to verify + that UDP checksumming is enabled. + +References + + [RFC 974] Partridge, C., "Mail routing and the domain system", STD + 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986. + + [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC + 1033, USC/Information Sciences Institute, November 1987. + + [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, USC/Information Sciences Institute, + November 1987. + + [RFC 1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + [RFC 1123] Braden, R., "Requirements for Internet Hosts -- + Application and Support", STD 3, RFC 1123, IETF, October + 1989. + + [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC + 1178, Integrated Systems Group/NIST, August 1990. + + [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart, + "New DNS RR Definitions", RFC 1183, October 1990. + + [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction + With Widely Deployed DNS Software", RFC 1535, ACES + Research Inc., October 1993. + + [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. + Miller, "Common DNS Implementation Errors and Suggested + Fixes", RFC 1536, USC/Information Sciences Institute, USC, + October 1993. + + + + + +Barr Informational [Page 15] + +RFC 1912 Common DNS Errors February 1996 + + + [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors", + RFC 1537, CWI, October 1993. + + [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN, + November 1994. + + [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND", + Vixie Enterprises, July 1994. + +5. Security Considerations + + Security issues are not discussed in this memo. + +6. Author's Address + + David Barr + The Pennsylvania State University + Department of Mathematics + 334 Whitmore Building + University Park, PA 16802 + + Voice: +1 814 863 7374 + Fax: +1 814 863-8311 + EMail: barr@math.psu.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + +Barr Informational [Page 16] + diff --git a/doc/rfc/rfc3755.txt b/doc/rfc/rfc3755.txt new file mode 100644 index 000000000000..a9a7cf269298 --- /dev/null +++ b/doc/rfc/rfc3755.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group S. Weiler +Request for Comments: 3755 SPARTA, Inc. +Updates: 3658, 2535 May 2004 +Category: Standards Track + + + Legacy Resolver Compatibility for Delegation Signer (DS) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + As the DNS Security (DNSSEC) specifications have evolved, the syntax + and semantics of the DNSSEC resource records (RRs) have changed. + Many deployed nameservers understand variants of these semantics. + Dangerous interactions can occur when a resolver that understands an + earlier version of these semantics queries an authoritative server + that understands the new delegation signer semantics, including at + least one failure scenario that will cause an unsecured zone to be + unresolvable. This document changes the type codes and mnemonics of + the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions. + +1. Introduction + + The DNSSEC protocol has been through many iterations whose syntax and + semantics are not completely compatible. This has occurred as part + of the ordinary process of proposing a protocol, implementing it, + testing it in the increasingly complex and diverse environment of the + Internet, and refining the definitions of the initial Proposed + Standard. In the case of DNSSEC, the process has been complicated by + DNS's criticality and wide deployment and the need to add security + while minimizing daily operational complexity. + + A weak area for previous DNS specifications has been lack of detail + in specifying resolver behavior, leaving implementors largely on + their own to determine many details of resolver function. This, + combined with the number of iterations the DNSSEC specifications have + been through, has resulted in fielded code with a wide variety of + + + +Weiler Standards Track [Page 1] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + + behaviors. This variety makes it difficult to predict how a protocol + change will be handled by all deployed resolvers. The risk that a + change will cause unacceptable or even catastrophic failures makes it + difficult to design and deploy a protocol change. One strategy for + managing that risk is to structure protocol changes so that existing + resolvers can completely ignore input that might confuse them or + trigger undesirable failure modes. + + This document addresses a specific problem caused by Delegation + Signer's (DS) [RFC3658] introduction of new semantics for the NXT RR + that are incompatible with the semantics in [RFC2535]. Answers + provided by DS-aware servers can trigger an unacceptable failure mode + in some resolvers that implement RFC 2535, which provides a great + disincentive to sign zones with DS. The changes defined in this + document allow for the incremental deployment of DS. + +1.1. Terminology + + In this document, the term "unsecure delegation" means any delegation + for which no DS record appears at the parent. An "unsecure referral" + is an answer from the parent containing an NS RRset and a proof that + no DS record exists for that name. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. The Problem + + Delegation Signer (DS) introduces new semantics for the NXT RR that + are incompatible with the semantics in RFC 2535. In RFC 2535, NXT + records were only required to be returned as part of a non-existence + proof. With DS, an unsecure referral returns, in addition to the NS, + a proof of non-existence of a DS RR in the form of an NXT and + SIG(NXT). RFC 2535 didn't specify how a resolver was to interpret a + response with RCODE=0, AA=0, and both an NS and an NXT in the + authority section. Some widely deployed 2535-aware resolvers + interpret any answer with an NXT as a proof of non-existence of the + requested record. This results in unsecure delegations being + invisible to 2535-aware resolvers and violates the basic + architectural principle that DNSSEC must do no harm -- the signing of + zones must not prevent the resolution of unsecured delegations. + +2. Possible Solutions + + This section presents several solutions that were considered. + Section 3 describes the one selected. + + + + +Weiler Standards Track [Page 2] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +2.1. Change SIG, KEY, and NXT type codes + + To avoid the problem described above, legacy (RFC2535-aware) + resolvers need to be kept from seeing unsecure referrals that include + NXT records in the authority section. The simplest way to do that is + to change the type codes for SIG, KEY, and NXT. + + The obvious drawback to this is that new resolvers will not be able + to validate zones signed with the old RRs. This problem already + exists, however, because of the changes made by DS, and resolvers + that understand the old RRs (and have compatibility issues with DS) + are far more prevalent than 2535-signed zones. + +2.2. Change a subset of type codes + + The observed problem with unsecure referrals could be addressed by + changing only the NXT type code or another subset of the type codes + that includes NXT. This has the virtue of apparent simplicity, but + it risks introducing new problems or not going far enough. It's + quite possible that more incompatibilities exist between DS and + earlier semantics. Legacy resolvers may also be confused by seeing + records they recognize (SIG and KEY) while being unable to find NXTs. + Although it may seem unnecessary to fix that which is not obviously + broken, it's far cleaner to change all of the type codes at once. + This will leave legacy resolvers and tools completely blinded to + DNSSEC -- they will see only unknown RRs. + +2.3. Replace the DO bit + + Another way to keep legacy resolvers from ever seeing DNSSEC records + with DS semantics is to have authoritative servers only send that + data to DS-aware resolvers. It's been proposed that assigning a new + EDNS0 flag bit to signal DS-awareness (tentatively called "DA"), and + having authoritative servers send DNSSEC data only in response to + queries with the DA bit set, would accomplish this. This bit would + presumably supplant the DO bit described in [RFC3225]. + + This solution is sufficient only if all 2535-aware resolvers zero out + EDNS0 flags that they don't understand. If one passed through the DA + bit unchanged, it would still see the new semantics, and it would + probably fail to see unsecure delegations. Since it's impractical to + know how every DNS implementation handles unknown EDNS0 flags, this + is not a universal solution. It could, though, be considered in + addition to changing the RR type codes. + + + + + + + +Weiler Standards Track [Page 3] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +2.4. Increment the EDNS version + + Another possible solution is to increment the EDNS version number as + defined in [RFC2671], on the assumption that all existing + implementations will reject higher versions than they support, and + retain the DO bit as the signal for DNSSEC awareness. This approach + has not been tested. + +2.5. Do nothing + + There is a large deployed base of DNS resolvers that understand + DNSSEC as defined by the standards track RFC 2535 and [RFC2065] and, + due to under specification in those documents, interpret any answer + with an NXT as a non-existence proof. So long as that is the case, + zone owners will have a strong incentive to not sign any zones that + contain unsecure delegations, lest those delegations be invisible to + such a large installed base. This will dramatically slow DNSSEC + adoption. + + Unfortunately, without signed zones there's no clear incentive for + operators of resolvers to upgrade their software to support the new + version of DNSSEC, as defined in RFC 3658. Historical data suggests + that resolvers are rarely upgraded, and that old nameserver code + never dies. + + Rather than wait years for resolvers to be upgraded through natural + processes before signing zones with unsecure delegations, addressing + this problem with a protocol change will immediately remove the + disincentive for signing zones and allow widespread deployment of + DNSSEC. + +3. Protocol changes + + This document changes the type codes of SIG, KEY, and NXT. This + approach is the cleanest and safest of those discussed above, largely + because the behavior of resolvers that receive unknown type codes is + well understood. This approach has also received the most testing. + + To avoid operational confusion, it's also necessary to change the + mnemonics for these RRs. DNSKEY will be the replacement for KEY, + with the mnemonic indicating that these keys are not for application + use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace + SIG, and NSEC (Next SECure) will replace NXT. These new types + completely replace the old types, except that SIG(0) [RFC2931] and + TKEY [RFC2930] will continue to use SIG and KEY. + + + + + + +Weiler Standards Track [Page 4] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + + The new types will have exactly the same syntax and semantics as + specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for + the following: + + 1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC + RRs MUST NOT be compressed, + + 2) Embedded domain names in RRSIG and NSEC RRs are not downcased for + purposes of DNSSEC canonical form and ordering nor for equality + comparison, and + + 3) An RRSIG with a type-covered field of zero has undefined + semantics. The meaning of such a resource record may only be + defined by IETF Standards Action. + + If a resolver receives the old types, it SHOULD treat them as unknown + RRs and SHOULD NOT assign any special meaning to them or give them + any special treatment. It MUST NOT use them for DNSSEC validations + or other DNS operational decision making. For example, a resolver + MUST NOT use DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. + If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive + special treatment. As an example, if a SIG is included in a signed + zone, there MUST be an RRSIG for it. Authoritative servers may wish + to give error messages when loading zones containing SIG or NXT + records (KEY records may be included for SIG(0) or TKEY). + + As a clarification to previous documents, some positive responses, + particularly wildcard proofs and unsecure referrals, will contain + NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as negative + answers merely because they contain an NSEC. + +4. IANA Considerations + +4.1. DNS Resource Record Types + + This document updates the IANA registry for DNS Resource Record Types + by assigning types 46, 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, + respectively. + + Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and + TKEY [RFC2930] use only. + + Type 30 (NXT) should be marked as Obsolete. + + + + + + + + +Weiler Standards Track [Page 5] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +4.2. DNS Security Algorithm Numbers + + To allow zone signing (DNSSEC) and transaction security mechanisms + (SIG(0) and TKEY) to use different sets of algorithms, the existing + "DNS Security Algorithm Numbers" registry is modified to include the + applicability of each algorithm. Specifically, two new columns are + added to the registry, showing whether each algorithm may be used for + zone signing, transaction security mechanisms, or both. Only + algorithms usable for zone signing may be used in DNSKEY, RRSIG, and + DS RRs. Only algorithms usable for SIG(0) and/or TSIG may be used in + SIG and KEY RRs. + + All currently defined algorithms except for Indirect (algorithm 252) + remain usable for transaction security mechanisms. Only RSA/SHA-1 + [RFC3110], DSA/SHA-1 [RFC2536], and private algorithms (types 253 and + 254) may be used for zone signing. Note that the registry does not + contain the requirement level of each algorithm, only whether or not + an algorithm may be used for the given purposes. For example, + RSA/MD5, while allowed for transaction security mechanisms, is NOT + RECOMMENDED, per [RFC3110]. + + Additionally, the presentation format algorithm mnemonics from + [RFC2535] Section 7 are added to the registry. This document assigns + RSA/SHA-1 the mnemonic RSASHA1. + + As before, assignment of new algorithms in this registry requires + IETF Standards Action. Additionally, modification of algorithm + mnemonics or applicability requires IETF Standards Action. Documents + defining a new algorithm must address the applicability of the + algorithm and should assign a presentation mnemonic to the algorithm. + +4.3. DNSKEY Flags + + Like the KEY resource record, DNSKEY contains a 16-bit flags field. + This document creates a new registry for the DNSKEY flags field. + + Initially, this registry only contains an assignment for bit 7 (the + ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF + Standards Action. + +4.4. DNSKEY Protocol Octet + + Like the KEY resource record, DNSKEY contains an eight bit protocol + field. The only defined value for this field is 3 (DNSSEC). No + other values are allowed, hence no IANA registry is needed for this + field. + + + + + +Weiler Standards Track [Page 6] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +5. Security Considerations + + The changes introduced here do not materially affect security. The + implications of trying to use both new and legacy types together are + not well understood, and attempts to do so would probably lead to + unintended and dangerous results. + + Changing type codes will leave code paths in legacy resolvers that + are never exercised. Unexercised code paths are a frequent source of + security holes, largely because those code paths do not get frequent + scrutiny. + + Doing nothing, as described in section 2.5, will slow DNSSEC + deployment. While this does not decrease security, it also fails to + increase it. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", + RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + + + + + + + + + + +Weiler Standards Track [Page 7] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +6.2. Informative References + + [RFC2065] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System + Security Extensions", RFC 2065, January 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + +7. Acknowledgments + + The changes introduced here and the analysis of alternatives had many + contributors. With apologies to anyone overlooked, those include: + Michael Graff, Johan Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, + Bill Manning, Paul Vixie, and Suzanne Woolf. + + Thanks to Jakob Schlyter and Mark Andrews for identifying the + incompatibility described in section 1.2. + + In addition to the above, the author would like to thank Scott Rose, + Olafur Gudmundsson, and Sandra Murphy for their substantive comments. + +8. Author's Address + + Samuel Weiler + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + + EMail: weiler@tislabs.com + + + + + + + + + + + + +Weiler Standards Track [Page 8] + +RFC 3755 Legacy Resolver Compatibility for DS May 2004 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (2004). 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Weiler Standards Track [Page 9] + diff --git a/doc/rfc/rfc4294.txt b/doc/rfc/rfc4294.txt new file mode 100644 index 000000000000..8fea5c311bfd --- /dev/null +++ b/doc/rfc/rfc4294.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group J. Loughney, Ed. +Request for Comments: 4294 Nokia +Category: Informational April 2006 + + + IPv6 Node Requirements + +Status of This Memo + + This memo provides information for 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 + + This document defines requirements for IPv6 nodes. It is expected + that IPv6 will be deployed in a wide range of devices and situations. + Specifying the requirements for IPv6 nodes allows IPv6 to function + well and interoperate in a large number of situations and + deployments. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirement Language .......................................3 + 1.2. Scope of This Document .....................................3 + 1.3. Description of IPv6 Nodes ..................................3 + 2. Abbreviations Used in This Document .............................3 + 3. Sub-IP Layer ....................................................4 + 3.1. Transmission of IPv6 Packets over Ethernet Networks + - RFC 2464 .................................................4 + 3.2. IP version 6 over PPP - RFC 2472 ...........................4 + 3.3. IPv6 over ATM Networks - RFC 2492 ..........................4 + 4. IP Layer ........................................................5 + 4.1. Internet Protocol Version 6 - RFC 2460 .....................5 + 4.2. Neighbor Discovery for IPv6 - RFC 2461 .....................5 + 4.3. Path MTU Discovery and Packet Size .........................6 + 4.4. ICMP for the Internet Protocol Version 6 (IPv6) - + RFC 2463 ...................................................7 + 4.5. Addressing .................................................7 + 4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 .....8 + 5. DNS and DHCP ....................................................8 + 5.1. DNS ........................................................8 + + + + +Loughney Informational [Page 1] + +RFC 4294 IPv6 Node Requirements April 2006 + + + 5.2. Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) - RFC 3315 ........................................9 + 6. IPv4 Support and Transition ....................................10 + 6.1. Transition Mechanisms .....................................10 + 7. Mobile IP ......................................................10 + 8. Security .......................................................10 + 8.1. Basic Architecture ........................................10 + 8.2. Security Protocols ........................................11 + 8.3. Transforms and Algorithms .................................11 + 8.4. Key Management Methods ....................................12 + 9. Router-Specific Functionality ..................................12 + 9.1. General ...................................................12 + 10. Network Management ............................................12 + 10.1. Management Information Base Modules (MIBs) ...............12 + 11. Security Considerations .......................................13 + 12. References ....................................................13 + 12.1. Normative References .....................................13 + 12.2. Informative References ...................................16 + 13. Authors and Acknowledgements ..................................18 + +1. Introduction + + The goal of this document is to define the common functionality + required from both IPv6 hosts and routers. Many IPv6 nodes will + implement optional or additional features, but this document + summarizes requirements from other published Standards Track + documents in one place. + + This document tries to avoid discussion of protocol details, and + references RFCs for this purpose. This document is informational in + nature and does not update Standards Track RFCs. + + Although the document points to different specifications, it should + be noted that in most cases, the granularity of requirements are + smaller than a single specification, as many specifications define + multiple, independent pieces, some of which may not be mandatory. + + As it is not always possible for an implementer to know the exact + usage of IPv6 in a node, an overriding requirement for IPv6 nodes is + that they should adhere to Jon Postel's Robustness Principle: + + Be conservative in what you do, be liberal in what you accept from + others [RFC-793]. + + + + + + + + +Loughney Informational [Page 2] + +RFC 4294 IPv6 Node Requirements April 2006 + + +1.1. Requirement Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC-2119]. + +1.2. Scope of This Document + + IPv6 covers many specifications. It is intended that IPv6 will be + deployed in many different situations and environments. Therefore, + it is important to develop the requirements for IPv6 nodes to ensure + interoperability. + + This document assumes that all IPv6 nodes meet the minimum + requirements specified here. + +1.3. Description of IPv6 Nodes + + From the Internet Protocol, Version 6 (IPv6) Specification + [RFC-2460], we have the following definitions: + + Description of an IPv6 Node + + - a device that implements IPv6. + + Description of an IPv6 router + + - a node that forwards IPv6 packets not explicitly addressed + to itself. + + Description of an IPv6 Host + + - any node that is not a router. + +2. Abbreviations Used in This Document + + ATM Asynchronous Transfer Mode + + AH Authentication Header + + DAD Duplicate Address Detection + + ESP Encapsulating Security Payload + + ICMP Internet Control Message Protocol + + IKE Internet Key Exchange + + + + +Loughney Informational [Page 3] + +RFC 4294 IPv6 Node Requirements April 2006 + + + MIB Management Information Base + + MLD Multicast Listener Discovery + + MTU Maximum Transfer Unit + + NA Neighbor Advertisement + + NBMA Non-Broadcast Multiple Access + + ND Neighbor Discovery + + NS Neighbor Solicitation + + NUD Neighbor Unreachability Detection + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SVC Switched Virtual Circuit + +3. Sub-IP Layer + + An IPv6 node must include support for one or more IPv6 link-layer + specifications. Which link-layer specifications are included will + depend upon what link-layers are supported by the hardware available + on the system. It is possible for a conformant IPv6 node to support + IPv6 on some of its interfaces and not on others. + + As IPv6 is run over new layer 2 technologies, it is expected that new + specifications will be issued. This section highlights some major + layer 2 technologies and is not intended to be complete. + +3.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464 + + Nodes supporting IPv6 over Ethernet interfaces MUST implement + Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. + +3.2. IP version 6 over PPP - RFC 2472 + + Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP + [RFC-2472]. + +3.3. IPv6 over ATM Networks - RFC 2492 + + Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM + Networks [RFC-2492]. Additionally, RFC 2492 states: + + + +Loughney Informational [Page 4] + +RFC 4294 IPv6 Node Requirements April 2006 + + + A minimally conforming IPv6/ATM driver SHALL support the PVC mode + of operation. An IPv6/ATM driver that supports the full SVC mode + SHALL also support PVC mode of operation. + +4. IP Layer + +4.1. Internet Protocol Version 6 - RFC 2460 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification MUST be supported. + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions MUST be processed as described in RFC 2460. + + The node MUST follow the packet transmission rules in RFC 2460. + + Nodes MUST always be able to send, receive, and process fragment + headers. All conformant IPv6 implementations MUST be capable of + sending and receiving IPv6 packets; the forwarding functionality MAY + be supported. + + RFC 2460 specifies extension headers and the processing for these + headers. + + A full implementation of IPv6 includes implementation of the + following extension headers: Hop-by-Hop Options, Routing (Type 0), + Fragment, Destination Options, Authentication and Encapsulating + Security Payload [RFC-2460]. + + An IPv6 node MUST be able to process these headers. It should be + noted that there is some discussion about the use of Routing Headers + and possible security threats [IPv6-RH] that they cause. + +4.2. Neighbor Discovery for IPv6 - RFC 2461 + + Neighbor Discovery SHOULD be supported. [RFC-2461] states: + + "Unless specified otherwise (in a document that covers operating + IP over a particular link type) this document applies to all link + types. However, because ND uses link-layer multicast for some of + its services, it is possible that on some link types (e.g., NBMA + links) alternative protocols or mechanisms to implement those + services will be specified (in the appropriate document covering + the operation of IP over a particular link type). The services + described in this document that are not directly dependent on + multicast, such as Redirects, Next-hop determination, Neighbor + Unreachability Detection, etc., are expected to be provided as + + + + +Loughney Informational [Page 5] + +RFC 4294 IPv6 Node Requirements April 2006 + + + specified in this document. The details of how one uses ND on + NBMA links is an area for further study." + + Some detailed analysis of Neighbor Discovery follows: + + Router Discovery is how hosts locate routers that reside on an + attached link. Router Discovery MUST be supported for + implementations. + + Prefix Discovery is how hosts discover the set of address prefixes + that define which destinations are on-link for an attached link. + Prefix discovery MUST be supported for implementations. Neighbor + Unreachability Detection (NUD) MUST be supported for all paths + between hosts and neighboring nodes. It is not required for paths + between routers. However, when a node receives a unicast Neighbor + Solicitation (NS) message (that may be a NUD's NS), the node MUST + respond to it (i.e., send a unicast Neighbor Advertisement). + + Duplicate Address Detection MUST be supported on all links supporting + link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take + place on all unicast addresses). + + A host implementation MUST support sending Router Solicitations. + + Receiving and processing Router Advertisements MUST be supported for + host implementations. The ability to understand specific Router + Advertisement options is dependent on supporting the specification + where the RA is specified. + + Sending and Receiving Neighbor Solicitation (NS) and Neighbor + Advertisement (NA) MUST be supported. NS and NA messages are + required for Duplicate Address Detection (DAD). + + Redirect functionality SHOULD be supported. If the node is a router, + Redirect functionality MUST be supported. + +4.3. Path MTU Discovery and Packet Size + +4.3.1. Path MTU Discovery - RFC 1981 + + Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal + implementations MAY choose to not support it and avoid large packets. + The rules in RFC 2460 MUST be followed for packet fragmentation and + reassembly. + +4.3.2. IPv6 Jumbograms - RFC 2675 + + IPv6 Jumbograms [RFC-2675] MAY be supported. + + + +Loughney Informational [Page 6] + +RFC 4294 IPv6 Node Requirements April 2006 + + +4.4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463 + + ICMPv6 [RFC-2463] MUST be supported. + +4.5. Addressing + +4.5.1. IP Version 6 Addressing Architecture - RFC 3513 + + The IPv6 Addressing Architecture [RFC-3513] MUST be supported as + updated by [RFC-3879]. + +4.5.2. IPv6 Stateless Address Autoconfiguration - RFC 2462 + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification MUST be supported for nodes that are hosts. + Static address can be supported as well. + + Nodes that are routers MUST be able to generate link local addresses + as described in RFC 2462 [RFC-2462]. + + From 2462: + + The autoconfiguration process specified in this document applies + only to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be + configured by some other means. However, it is expected that + routers will generate link-local addresses using the mechanism + described in this document. In addition, routers are expected to + successfully pass the Duplicate Address Detection procedure + described in this document on all addresses prior to assigning + them to an interface. + + Duplicate Address Detection (DAD) MUST be supported. + +4.5.3. Privacy Extensions for Address Configuration in IPv6 - RFC 3041 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + SHOULD be supported. It is recommended that this behavior be + configurable on a connection basis within each application when + available. It is noted that a number of applications do not work + with addresses generated with this method, while other applications + work quite well with them. + +4.5.4. Default Address Selection for IPv6 - RFC 3484 + + The rules specified in the Default Address Selection for IPv6 + [RFC-3484] document MUST be implemented. It is expected that IPv6 + nodes will need to deal with multiple addresses. + + + +Loughney Informational [Page 7] + +RFC 4294 IPv6 Node Requirements April 2006 + + +4.5.5. Stateful Address Autoconfiguration + + Stateful Address Autoconfiguration MAY be supported. DHCPv6 + [RFC-3315] is the standard stateful address configuration protocol; + see Section 5.3 for DHCPv6 support. + + Nodes which do not support Stateful Address Autoconfiguration may be + unable to obtain any IPv6 addresses, aside from link-local addresses, + when it receives a router advertisement with the 'M' flag (Managed + address configuration) set and that contains no prefixes advertised + for Stateless Address Autoconfiguration (see Section 4.5.2). + Additionally, such nodes will be unable to obtain other configuration + information, such as the addresses of DNS servers when it is + connected to a link over which the node receives a router + advertisement in which the 'O' flag ("Other stateful configuration") + is set. + +4.6. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 + + Nodes that need to join multicast groups SHOULD implement MLDv2 + [RFC-3810]. However, if the node has applications that only need + support for Any-Source Multicast [RFC-3569], the node MAY implement + MLDv1 [RFC-2710] instead. If the node has applications that need + support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node + MUST support MLDv2 [RFC-3810]. + + When MLD is used, the rules in the "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be + followed. + +5. DNS and DHCP + +5.1. DNS + + DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363], + and [RFC-3596]. Not all nodes will need to resolve names; those that + will never need to resolve DNS names do not need to implement + resolver functionality. However, the ability to resolve names is a + basic infrastructure capability that applications rely on and + generally needs to be supported. All nodes that need to resolve + names SHOULD implement stub-resolver [RFC-1034] functionality, as in + RFC 1034, Section 5.3.1, with support for: + + - AAAA type Resource Records [RFC-3596]; + + - reverse addressing in ip6.arpa using PTR records [RFC-3152]; + + + + + +Loughney Informational [Page 8] + +RFC 4294 IPv6 Node Requirements April 2006 + + + - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 + octets. + + Those nodes are RECOMMENDED to support DNS security extensions + [RFC-4033], [RFC-4034], and [RFC-4035]. + + Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC-3363]. + +5.2. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC 3315 + +5.2.1. Managed Address Configuration + + The method by which IPv6 nodes that use DHCP for address assignment + can obtain IPv6 addresses and other configuration information upon + receipt of a Router Advertisement with the 'M' flag set is described + in Section 5.5.3 of RFC 2462. + + In addition, in the absence of a router, those IPv6 nodes that use + DHCP for address assignment MUST initiate DHCP to obtain IPv6 + addresses and other configuration information, as described in + Section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP for + address assignment can ignore the 'M' flag in Router Advertisements. + +5.2.2. Other Configuration Information + + The method by which IPv6 nodes that use DHCP to obtain other + configuration information can obtain other configuration information + upon receipt of a Router Advertisement with the 'O' flag set is + described in Section 5.5.3 of RFC 2462. + + Those IPv6 nodes that use DHCP to obtain other configuration + information initiate DHCP for other configuration information upon + receipt of a Router Advertisement with the 'O' flag set, as described + in Section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP + for other configuration information can ignore the 'O' flag in Router + Advertisements. + + An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to + obtain other configuration information. + +5.3.3. Use of Router Advertisements in Managed Environments + + Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + are expected to determine their default router information and on- + link prefix information from received Router Advertisements. + + + + + +Loughney Informational [Page 9] + +RFC 4294 IPv6 Node Requirements April 2006 + + +6. IPv4 Support and Transition + + IPv6 nodes MAY support IPv4. + +6.1. Transition Mechanisms + +6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 + + If an IPv6 node implements dual stack and tunneling, then [RFC-4213] + MUST be supported. + +7. Mobile IP + + The Mobile IPv6 [RFC-3775] specification defines requirements for the + following types of nodes: + + - mobile nodes + + - correspondent nodes with support for route optimization + + - home agents + + - all IPv6 routers + + Hosts MAY support mobile node functionality described in Section 8.5 + of [RFC-3775], including support of generic packet tunneling [RFC- + 2473] and secure home agent communications [RFC-3776]. + + Hosts SHOULD support route optimization requirements for + correspondent nodes described in Section 8.2 of [RFC-3775]. + + Routers SHOULD support the generic mobility-related requirements for + all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY + support the home agent functionality described in Section 8.4 of + [RFC-3775], including support of [RFC-2473] and [RFC-3776]. + +8. Security + + This section describes the specification of IPsec for the IPv6 node. + +8.1. Basic Architecture + + Security Architecture for the Internet Protocol [RFC-4301] MUST be + supported. + + + + + + + +Loughney Informational [Page 10] + +RFC 4294 IPv6 Node Requirements April 2006 + + +8.2. Security Protocols + + ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported. + +8.3. Transforms and Algorithms + + Current IPsec RFCs specify the support of transforms and algorithms + for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and + HMAC-MD5-96. However, "Cryptographic Algorithm Implementation + Requirements For ESP And AH" [RFC-4305] contains the current set of + mandatory to implement algorithms for ESP and AH. It also specifies + algorithms that should be implemented because they are likely to be + promoted to mandatory at some future time. IPv6 nodes SHOULD conform + to the requirements in [RFC-4305], as well as the requirements + specified below. + + Since ESP encryption and authentication are both optional, support + for the NULL encryption algorithm [RFC-2410] and the NULL + authentication algorithm [RFC-4303] MUST be provided to maintain + consistency with the way these services are negotiated. However, + while authentication and encryption can each be NULL, they MUST NOT + both be NULL. The NULL encryption algorithm is also useful for + debugging. + + The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported + within ESP. Security issues related to the use of DES are discussed + in [DESDIFF], [DESINT], and [DESCRACK]. DES-CBC is still listed as + required by the existing IPsec RFCs, but updates to these RFCs will + be published in the near future. DES provides 56 bits of protection, + which is no longer considered sufficient. + + The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP + MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC-2403] + within AH and ESP MAY also be supported. + + The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the + same security issues as DES-CBC, and the 3DES-CBC algorithm within + ESP MUST be supported to ensure interoperability. + + The AES-128-CBC algorithm [RFC-3602] MUST also be supported within + ESP. AES-128 is expected to be a widely available, secure, and + efficient algorithm. While AES-128-CBC is not required by the + current IPsec RFCs, it is expected to become required in the future. + + + + + + + + +Loughney Informational [Page 11] + +RFC 4294 IPv6 Node Requirements April 2006 + + +8.4. Key Management Methods + + An implementation MUST support the manual configuration of the + security key and SPI. The SPI configuration is needed in order to + delineate between multiple keys. + + Key management SHOULD be supported. Examples of key management + systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include + key management functions. + + Where key refresh, anti-replay features of AH and ESP, or on-demand + creation of Security Associations (SAs) is required, automated keying + MUST be supported. + + Key management methods for multicast traffic are also being worked on + by the MSEC WG. + +9. Router-Specific Functionality + + This section defines general host considerations for IPv6 nodes that + act as routers. Currently, this section does not discuss routing- + specific requirements. + +9.1. General + +9.1.1. IPv6 Router Alert Option - RFC 2711 + + The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- + Hop Header that is used in conjunction with some protocols (e.g., + RSVP [RFC-2205] or MLD [RFC-2710]). The Router Alert option will + need to be implemented whenever protocols that mandate its usage are + implemented. See Section 4.6. + +9.1.2. Neighbor Discovery for IPv6 - RFC 2461 + + Sending Router Advertisements and processing Router Solicitation MUST + be supported. + +10. Network Management + + Network Management MAY be supported by IPv6 nodes. However, for IPv6 + nodes that are embedded devices, network management may be the only + possible way of controlling these nodes. + +10.1. Management Information Base Modules (MIBs) + + The following two MIBs SHOULD be supported by nodes that support an + SNMP agent. + + + +Loughney Informational [Page 12] + +RFC 4294 IPv6 Node Requirements April 2006 + + +10.1.1. IP Forwarding Table MIB + + IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that + support an SNMP agent. + +10.1.2. Management Information Base for the Internet Protocol (IP) + + IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP + agent. + +11. Security Considerations + + This document does not affect the security of the Internet, but + implementations of IPv6 are expected to support a minimum set of + security features to ensure security on the Internet. "IP Security + Document Roadmap" [RFC-2411] is important for everyone to read. + + The security considerations in RFC 2460 state the following: + + The security features of IPv6 are described in the Security + Architecture for the Internet Protocol [RFC-2401]. + + RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for + the security features of IPv6. + +12. References + +12.1. Normative References + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [RFC-2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 + within ESP and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 + within ESP and AH", RFC 2404, November 1998. + + + + +Loughney Informational [Page 13] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm + and Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security + Document Roadmap", RFC 2411, November 1998. + + [RFC-2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version + 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [RFC-2463] Conta, A. and S. Deering, "Internet Control Message + Protocol (ICMPv6) for the Internet Protocol Version 6 + (IPv6) Specification", RFC 2463, December 1998. + + [RFC-2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC + 2472, December 1998. + + [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in + IPv6 Specification", RFC 2473, December 1998. + + [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC-2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and A. Jackson, "IPv6 Router Alert + Option", RFC 2711, October 1999. + + [RFC-3041] Narten, T. and R. Draves, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC + 3041, January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, + August 2001. + + + +Loughney Informational [Page 14] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC-3363] 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. + + [RFC-3484] Frye, R., Levi, D., Routhier, S., and B. Wijnen, + "Coexistence between Version 1, Version 2, and Version + 3 of the Internet-standard Network Management + Framework", BCP 74, RFC 3584, August 2003. + + [RFC-3513] Hinden, R. and S. Deering, "Internet Protocol Version + 6 (IPv6) Addressing Architecture", RFC 3513, April + 2003. + + [RFC-3590] Haberman, B., "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol", RFC + 3590, September 2003. + + [RFC-3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC-3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC + Cipher Algorithm and Its Use with IPsec", RFC 3602, + September 2003. + + [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility + Support in IPv6", RFC 3775, June 2004. + + [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using + IPsec to Protect Mobile IPv6 Signaling Between Mobile + Nodes and Home Agents", RFC 3776, June 2004. + + [RFC-3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC-3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC-4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, + April 2006. + + [RFC-4293] Routhier, S., Ed., "Management Information Base for + the Internet Protocol (IP)", RFC 4293, April 2006. + + + +Loughney Informational [Page 15] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-4301] Kent, S. and R. Atkinson, "Security Architecture for + the Internet Protocol", RFC 4301, December 2005. + + [RFC-4302] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [RFC-4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + [RFC-4305] Eastlake 3rd, D., "Cryptographic Algorithm + Implementation Requirements for Encapsulating Security + Payload (ESP) and Authentication Header (AH)", RFC + 4305, December 2005. + +12.2. Informative References + + [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of + DES-like cryptosystems", Journal of Cryptology Vol 4, + Jan 1991. + + [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA + 2000. + + [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, + Danvers, MA, April 1995. + + [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home + Address Options", Work in Progress. + + [RFC-793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, + September 1997. + + [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over + Ethernet Networks", RFC 2464, December 1998. + + [RFC-2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over + ATM Networks", RFC 2492, January 1999. + + + + + +Loughney Informational [Page 16] + +RFC 4294 IPv6 Node Requirements April 2006 + + + [RFC-2675] Borman, D., Deering, S., and R. Hinden, "IPv6 + Jumbograms", RFC 2675, August 1999. + + [RFC-4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [RFC-3569] Bhattacharyya, S., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [RFC-3736] Droms, R., "Stateless Dynamic Host Configuration + Protocol (DHCP) Service for IPv6", RFC 3736, April + 2004. + + [RFC-4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet + Network Addresses", RFC 4001, February 2005. + + [RFC-4033] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC-4034] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + [RFC-4035] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC-4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) + Protocol", RFC 4306, December 2005. + + [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for + IP", Work in Progress. + + + + + + + + + + + + + + + + +Loughney Informational [Page 17] + +RFC 4294 IPv6 Node Requirements April 2006 + + +13. Authors and Acknowledgements + + This document was written by the IPv6 Node Requirements design team: + + Jari Arkko + [jari.arkko@ericsson.com] + + Marc Blanchet + [marc.blanchet@viagenie.qc.ca] + + Samita Chakrabarti + [samita.chakrabarti@eng.sun.com] + + Alain Durand + [alain.durand@sun.com] + + Gerard Gastaud + [gerard.gastaud@alcatel.fr] + + Jun-ichiro itojun Hagino + [itojun@iijlab.net] + + Atsushi Inoue + [inoue@isl.rdc.toshiba.co.jp] + + Masahiro Ishiyama + [masahiro@isl.rdc.toshiba.co.jp] + + John Loughney + [john.loughney@nokia.com] + + Rajiv Raghunarayan + [raraghun@cisco.com] + + Shoichi Sakane + [shouichi.sakane@jp.yokogawa.com] + + Dave Thaler + [dthaler@windows.microsoft.com] + + Juha Wiljakka + [juha.wiljakka@Nokia.com] + + The authors would like to thank Ran Atkinson, Jim Bound, Brian + Carpenter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas + Narten, Juha Ollila, and Pekka Savola for their comments. + + + + + +Loughney Informational [Page 18] + +RFC 4294 IPv6 Node Requirements April 2006 + + +Editor's Contact Information + + Comments or questions regarding this document should be sent to the + IPv6 Working Group mailing list (ipv6@ietf.org) or to: + + John Loughney + Nokia Research Center + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + Phone: +358 50 483 6242 + EMail: John.Loughney@Nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney Informational [Page 19] + +RFC 4294 IPv6 Node Requirements April 2006 + + +Full 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the 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). + + + + + + + +Loughney Informational [Page 20] + diff --git a/doc/rfc/rfc4339.txt b/doc/rfc/rfc4339.txt new file mode 100644 index 000000000000..a6f29d9f4309 --- /dev/null +++ b/doc/rfc/rfc4339.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group J. Jeong, Ed. +Request for Comments: 4339 ETRI/University of Minnesota +Category: Informational February 2006 + + + IPv6 Host Configuration of DNS Server Information Approaches + + +Status of This Memo + + This memo provides information for 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). + +IESG Note + + This document describes three different approaches for the + configuration of DNS name resolution server information in IPv6 + hosts. + + There is not an IETF consensus on which approach is preferred. The + analysis in this document was developed by the proponents for each + approach and does not represent an IETF consensus. + + The 'RA option' and 'Well-known anycast' approaches described in this + document are not standardized. Consequently the analysis for these + approaches might not be completely applicable to any specific + proposal that might be proposed in the future. + +Abstract + + This document describes three approaches for IPv6 recursive DNS + server address configuration. It details the operational attributes + of three solutions: RA option, DHCPv6 option, and well-known anycast + addresses for recursive DNS servers. Additionally, it suggests the + deployment scenarios in four kinds of networks (ISP, enterprise, + 3GPP, and unmanaged networks) considering multi-solution resolution. + + + + + + + + + + +Jeong Informational [Page 1] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................3 + 3. IPv6 DNS Configuration Approaches ...............................3 + 3.1. RA Option ..................................................3 + 3.1.1. Advantages ..........................................4 + 3.1.2. Disadvantages .......................................5 + 3.1.3. Observations ........................................5 + 3.2. DHCPv6 Option ..............................................6 + 3.2.1. Advantages ..........................................7 + 3.2.2. Disadvantages .......................................8 + 3.2.3. Observations ........................................9 + 3.3. Well-known Anycast Addresses ...............................9 + 3.3.1. Advantages .........................................10 + 3.3.2. Disadvantages ......................................10 + 3.3.3. Observations .......................................10 + 4. Interworking among IPv6 DNS Configuration Approaches ...........11 + 5. Deployment Scenarios ...........................................12 + 5.1. ISP Network ...............................................12 + 5.1.1. RA Option Approach .................................13 + 5.1.2. DHCPv6 Option Approach .............................13 + 5.1.3. Well-known Anycast Addresses Approach ..............14 + 5.2. Enterprise Network ........................................14 + 5.3. 3GPP Network ..............................................15 + 5.3.1. Currently Available Mechanisms and + Recommendations ....................................15 + 5.3.2. RA Extension .......................................16 + 5.3.3. Stateless DHCPv6 ...................................16 + 5.3.4. Well-known Addresses ...............................17 + 5.3.5. Recommendations ....................................18 + 5.4. Unmanaged Network .........................................18 + 5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18 + 5.4.2. Case B: A Dual-stack Gateway Connected to a + Dual-stack ISP .....................................19 + 5.4.3. Case C: A Dual-stack Gateway Connected to + an IPv4-only ISP ...................................19 + 5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19 + 6. Security Considerations ........................................19 + 6.1. RA Option .................................................20 + 6.2. DHCPv6 Option .............................................21 + 6.3. Well-known Anycast Addresses ..............................21 + 7. Contributors ...................................................21 + 8. Acknowledgements ...............................................23 + 9. References .....................................................23 + 9.1. Normative References ......................................23 + 9.2. Informative References ....................................23 + + + + +Jeong Informational [Page 2] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +1. Introduction + + Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address + Autoconfiguration provide ways to configure either fixed or mobile + nodes with one or more IPv6 addresses, default routes, and some other + parameters [1][2]. To support the access to additional services in + the Internet that are identified by a DNS name, such as a web server, + the configuration of at least one recursive DNS server is also needed + for DNS name resolution. + + This document describes three approaches of recursive DNS server + address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6 + option [3]-[5], and (c) well-known anycast addresses for recursive + DNS servers [7]. Also, it suggests the applicable scenarios for four + kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP + network, and (d) unmanaged network. + + This document is just an analysis of each possible approach, and it + does not recommend a particular approach or combination of + approaches. Some approaches may even not be adopted at all as a + result of further discussion. + + Therefore, the objective of this document is to help the audience + select the approaches suitable for IPv6 host configuration of + recursive DNS servers. + +2. Terminology + + This document uses the terminology described in [1]-[7]. In + addition, a new term is defined below: + + o Recursive DNS Server (RDNSS): Server which provides a recursive + DNS resolution service. + +3. IPv6 DNS Configuration Approaches + + In this section, the operational attributes of the three solutions + are described in detail. + +3.1. RA Option + + The RA approach defines a new ND option, called the RDNSS option, + that contains a recursive DNS server address [6]. Existing ND + transport mechanisms (i.e., advertisements and solicitations) are + used. This works in the same way that nodes learn about routers and + prefixes. An IPv6 host can configure the IPv6 addresses of one or + more RDNSSes via RA message periodically sent by a router or + solicited by a Router Solicitation (RS). + + + +Jeong Informational [Page 3] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + This approach needs RDNSS information to be configured in the routers + doing the advertisements. The configuration of RDNSS addresses can + be performed manually by an operator or in other ways, such as + automatic configuration through a DHCPv6 client running on the + router. An RA message with one RDNSS option can include as many + RDNSS addresses as needed [6]. + + Through the ND protocol and RDNSS option, along with a prefix + information option, an IPv6 host can perform network configuration of + its IPv6 address and RDNSS simultaneously [1][2]. The RA option for + RDNSS can be used on any network that supports the use of ND. + + The RA approach is useful in some mobile environments where the + addresses of the RDNSSes are changing because the RA option includes + a lifetime field that allows client to use RDNSSes nearer to the + client. This can be configured to a value that will require the + client to time out the entry and switch over to another RDNSS address + [6]. However, from the viewpoint of implementation, the lifetime + field would seem to make matters a bit more complex. Instead of just + writing to a DNS configuration file, such as resolv.conf for the list + of RDNSS addresses, we have to have a daemon around (or a program + that is called at the defined intervals) that keeps monitoring the + lifetime of RDNSSes all the time. + + The preference value of RDNSS, included in the RDNSS option, allows + IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this + can be used for the load balancing of RDNSSes. + +3.1.1. Advantages + + The RA option for RDNSS has a number of advantages. These include: + + 1. The RA option is an extension of existing ND/Autoconfig + mechanisms [1][2] and does not require a change in the base ND + protocol. + + 2. This approach, like ND, works well on a variety of link types, + including point-to-point links, point-to-multipoint, and + multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1] + states, however, that there may be some link types on which ND is + not feasible; on such links, some other mechanisms will be needed + for DNS configuration. + + 3. All the information a host needs to run the basic Internet + applications (such as the email, web, ftp, etc.) can be obtained + with the addition of this option to ND and address + autoconfiguration. The use of a single mechanism is more + reliable and easier to provide than when the RDNSS information is + + + +Jeong Informational [Page 4] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + learned via another protocol mechanism. Debugging problems when + multiple protocol mechanisms are being used is harder and much + more complex. + + 4. This mechanism works over a broad range of scenarios and + leverages IPv6 ND. This works well on links that are high + performance (e.g., Ethernet LANs) and low performance (e.g., + cellular networks). In the latter case, by combining the RDNSS + information with the other information in the RA, the host can + learn all the information needed to use most Internet + applications, such as the web, in a single packet. This not only + saves bandwidth, but also minimizes the delay needed to learn the + RDNSS information. + + 5. The RA approach could be used as a model for similar types of + configuration information. New RA options for other server + addresses, such as NTP server address, that are common to all + clients on a subnet would be easy to define. + +3.1.2. Disadvantages + + 1. ND is mostly implemented in the kernel of the operating system. + Therefore, if ND supports the configuration of some additional + services, such as DNS servers, ND should be extended in the + kernel and complemented by a user-land process. DHCPv6, however, + has more flexibility for the extension of service discovery + because it is an application layer protocol. + + 2. The current ND framework should be modified to facilitate the + synchronization between another ND cache for RDNSSes in the + kernel space and the DNS configuration file in the user space. + Because it is unacceptable to write and rewrite to the DNS + configuration file (e.g., resolv.conf) from the kernel, another + approach is needed. One simple approach to solve this is to have + a daemon listening to what the kernel conveys, and to have the + daemon do these steps, but such a daemon is not needed with the + current ND framework. + + 3. It is necessary to configure RDNSS addresses at least at one + router on every link where this information needs to be + configured via the RA option. + +3.1.3. Observations + + The proposed RDNSS RA option, along with the IPv6 ND and + Autoconfiguration, allows a host to obtain all of the information it + needs to access basic Internet services like the web, email, ftp, + etc. This is preferable in the environments where hosts use RAs to + + + +Jeong Informational [Page 5] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + autoconfigure their addresses and all the hosts on the subnet share + the same router and server addresses. If the configuration + information can be obtained from a single mechanism, it is preferable + because it does not add additional delay, and because it uses a + minimum of bandwidth. Environments like this include homes, public + cellular networks, and enterprise environments where no per host + configuration is needed. + + DHCPv6 is preferable where it is being used for address configuration + and if there is a need for host specific configuration [3]-[5]. + Environments like this are most likely to be the enterprise + environments where the local administration chooses to have per host + configuration control. + +3.2. DHCPv6 Option + + DHCPv6 [3] includes the "DNS Recursive Name Server" option, through + which a host can obtain a list of IP addresses of recursive DNS + servers [5]. The DNS Recursive Name Server option carries a list of + IPv6 addresses of RDNSSes to which the host may send DNS queries. + The DNS servers are listed in the order of preference for use by the + DNS resolver on the host. + + The DNS Recursive Name Server option can be carried in any DHCPv6 + Reply message, in response to either a Request or an Information + request message. Thus, the DNS Recursive Name Server option can be + used either when DHCPv6 is used for address assignment, or when + DHCPv6 is used only for other configuration information as stateless + DHCPv6 [4]. + + Stateless DHCPv6 can be deployed either by using DHCPv6 servers + running on general-purpose computers, or on router hardware. Several + router vendors currently implement stateless DHCPv6 servers. + Deploying stateless DHCPv6 in routers has the advantage that no + special hardware is required, and it should work well for networks + where DHCPv6 is needed for very straightforward configuration of + network devices. + + However, routers can also act as DHCPv6 relay agents. In this case, + the DHCPv6 server need not be on the router; it can be on a general + purpose computer. This has the potential to give the operator of the + DHCPv6 server more flexibility in how the DHCPv6 server responds to + individual clients that can easily be given different configuration + information based on their identity, or for any other reason. + Nothing precludes adding this flexibility to a router, but generally, + in current practice, DHCP servers running on general-purpose hosts + tend to have more configuration options than those that are embedded + in routers. + + + +Jeong Informational [Page 6] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 + clients that use a stateful configuration assignment. To do this, + the DHCPv6 server sends a Reconfigure message to the client. The + client validates the Reconfigure message, and then contacts the + DHCPv6 server to obtain updated configuration information. By using + this mechanism, it is currently possible to propagate new + configuration information to DHCPv6 clients as this information + changes. + + The DHC Working Group has standardized an additional mechanism + through which configuration information, including the list of + RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns + a lifetime to configuration information obtained through DHCPv6. At + the expiration of the lifetime, the host contacts the DHCPv6 server + to obtain updated configuration information, including the list of + RDNSSes. This lifetime gives the network administrator another + mechanism to configure hosts with new RDNSSes by controlling the time + at which the host refreshes the list. + + The DHC Working Group has also discussed the possibility of defining + an extension to DHCPv6 that would allow the use of multicast to + provide configuration information to multiple hosts with a single + DHCPv6 message. Because of the lack of deployment experience, the WG + has deferred consideration of multicast DHCPv6 configuration at this + time. Experience with DHCPv4 has not identified a requirement for + multicast message delivery, even in large service provider networks + with tens of thousands of hosts that may initiate a DHCPv4 message + exchange simultaneously. + +3.2.1. Advantages + + The DHCPv6 option for RDNSS has a number of advantages. These + include: + + 1. DHCPv6 currently provides a general mechanism for conveying + network configuration information to clients. Configuring DHCPv6 + servers in this way allows the network administrator to configure + RDNSSes, the addresses of other network services, and location- + specific information, such as time zones. + + 2. As a consequence, when the network administrator goes to + configure DHCPv6, all the configuration information can be + managed through a single service, typically with a single user + interface and a single configuration database. + + + + + + + +Jeong Informational [Page 7] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + 3. DHCPv6 allows for the configuration of a host with information + specific to that host, so that hosts on the same link can be + configured with different RDNSSes and with other configuration + information. + + 4. A mechanism exists for extending DHCPv6 to support the + transmission of additional configuration that has not yet been + anticipated. + + 5. Hosts that require other configuration information, such as the + addresses of SIP servers and NTP servers, are likely to need + DHCPv6 for other configuration information. + + 6. The specification for configuration of RDNSSes through DHCPv6 is + available as an RFC. No new protocol extensions (such as new + options) are necessary. + + 7. Interoperability among independent implementations has been + demonstrated. + +3.2.2. Disadvantages + + The DHCPv6 option for RDNSS has a few disadvantages. These include: + + 1. Update currently requires a message from server (however, see + [8]). + + 2. Because DNS information is not contained in RA messages, the host + must receive two messages from the router and must transmit at + least one message to the router. On networks where bandwidth is + at a premium, this is a disadvantage, although on most networks + it is not a practical concern. + + 3. There is an increased latency for initial configuration. In + addition to waiting for an RA message, the client must now + exchange packets with a DHCPv6 server. Even if it is locally + installed on a router, this will slightly extend the time + required to configure the client. For clients that are moving + rapidly from one network to another, this will be a disadvantage. + + + + + + + + + + + + +Jeong Informational [Page 8] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +3.2.3. Observations + + In the general case, on general-purpose networks, stateless DHCPv6 + provides significant advantages and no significant disadvantages. + Even in the case where bandwidth is at a premium and low latency is + desired, if hosts require other configuration information in addition + to a list of RDNSSes or if hosts must be configured selectively, + those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive + name server option will be advantageous. + + However, we are aware of some applications where it would be + preferable to put the RDNSS information into an RA packet; for + example, in a mobile phone network, where bandwidth is at a premium + and extremely low latency is desired. The DNS configuration based on + RA should be standardized so as to allow these special applications + to be handled using DNS information in the RA packet. + +3.3. Well-known Anycast Addresses + + Anycast uses the same routing system as unicast [9]. However, + administrative entities are local ones. The local entities may + accept unicast routes (including default routes) to anycast servers + from adjacent entities. The administrative entities should not + advertise their peer routes to their internal anycast servers, if + they want to prohibit external access from some peers to the servers. + If some advertisement is inevitable (such as the case with default + routes), the packets to the servers should be blocked at the boundary + of the entities. Thus, for this anycast, not only unicast routing + but also unicast ND protocols can be used as is. + + First of all, the well-known anycast addresses approach is much + different from that discussed by the IPv6 Working Group in the past + [7]. Note that "anycast" in this memo is simpler than that of RFC + 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to + have multiple servers on a single link sharing an anycast address. + That is, on a link, an anycast address is assumed to be unique. DNS + clients today already have redundancy by having multiple well-known + anycast addresses configured as RDNSS addresses. There is no point + in having multiple RDNSSes sharing an anycast address on a single + link. + + The approach with well-known anycast addresses is to set multiple + well-known anycast addresses in clients' resolver configuration files + from the beginning as, say, factory default. Thus, there is no + transport mechanism and no packet format [7]. + + An anycast address is an address shared by multiple servers (in this + case, the servers are RDNSSes). A request from a client to the + + + +Jeong Informational [Page 9] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + anycast address is routed to a server selected by the routing system. + However, it is a bad idea to mandate "site" boundary on anycast + addresses, because most users do not have their own servers and want + to access their ISPs across their site boundaries. Larger sites may + also depend on their ISPs or may have their own RDNSSes within "site" + boundaries. + +3.3.1. Advantages + + The basic advantage of the well-known addresses approach is that it + uses no transport mechanism. Thus, the following apply: + + 1. There is no delay to get the response and no further delay by + packet losses. + + 2. The approach can be combined with any other configuration + mechanisms, such as the RA-based approach and DHCP-based + approach, as well as the factory default configuration. + + 3. The approach works over any environment where DNS works. + + Another advantage is that this approach only needs configuration of + the DNS servers as a router (or configuration of a proxy router). + Considering that DNS servers do need configuration, the amount of + overall configuration effort is proportional to the number of DNS + servers and it scales linearly. Note that, in the simplest case, + where a subscriber to an ISP does not have a DNS server, the + subscriber naturally accesses DNS servers of the ISP, even though the + subscriber and the ISP do nothing and there is no protocol to + exchange DNS server information between the subscriber and the ISP. + +3.3.2. Disadvantages + + The well-known anycast addresses approach requires that DNS servers + (or routers near to them as a proxy) act as routers to advertise + their anycast addresses to the routing system, which requires some + configuration (see the last paragraph of the previous section on the + scalability of the effort). In addition, routers at the boundary of + the "site" might need the configuration of route filters to prevent + providing DNS services for parties outside the "site" and the + possibility of denial of service attacks on the internal DNS + infrastructure. + +3.3.3. Observations + + If other approaches are used in addition, the well-known anycast + addresses should also be set in RA or DHCP configuration files to + reduce the configuration effort of users. + + + +Jeong Informational [Page 10] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The redundancy by multiple RDNSSes is better provided by multiple + servers with different anycast addresses than by multiple servers + sharing the same anycast address, because the former approach allows + stale servers to generate routes to their anycast addresses. Thus, + in a routing domain (or domains sharing DNS servers), there will be + only one server with an anycast address unless the domain is so large + that load distribution is necessary. + + Small ISPs will operate one RDNSS at each anycast address that is + shared by all the subscribers. Large ISPs may operate multiple + RDNSSes at each anycast address to distribute and reduce load, where + the boundary between RDNSSes may be fixed (redundancy is still + provided by multiple addresses) or change dynamically. DNS packets + with the well-known anycast addresses are not expected (though not + prohibited) to cross ISP boundaries, as ISPs are expected to be able + to take care of themselves. + + Because "anycast" in this memo is simpler than that of RFC 1546 [9] + and RFC 3513 [10], where it is assumed to be administratively + prohibited to have multiple servers on a single link sharing an + anycast address, anycast in this memo should be implemented as + UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related + instability disappears. Thus, in the well-known anycast addresses + approach, anycast can and should use the anycast address as a source + unicast (according to RFC 3513 [10]) address of packets of UDP and + TCP responses. With TCP, if a route flips and packets to an anycast + address are routed to a new server, it is expected that the flip is + detected by ICMP or sequence number inconsistency, and that the TCP + connection is reset and retried. + +4. Interworking among IPv6 DNS Configuration Approaches + + Three approaches can work together for IPv6 host configuration of + RDNSS. This section shows a consideration on how these approaches + can interwork. + + For ordering between RA and DHCP approaches, the O (Other stateful + configuration) flag in the RA message can be used [6][28]. If no + RDNSS option is included, an IPv6 host may perform DNS configuration + through DHCPv6 [3]-[5] regardless of whether the O flag is set or + not. + + The well-known anycast addresses approach fully interworks with the + other approaches. That is, the other approaches can remove the + configuration effort on servers by using the well-known addresses as + the default configuration. Moreover, the clients preconfigured with + the well-known anycast addresses can be further configured to use + other approaches to override the well-known addresses, if the + + + +Jeong Informational [Page 11] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + configuration information from other approaches is available. + Otherwise, all the clients need to have the well-known anycast + addresses preconfigured. In order to use the anycast approach along + with two other approaches, there are three choices as follows: + + 1. The first choice is that well-known addresses are used as last + resort, when an IPv6 host cannot get RDNSS information through RA + and DHCP. The well-known anycast addresses have to be + preconfigured in all of IPv6 hosts' resolver configuration files. + + 2. The second is that an IPv6 host can configure well-known + addresses as the most preferable in its configuration file even + though either an RA option or DHCP option is available. + + 3. The last is that the well-known anycast addresses can be set in + RA or DHCP configuration to reduce the configuration effort of + users. According to either the RA or DHCP mechanism, the well- + known addresses can be obtained by an IPv6 host. Because this + approach is the most convenient for users, the last option is + recommended. + + Note: This section does not necessarily mean that this document + suggests adopting all of these three approaches and making them + interwork in the way described here. In fact, as a result of further + discussion some approaches may not even be adopted at all. + +5. Deployment Scenarios + + Regarding the DNS configuration on the IPv6 host, several mechanisms + are being considered by the DNSOP Working Group, such as RA option, + DHCPv6 option, and well-known preconfigured anycast addresses as of + today, and this document is a final result from the long thread. In + this section, we suggest four applicable scenarios of three + approaches for IPv6 DNS configuration. + + Note: In the applicable scenarios, authors do not implicitly push any + specific approaches into the restricted environments. No enforcement + is in each scenario, and all mentioned scenarios are probable. The + main objective of this work is to provide a useful guideline for IPv6 + DNS configuration. + +5.1. ISP Network + + A characteristic of an ISP network is that multiple Customer Premises + Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) + routers and that each PE connects multiple CPE devices to the + backbone network infrastructure [11]. The CPEs may be hosts or + routers. + + + +Jeong Informational [Page 12] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + If the CPE is a router, there is a customer network that is connected + to the ISP backbone through the CPE. Typically, each customer + network gets a different IPv6 prefix from an IPv6 PE router, but the + same RDNSS configuration will be distributed. + + This section discusses how the different approaches to distributing + DNS information are compared in an ISP network. + +5.1.1. RA Option Approach + + When the CPE is a host, the RA option for RDNSS can be used to allow + the CPE to get RDNSS information and /64 prefix information for + stateless address autoconfiguration at the same time when the host is + attached to a new subnet [6]. Because an IPv6 host must receive at + least one RA message for stateless address autoconfiguration and + router configuration, the host could receive RDNSS configuration + information in the RA without the overhead of an additional message + exchange. + + When the CPE is a router, the CPE may accept the RDNSS information + from the RA on the interface connected to the ISP and copy that + information into the RAs advertised in the customer network. + + This approach is more valuable in the mobile host scenario, in which + the host must receive at least an RA message for detecting a new + network, than in other scenarios generally, although the + administrator should configure RDNSS information on the routers. + Secure ND [12] can provide extended security when RA messages are + used. + +5.1.2. DHCPv6 Option Approach + + DHCPv6 can be used for RDNSS configuration through the use of the DNS + option, and can provide other configuration information in the same + message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is + already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or + stateless DHCP [4] is not nearly as complex as a full DHCPv6 + implementation. DHCP is a client-server model protocol, so ISPs can + handle user identification on its network intentionally; also, + authenticated DHCP [13] can be used for secure message exchange. + + The expected model for deployment of IPv6 service by ISPs is to + assign a prefix to each customer, which will be used by the customer + gateway to assign a /64 prefix to each network in the customer's + network. Prefix delegation with DHCP (DHCPv6 PD) has already been + adopted by ISPs for automating the assignment of the customer prefix + to the customer gateway [15]. DNS configuration can be carried in + the same DHCPv6 message exchange used for DHCPv6 to provide that + + + +Jeong Informational [Page 13] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + information efficiently, along with any other configuration + information needed by the customer gateway or customer network. This + service model can be useful to Home or SOHO subscribers. The Home or + SOHO gateway, which is a customer gateway for ISP, can then pass that + RDNSS configuration information to the hosts in the customer network + through DHCP. + +5.1.3. Well-known Anycast Addresses Approach + + The well-known anycast addresses approach is also a feasible and + simple mechanism for ISP [7]. The use of well-known anycast + addresses avoids some of the security risks in rogue messages sent + through an external protocol such as RA or DHCPv6. The configuration + of hosts for the use of well-known anycast addresses requires no + protocol or manual configuration, but the configuration of routing + for the anycast addresses requires intervention on the part of the + network administrator. Also, the number of special addresses would + be equal to the number of RDNSSes that could be made available to + subscribers. + +5.2. Enterprise Network + + An enterprise network is defined as a network that has multiple + internal links, one or more router connections to one or more + providers, and is actively managed by a network operations entity + [14]. An enterprise network can get network prefixes from an ISP by + either manual configuration or prefix delegation [15]. In most + cases, because an enterprise network manages its own DNS domains, it + operates its own DNS servers for the domains. These DNS servers + within enterprise networks process recursive DNS name resolution + requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the + enterprise network can be performed as it is in Section 4, in which + three approaches can be used together as follows: + + 1. An IPv6 host can decide which approach is or may be used in its + subnet with the O flag in RA message [6][28]. As the first + choice in Section 4, well-known anycast addresses can be used as + a last resort when RDNSS information cannot be obtained through + either an RA option or a DHCP option. This case needs IPv6 hosts + to preconfigure the well-known anycast addresses in their DNS + configuration files. + + 2. When the enterprise prefers the well-known anycast approach to + others, IPv6 hosts should preconfigure the well-known anycast + addresses as it is in the first choice. + + 3. The last choice, a more convenient and transparent way, does not + need IPv6 hosts to preconfigure the well-known anycast addresses + + + +Jeong Informational [Page 14] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + because the addresses are delivered to IPv6 hosts via either the + RA option or DHCPv6 option as if they were unicast addresses. + This way is most recommended for the sake of the user's + convenience. + +5.3. 3GPP Network + + The IPv6 DNS configuration is a missing part of IPv6 + autoconfiguration and an important part of the basic IPv6 + functionality in the 3GPP User Equipment (UE). The higher-level + description of the 3GPP architecture can be found in [16], and + transition to IPv6 in 3GPP networks is analyzed in [17] and [18]. + + In the 3GPP architecture, there is a dedicated link between the UE + and the GGSN called the Packet Data Protocol (PDP) Context. This + link is created through the PDP Context activation procedure [19]. + There is a separate PDP context type for IPv4 and IPv6 traffic. If a + 3GPP UE user is communicating by using IPv6 (i.e., by having an + active IPv6 PDP context), it cannot be assumed that the user + simultaneously has an active IPv4 PDP context, and DNS queries could + be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow + it needs to discover the address of the RDNSS. Before IP-based + services (e.g., web browsing or e-mail) can be used, the IPv6 (and + IPv4) RDNSS addresses need to be discovered in the 3GPP UE. + + Section 5.3.1 briefly summarizes currently available mechanisms in + 3GPP networks and recommendations. 5.3.2 analyzes the Router + Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6 + mechanism, and 5.3.4 analyzes the well-known addresses approach. + Section 5.3.5 summarizes the recommendations. + +5.3.1. Currently Available Mechanisms and Recommendations + + 3GPP has defined a mechanism in which RDNSS addresses can be received + in the PDP context activation (a control plane mechanism). That is + called the Protocol Configuration Options Information Element (PCO- + IE) mechanism [20]. The RDNSS addresses can also be received over + the air (using text messages) or typed in manually in the UE. Note + that the two last mechanisms are not very well scalable. The UE user + most probably does not want to type IPv6 RDNSS addresses manually in + the user's UE. The use of well-known addresses is briefly discussed + in section 5.3.4. + + It is seen that the mechanisms above most probably are not sufficient + for the 3GPP environment. IPv6 is intended to operate in a zero- + configuration manner, no matter what the underlying network + infrastructure is. Typically, the RDNSS address is needed to make an + IPv6 node operational, and the DNS configuration should be as simple + + + +Jeong Informational [Page 15] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + as the address autoconfiguration mechanism. Note that there will be + additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP- + specific DNS configuration mechanisms (such as PCO-IE [20]) do not + work for those IP interfaces. In other words, a good IPv6 DNS + configuration mechanism should also work in a multi-access network + environment. + + From a 3GPP point of view, the best IPv6 DNS configuration solution + is feasible for a very large number of IPv6-capable UEs (even + hundreds of millions in one operator's network), is automatic, and + thus requires no user action. It is suggested that a lightweight, + stateless mechanism be standardized for use in all network + environments. The solution could then be used for 3GPP, 3GPP2, and + other access network technologies. Thus, not only is a light, + stateless IPv6 DNS configuration mechanism needed in 3GPP networks, + but also 3GPP networks and UEs would certainly benefit from the new + mechanism. + +5.3.2. RA Extension + + Router Advertisement extension [6] is a lightweight IPv6 DNS + configuration mechanism that requires minor changes in the 3GPP UE + IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in + the 3GPP architecture) IPv6 stack. This solution can be specified in + the IETF (no action is needed in the 3GPP) and taken in use in 3GPP + UEs and GGSNs. + + In this solution, an IPv6-capable UE configures DNS information via + an RA message sent by its default router (GGSN); i.e., the RDNSS + option for a recursive DNS server is included in the RA message. + This solution is easily scalable for a very large number of UEs. The + operator can configure the RDNSS addresses in the GGSN as a part of + normal GGSN configuration. The IPv6 RDNSS address is received in the + Router Advertisement, and an extra Round Trip Time (RTT) for asking + RDNSS addresses can be avoided. + + When one considers the cons, this mechanism still requires + standardization effort in the IETF, and the end nodes and routers + need to support this mechanism. The equipment software update + should, however, be pretty straightforward, and new IPv6 equipment + could support RA extension already from the beginning. + +5.3.3. Stateless DHCPv6 + + A DHCPv6-based solution needs the implementation of Stateless DHCP + [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the + operator's network. A possible configuration is such that the GGSN + works as a DHCP relay. + + + +Jeong Informational [Page 16] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The pros of a stateless DHCPv6-based solution are: + + 1. Stateless DHCPv6 is a standardized mechanism. + + 2. DHCPv6 can be used for receiving configuration information other + than RDNSS addresses; e.g., SIP server addresses. + + 3. DHCPv6 works in different network environments. + + 4. When DHCPv6 service is deployed through a single, centralized + server, the RDNSS configuration information can be updated by the + network administrator at a single source. + + Some issues with DHCPv6 in 3GPP networks are listed below: + + 1. DHCPv6 requires an additional server in the network unless the + (Stateless) DHCPv6 functionality is integrated into an existing + router. This means that there might be one additional server to + be maintained. + + 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing + (3GPP Stateless Address Autoconfiguration is typically used) and + is not automatically implemented in 3GPP IPv6 UEs. + + 3. Scalability and reliability of DHCPv6 in very large 3GPP networks + (with tens or hundreds of millions of UEs) may be an issue; at + least the redundancy needs to be taken care of. However, if the + DHCPv6 service is integrated into the network elements, such as a + router operating system, scalability and reliability is + comparable with other DNS configuration approaches. + + 4. It is sub-optimal to utilize the radio resources in 3GPP networks + for DHCPv6 messages if there is a simpler alternative is + available. + + * The use of stateless DHCPv6 adds one round-trip delay to the + case in which the UE can start transmitting data right after + the Router Advertisement. + + 5. If the DNS information (suddenly) changes, Stateless DHCPv6 + cannot automatically update the UE; see [21]. + +5.3.4. Well-known Addresses + + Using well-known addresses is also a feasible and light mechanism for + 3GPP UEs. Those well-known addresses can be preconfigured in the UE + software and the operator can make the corresponding configuration on + the network side. Thus, this is a very easy mechanism for the UE, + + + +Jeong Informational [Page 17] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + but it requires some configuration work in the network. When using + well-known addresses, UE forwards queries to any of the preconfigured + addresses. In the current proposal [7], IPv6 anycast addresses are + suggested. + + Note: An IPv6 DNS configuration proposal, based on the use of well- + known site-local addresses, was developed by the IPv6 Working Group; + it was seen as a feasible mechanism for 3GPP UEs, although no IETF + consensus was reached on this proposal. In the end, the deprecation + of IPv6 site-local addresses made it impossible to standardize a + mechanism that uses site-local addresses as well-known addresses. + However, as of this writing, this mechanism is implemented in some + operating systems and 3GPP UEs as a last resort of IPv6 DNS + configuration. + +5.3.5. Recommendations + + It is suggested that a lightweight, stateless DNS configuration + mechanism be specified as soon as possible. From a 3GPP UE and + network point of view, the Router Advertisement-based mechanism looks + most promising. The sooner a light, stateless mechanism is + specified, the sooner we can stop using well-known site-local + addresses for IPv6 DNS configuration. + +5.4. Unmanaged Network + + There are four deployment scenarios of interest in unmanaged networks + [22]: + + 1. A gateway that does not provide IPv6 at all, + + 2. A dual-stack gateway connected to a dual-stack ISP, + + 3. A dual-stack gateway connected to an IPv4-only ISP, and + + 4. A gateway connected to an IPv6-only ISP. + +5.4.1. Case A: Gateway Does Not Provide IPv6 at All + + In this case, the gateway does not provide IPv6; the ISP may or may + not provide IPv6. Automatic or Configured tunnels are the + recommended transition mechanisms for this scenario. + + The case where dual-stack hosts behind an NAT need access to an IPv6 + RDNSS cannot be entirely ruled out. The DNS configuration mechanism + has to work over the tunnel, and the underlying tunneling mechanism + could implement NAT traversal. The tunnel server assumes the role of + a relay (for both DHCP and well-known anycast addresses approaches). + + + +Jeong Informational [Page 18] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + The RA-based mechanism is relatively straightforward in its + operation, assuming the tunnel server is also the IPv6 router + emitting RAs. The well-known anycast addresses approach also seems + simple in operation across the tunnel, but the deployment model using + well-known anycast addresses in a tunneled environment is unclear or + not well understood. + +5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP + + This is similar to a typical IPv4 home user scenario, where DNS + configuration parameters are obtained using DHCP. The exception is + that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where + the DHCP server is stateful (it maintains the state for clients). + +5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP + + This is similar to Case B. If a gateway provides IPv6 connectivity + by managing tunnels, then it is also supposed to provide access to an + RDNSS. Like this, the tunnel for IPv6 connectivity originates from + the dual-stack gateway instead of from the host. + +5.4.4. Case D: A Gateway Connected to an IPv6-only ISP + + This is similar to Case B. + +6. Security Considerations + + As security requirements depend solely on applications and differ + from application to application, there can be no generic requirement + defined at the IP or application layer for DNS. + + However, note that cryptographic security requires configured secret + information and that full autoconfiguration and cryptographic + security are mutually exclusive. People insisting on secure, full + autoconfiguration will get false security, false autoconfiguration, + or both. + + In some deployment scenarios [17], where cryptographic security is + required for applications, the secret information for the + cryptographic security is preconfigured, through which application- + specific configuration data, including those for DNS, can be securely + configured. Note that if applications requiring cryptographic + security depend on DNS, the applications also require cryptographic + security to DNS. Therefore, the full autoconfiguration of DNS is not + acceptable. + + However, with full autoconfiguration, weaker but still reasonable + security is being widely accepted and will continue to be acceptable. + + + +Jeong Informational [Page 19] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + That is, with full autoconfiguration, which means there is no + cryptographic security for the autoconfiguration, it is already + assumed that the local environment is secure enough that the + information from the local autoconfiguration server has acceptable + security even without cryptographic security. Thus, the + communication between the local DNS client and local DNS server has + acceptable security. + + In autoconfiguring recursive servers, DNSSEC may be overkill, because + DNSSEC [23]-[25] needs the configuration and reconfiguration of + clients at root key roll-over [26][27]. Even if additional keys for + secure key roll-over are added at the initial configuration, they are + as vulnerable as the original keys to some forms of attack, such as + social hacking. Another problem of using DNSSEC and + autoconfiguration together is that DNSSEC requires secure time, which + means secure communication with autoconfigured time servers, which + requires configured secret information. Therefore, in order that the + autoconfiguration may be secure, configured secret information is + required. + + If DNSSEC [23]-[25] is used and the signatures are verified on the + client host, the misconfiguration of a DNS server may simply be + denial of service. Also, if local routing environment is not + reliable, clients may be directed to a false resolver with the same + IP address as the true one. + +6.1. RA Option + + The security of RA option for RDNSS is the same as the ND protocol + security [1][6]. The RA option does not add any new vulnerability. + + Note that the vulnerability of ND is not worse and is a subset of the + attacks that any node attached to a LAN can do independently of ND. + A malicious node on a LAN can promiscuously receive packets for any + router's MAC address and send packets with the router's MAC address + as the source MAC address in the L2 header. As a result, the L2 + switches send packets addressed to the router to the malicious node. + Also, this attack can send redirects that tell the hosts to send + their traffic somewhere else. The malicious node can send + unsolicited RA or NA replies, answer RS or NS requests, etc. All of + this can be done independently of implementing ND. Therefore, the RA + option for RDNSS does not add to the vulnerability. + + Security issues regarding the ND protocol were discussed by the IETF + SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for + the ND security has been published [12]. + + + + + +Jeong Informational [Page 20] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +6.2. DHCPv6 Option + + The DNS Recursive Name Server option may be used by an intruder DHCP + server to cause DHCP clients to send DNS queries to an intruder DNS + recursive name server [5]. The results of these misdirected DNS + queries may be used to spoof DNS names. + + To avoid attacks through the DNS Recursive Name Server option, the + DHCP client SHOULD require DHCP authentication (see "Authentication + of DHCP messages" in RFC 3315 [3][13]) before installing a list of + DNS recursive name servers obtained through authenticated DHCP. + +6.3. Well-known Anycast Addresses + + The well-known anycast addresses approach is not a protocol, thus + there is no need to secure the protocol itself. + + However, denial of service attacks on the DNS resolver system might + be easier to achieve as the anycast addresses used are by definition + well known. + +7. Contributors + + Ralph Droms + Cisco Systems, Inc. + 1414 Massachusetts Ave. + Boxboro, MA 01719 + US + + Phone: +1 978 936 1674 + EMail: rdroms@cisco.com + + + Robert M. Hinden + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + US + + Phone: +1 650 625 2004 + EMail: bob.hinden@nokia.com + + + + + + + + + + +Jeong Informational [Page 21] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + Ted Lemon + Nominum, Inc. + 950 Charter Street + Redwood City, CA 94043 + US + + EMail: Ted.Lemon@nominum.com + + Masataka Ohta + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku + Tokyo 152-8552 + Japan + + Phone: +81 3 5734 3299 + Fax: +81 3 5734 3299 + EMail: mohta@necom830.hpcl.titech.ac.jp + + + Soohong Daniel Park + Mobile Platform Laboratory, SAMSUNG Electronics + 416 Maetan-3dong, Yeongtong-Gu + Suwon, Gyeonggi-Do 443-742 + Korea + + Phone: +82 31 200 4508 + EMail: soohong.park@samsung.com + + + Suresh Satapati + Cisco Systems, Inc. + San Jose, CA 95134 + US + + EMail: satapati@cisco.com + + + Juha Wiljakka + Nokia + Visiokatu 3 + FIN-33720, TAMPERE + Finland + + Phone: +358 7180 48372 + EMail: juha.wiljakka@nokia.com + + + + + + +Jeong Informational [Page 22] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +8. Acknowledgements + + This document has greatly benefited from inputs by David Meyer, Rob + Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, + Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. + Also, Tony Bonanno proofread this document. The authors appreciate + their contribution. + +9. References + +9.1. Normative References + + [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery + for IP Version 6 (IPv6)", RFC 2461, December 1998. + + [2] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. + Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 3315, July 2003. + + [4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) + Service for IPv6", RFC 3736, April 2004. + + [5] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December + 2003. + +9.2. Informative References + + [6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 + Router Advertisement Option for DNS Configuration", Work in + Progress, September 2005. + + [7] Ohta, M., "Preconfigured DNS Server Addresses", Work in + Progress, February 2004. + + [8] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time + Option for Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 4242, November 2005. + + [9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + + + +Jeong Informational [Page 23] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + [11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, + "Scenarios and Analysis for Introducing IPv6 into ISP Networks", + RFC 4029, March 2005. + + [12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", + RFC 3118, June 2001. + + [14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June + 2005. + + [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host + Configuration Protocol (DHCP) version 6", RFC 3633, December + 2003. + + [16] Wasserman, M., "Recommendations for IPv6 in Third Generation + Partnership Project (3GPP) Standards", RFC 3314, September 2002. + + [17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC + 3574, August 2003. + + [18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation + Partnership Project (3GPP) Networks", RFC 4215, October 2005. + + [19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); + Service description; Stage 2 (Release 5)", December 2002. + + [20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 + specification; Core network protocols; Stage 3 (Release 5)", + June 2003. + + [21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering + Requirements for Stateless Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 4076, May 2005. + + [22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, + "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April + 2004. + + [23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + + +Jeong Informational [Page 24] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + + [25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work + in Progress, October 2005. + + [27] Guette, G. and O. Courtay, "Requirements for Automated Key + Rollover in DNSSEC", Work in Progress, January 2005. + + [28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M + and O Flags of IPv6 Router Advertisement", Work in Progress, + March 2005. + +Author's Address + + Jaehoon Paul Jeong (editor) + ETRI/Department of Computer Science and Engineering + University of Minnesota + 117 Pleasant Street SE + Minneapolis, MN 55455 + US + + Phone: +1 651 587 7774 + Fax: +1 612 625 2002 + EMail: jjeong@cs.umn.edu + URI: http://www.cs.umn.edu/~jjeong/ + + + + + + + + + + + + + + + + + + + + + + + + +Jeong Informational [Page 25] + +RFC 4339 IPv6 Host Configuration of DNS Server February 2006 + + +Full 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the 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). + + + + + + + +Jeong Informational [Page 26] + diff --git a/doc/rfc/rfc4471.txt b/doc/rfc/rfc4471.txt new file mode 100644 index 000000000000..eb338e6b5edf --- /dev/null +++ b/doc/rfc/rfc4471.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group G. Sisson +Request for Comments: 4471 B. Laurie +Category: Experimental Nominet + September 2006 + + + Derivation of DNS Name Predecessor and Successor + + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document describes two methods for deriving the canonically- + ordered predecessor and successor of a DNS name. These methods may + be used for dynamic NSEC resource record synthesis, enabling + security-aware name servers to provide authenticated denial of + existence without disclosing other owner names in a DNSSEC secured + zone. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Notational Conventions ..........................................3 + 3. Derivations .....................................................3 + 3.1. Absolute Method ............................................3 + 3.1.1. Derivation of DNS Name Predecessor ..................3 + 3.1.2. Derivation of DNS Name Successor ....................4 + 3.2. Modified Method ............................................4 + 3.2.1. Derivation of DNS Name Predecessor ..................5 + 3.2.2. Derivation of DNS Name Successor ....................6 + 4. Notes ...........................................................6 + 4.1. Test for Existence .........................................6 + 4.2. Case Considerations ........................................7 + 4.3. Choice of Range ............................................7 + 4.4. Wild Card Considerations ...................................8 + 4.5. Possible Modifications .....................................8 + 4.5.1. Restriction of Effective Maximum DNS Name Length ....8 + 4.5.2. Use of Modified Method with Zones Containing + + + +Sisson & Laurie Experimental [Page 1] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + SRV RRs .............................................8 + 5. Examples ........................................................9 + 5.1. Examples of Immediate Predecessors Using Absolute Method ..10 + 5.2. Examples of Immediate Successors Using Absolute Method ....14 + 5.3. Examples of Predecessors Using Modified Method ............19 + 5.4. Examples of Successors Using Modified Method ..............20 + 6. Security Considerations ........................................21 + 7. Acknowledgements ...............................................21 + 8. References .....................................................21 + 8.1. Normative References ......................................21 + 8.2. Informative References ....................................22 + +1. Introduction + + One of the proposals for avoiding the exposure of zone information + during the deployment DNSSEC is dynamic NSEC resource record (RR) + synthesis. This technique is described in [DNSSEC-TRANS] and + [RFC4470], and involves the generation of NSEC RRs that just span the + query name for non-existent owner names. In order to do this, the + DNS names that would occur just prior to and just following a given + query name must be calculated in real time, as maintaining a list of + all possible owner names that might occur in a zone would be + impracticable. + + Section 6.1 of [RFC4034] defines canonical DNS name order. This + document does not amend or modify this definition. However, the + derivation of immediate predecessor and successor, although trivial, + is non-obvious. Accordingly, several methods are described here as + an aid to implementors and a reference to other interested parties. + + This document describes two methods: + + 1. An "absolute method", which returns the immediate predecessor or + successor of a domain name such that no valid DNS name could + exist between that DNS name and the predecessor or successor. + + 2. A "modified method", which returns a predecessor and successor + that are more economical in size and computation. This method is + restricted to use with zones consisting exclusively of owner + names that contain no more than one label more than the owner + name of the apex, where the longest possible owner name (i.e., + one with a maximum length left-most label) would not exceed the + maximum DNS name length. This is, however, the type of zone for + which the technique of online signing is most likely to be used. + + + + + + + +Sisson & Laurie Experimental [Page 2] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +2. Notational Conventions + + The following notational conventions are used in this document for + economy of expression: + + N: An unspecified DNS name. + + P(N): Immediate predecessor to N (absolute method). + + S(N): Immediate successor to N (absolute method). + + P'(N): Predecessor to N (modified method). + + S'(N): Successor to N (modified method). + +3. Derivations + + These derivations assume that all uppercase US-ASCII letters in N + have already been replaced by their corresponding lowercase + equivalents. Unless otherwise specified, processing stops after the + first step in which a condition is met. + + The derivations make reference to maximum label length and maximum + DNS name length; these are defined in Section 3.1 of [RFC1034] to be + 63 and 255 octets, respectively. + +3.1. Absolute Method + +3.1.1. Derivation of DNS Name Predecessor + + To derive P(N): + + 1. If N is the same as the owner name of the zone apex, prepend N + repeatedly with labels of the maximum length possible consisting + of octets of the maximum sort value (e.g., 0xff) until N is the + maximum length possible; otherwise proceed to the next step. + + 2. If the least significant (left-most) label of N consists of a + single octet of the minimum sort value (e.g., 0x00), remove that + label; otherwise proceed to the next step. + + 3. If the least significant (right-most) octet in the least + significant (left-most) label of N is the minimum sort value, + remove the least significant octet and proceed to step 5. + + 4. Decrement the value of the least significant (right-most) octet + of the least significant (left-most) label, skipping any values + that correspond to uppercase US-ASCII letters, and then append + + + +Sisson & Laurie Experimental [Page 3] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + the least significant (left-most) label with as many octets as + possible of the maximum sort value. Proceed to the next step. + + 5. Prepend N repeatedly with labels of as long a length as possible + consisting of octets of the maximum sort value until N is the + maximum length possible. + +3.1.2. Derivation of DNS Name Successor + + To derive S(N): + + 1. If N is two or more octets shorter than the maximum DNS name + length, prepend N with a label containing a single octet of the + minimum sort value (e.g., 0x00); otherwise proceed to the next + step. + + 2. If N is one octet shorter than the maximum DNS name length and + the least significant (left-most) label is one or more octets + shorter than the maximum label length, append an octet of the + minimum sort value to the least significant label; otherwise + proceed to the next step. + + 3. Increment the value of the least significant (right-most) octet + in the least significant (left-most) label that is less than the + maximum sort value (e.g., 0xff), skipping any values that + correspond to uppercase US-ASCII letters, and then remove any + octets to the right of that one. If all octets in the label are + the maximum sort value, then proceed to the next step. + + 4. Remove the least significant (left-most) label. Unless N is now + the same as the owner name of the zone apex (this will occur only + if N was the maximum possible name in canonical DNS name order, + and thus has wrapped to the owner name of zone apex), repeat + starting at step 2. + +3.2. Modified Method + + This method is for use with zones consisting only of single-label + owner names where an owner name consisting of label of maximum length + would not result in a DNS name that exceeded the maximum DNS name + length. This method is computationally simpler and returns values + that are more economical in size than the absolute method. It + differs from the absolute method detailed above in the following + ways: + + 1. Step 1 of the derivation P(N) has been omitted as the existence + of the owner name of the zone apex never requires denial. + + + + +Sisson & Laurie Experimental [Page 4] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + 2. A new step 1 has been introduced that removes unnecessary labels. + + 3. Step 4 of the derivation P(N) has been omitted as it is only + necessary for zones containing owner names consisting of more + than one label. This omission generally results in a significant + reduction of the length of derived predecessors. + + 4. Step 1 of the derivation S(N) had been omitted as it is only + necessary for zones containing owner names consisting of more + than one label. This omission results in a tiny reduction of the + length of derived successors, and maintains consistency with the + modification of step 4 of the derivation P(N) described above. + + 5. Steps 2 and 4 of the derivation S(N) have been modified to + eliminate checks for maximum DNS name length, as it is an + assumption of this method that no DNS name in the zone can exceed + the maximum DNS name length. + +3.2.1. Derivation of DNS Name Predecessor + + To derive P'(N): + + 1. If N is two or more labels longer than the owner name of the + apex, repeatedly remove the least significant (left-most) label + until N is only one label longer than the owner name of the apex; + otherwise proceed to the next step. + + 2. If the least significant (left-most) label of N consists of a + single octet of the minimum sort value (e.g., 0x00), remove that + label; otherwise proceed to the next step. (If this condition is + met, P'(N) is the owner name of the apex.) + + 3. If the least significant (right-most) octet in the least + significant (left-most) label of N is the minimum sort value, + remove the least significant octet. + + 4. Decrement the value of the least significant (right-most) octet, + skipping any values that correspond to uppercase US-ASCII + letters, and then append the label with as many octets as + possible of the maximum sort value. + + + + + + + + + + + +Sisson & Laurie Experimental [Page 5] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +3.2.2. Derivation of DNS Name Successor + + To derive S'(N): + + 1. If N is two or more labels longer than the owner name of the + apex, repeatedly remove the least significant (left-most) label + until N is only one label longer than the owner name of the apex. + Proceed to the next step. + + 2. If the least significant (left-most) label of N is one or more + octets shorter than the maximum label length, append an octet of + the minimum sort value to the least significant label; otherwise + proceed to the next step. + + 3. Increment the value of the least significant (right-most) octet + in the least significant (left-most) label that is less than the + maximum sort value (e.g., 0xff), skipping any values that + correspond to uppercase US-ASCII letters, and then remove any + octets to the right of that one. If all octets in the label are + the maximum sort value, then proceed to the next step. + + 4. Remove the least significant (left-most) label. (This will occur + only if the least significant label is the maximum label length + and consists entirely of octets of the maximum sort value, and + thus has wrapped to the owner name of the zone apex.) + +4. Notes + +4.1. Test for Existence + + Before using the result of P(N) or P'(N) as the owner name of an NSEC + RR in a DNS response, a name server should test to see whether the + name exists. If it does, either a standard non-synthesised NSEC RR + should be used, or the synthesised NSEC RR should reflect the RRset + types that exist at the NSEC RR's owner name in the Type Bit Map + field as specified by Section 4.1.2 of [RFC4034]. Implementors will + likely find it simpler to use a non-synthesised NSEC RR. For further + details, see Section 2 of [RFC4470]. + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 6] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +4.2. Case Considerations + + Section 3.5 of [RFC1034] specifies that "while upper and lower case + letters are allowed in names, no significance is attached to the + case". Additionally, Section 6.1 of [RFC4034] states that when + determining canonical DNS name order, "uppercase US-ASCII letters are + treated as if they were lowercase US-ASCII letters". Consequently, + values corresponding to US-ASCII uppercase letters must be skipped + when decrementing and incrementing octets in the derivations + described in Section 3. + + The following pseudo-code is illustrative: + + Decrement the value of an octet: + + if (octet == '[') // '[' is just after uppercase 'Z' + octet = '@'; // '@' is just prior to uppercase 'A' + else + octet--; + + Increment the value of an octet: + + if (octet == '@') // '@' is just prior to uppercase 'A' + octet = '['; // '[' is just after uppercase 'Z' + else + octet++; + +4.3. Choice of Range + + [RFC2181] makes the clarification that "any binary string whatever + can be used as the label of any resource record". Consequently, the + minimum sort value may be set as 0x00 and the maximum sort value as + 0xff, and the range of possible values will be any DNS name that + contains octets of any value other than those corresponding to + uppercase US-ASCII letters. + + However, if all owner names in a zone are in the letter-digit-hyphen, + or LDH, format specified in [RFC1034], it may be desirable to + restrict the range of possible values to DNS names containing only + LDH values. This has the effect of + + 1. making the output of tools such as `dig' and `nslookup' less + subject to confusion, + + 2. minimising the impact that NSEC RRs containing DNS names with + non-LDH values (or non-printable values) might have on faulty DNS + resolver implementations, and + + + + +Sisson & Laurie Experimental [Page 7] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + 3. preventing the possibility of results that are wildcard DNS names + (see Section 4.4). + + This may be accomplished by using a minimum sort value of 0x1f (US- + ASCII character `-') and a maximum sort value of 0x7a (US-ASCII + character lowercase `z'), and then skipping non-LDH, non-lowercase + values when incrementing or decrementing octets. + +4.4. Wild Card Considerations + + Neither derivation avoids the possibility that the result may be a + DNS name containing a wildcard label, i.e., a label containing a + single octet with the value 0x2a (US-ASCII character `*'). With + additional tests, wildcard DNS names may be explicitly avoided; + alternatively, if the range of octet values can be restricted to + those corresponding to letter-digit-hyphen, or LDH, characters (see + Section 4.3), such DNS names will not occur. + + Note that it is improbable that a result that is a wildcard DNS name + will occur unintentionally; even if one does occur either as the + owner name of, or in the RDATA of an NSEC RR, it is treated as a + literal DNS name with no special meaning. + +4.5. Possible Modifications + +4.5.1. Restriction of Effective Maximum DNS Name Length + + [RFC1034] specifies that "the total number of octets that represent a + name (i.e., the sum of all label octets and label lengths) is limited + to 255", including the null (zero-length) label that represents the + root. For the purpose of deriving predecessors and successors during + NSEC RR synthesis, the maximum DNS name length may be effectively + restricted to the length of the longest DNS name in the zone. This + will minimise the size of responses containing synthesised NSEC RRs + but, especially in the case of the modified method, may result in + some additional computational complexity. + + Note that this modification will have the effect of revealing + information about the longest name in the zone. Moreover, when the + contents of the zone changes, e.g., during dynamic updates and zone + transfers, care must be taken to ensure that the effective maximum + DNS name length agrees with the new contents. + +4.5.2. Use of Modified Method with Zones Containing SRV RRs + + Normally, the modified method cannot be used in zones that contain + Service Record (SRV) RRs [RFC2782], as SRV RRs have owner names that + contain multiple labels. However, the use of SRV RRs can be + + + +Sisson & Laurie Experimental [Page 8] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + accommodated by various techniques. There are at least four possible + ways to do this: + + 1. Use conventional NSEC RRs for the region of the zone that + contains first-level labels beginning with the underscore (`_') + character. For the purposes of generating these NSEC RRs, the + existence of (possibly fictional) ownernames `9{63}' and `a' + could be assumed, providing a lower and upper bound for this + region. Then all queries where the QNAME does not exist but + contains a first-level label beginning with an underscore could + be handled using the normal DNSSEC protocol. + + This approach would make it possible to enumerate all DNS names + in the zone containing a first-level label beginning with + underscore, including all SRV RRs, but this may be of less a + concern to the zone administrator than incurring the overhead of + the absolute method or of the following variants of the modified + method. + + 2. The absolute method could be used for synthesising NSEC RRs for + all queries where the QNAME contains a leading underscore. + However, this re-introduces the susceptibility of the absolute + method to denial of service activity, as an attacker could send + queries for an effectively inexhaustible supply of domain names + beginning with a leading underscore. + + 3. A variant of the modified method could be used for synthesising + NSEC RRs for all queries where the QNAME contains a leading + underscore. This variant would assume that all predecessors and + successors to queries where the QNAME contains a leading + underscore may consist of two labels rather than only one. This + introduces a little additional complexity without incurring the + full increase in response size and computational complexity as + the absolute method. + + 4. Finally, a variant of the modified method that assumes that all + owner names in the zone consist of one or two labels could be + used. However, this negates much of the reduction in response + size of the modified method and may be nearly as computationally + complex as the absolute method. + +5. Examples + + In the following examples, + + the owner name of the zone apex is "example.com.", + + + + + +Sisson & Laurie Experimental [Page 9] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + the range of octet values is 0x00 - 0xff excluding values + corresponding to uppercase US-ASCII letters, and + + non-printable octet values are expressed as three-digit decimal + numbers preceded by a backslash (as specified in Section 5.1 of + [RFC1035]). + +5.1. Examples of Immediate Predecessors Using Absolute Method + + Example of a typical case: + + P(foo.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.fon\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.fon\255{60}.example.com. + + where {n} represents the number of repetitions of an octet. + + Example where least significant (left-most) label of DNS name + consists of a single octet of the minimum sort value: + + P(\000.foo.example.com.) = foo.example.com. + + + + + + + +Sisson & Laurie Experimental [Page 10] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where least significant (right-most) octet of least + significant (left-most) label has the minimum sort value: + + P(foo\000.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.foo.example.com. + + or, in alternate notation: + + \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com. + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 11] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where DNS name contains an octet that must be decremented by + skipping values corresponding to US-ASCII uppercase letters: + + P(fo\[.example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.fo\@\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com. + + where {n} represents the number of repetitions of an octet. + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 12] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where DNS name is the owner name of the zone apex, and + consequently wraps to the DNS name with the maximum possible sort + order in the zone: + + P(example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.\255{63}.example.com. + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 13] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +5.2. Examples of Immediate Successors Using Absolute Method + + Example of typical case: + + S(foo.example.com.) = \000.foo.example.com. + + Example where DNS name is one octet short of the maximum DNS name + length: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + .ooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooo.ooooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooo.ooooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{47}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + \000.ooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooooo.ooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooooo.ooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooo.example.com. + + or, in alternate notation: + + fo{47}\000.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 14] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where DNS name is the maximum DNS name length: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + o.oooooooooooooooooooooooooooooooooooooooooooooo + ooooooooooooooooo.oooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooooo.oooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + o.example.com. + + or, in alternate notation: + + fo{48}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + p.oooooooooooooooooooooooooooooooooooooooooooooo + ooooooooooooooooo.oooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooooo.oooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + o.example.com. + + or, in alternate notation: + + fo{47}p.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 15] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where DNS name is the maximum DNS name length and the least + significant (left-most) label has the maximum sort value: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.ooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooooo.ooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooooo.ooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooo.example.com. + + or, in alternate notation: + + \255{49}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + oooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooop.oooooooooooooooooooooooooooooooo + ooooooooooooooooooooooooooooooo.oooooooooooooooo + ooooooooooooooooooooooooooooooooooooooooooooooo. + example.com. + + or, in alternate notation: + + o{62}p.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 16] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where DNS name is the maximum DNS name length and the eight + least significant (right-most) octets of the least significant + (left-most) label have the maximum sort value: + + N = foooooooooooooooooooooooooooooooooooooooo\255 + \255\255\255\255\255\255\255.ooooooooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooo.ooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooo.ooooooooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{40}\255{8}.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooop.oooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + ooooooooo.oooooooooooooooooooooooooooooooooooooo + ooooooooooooooooooooooooo.oooooooooooooooooooooo + ooooooooooooooooooooooooooooooooooooooooo.example.com. + + or, in alternate notation: + + fo{39}p.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 17] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where DNS name is the maximum DNS name length and contains an + octet that must be incremented by skipping values corresponding to + US-ASCII uppercase letters: + + N = fooooooooooooooooooooooooooooooooooooooooooooooo + \@.ooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooo.ooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooo.ooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oo.example.com. + + or, in alternate notation: + + fo{47}\@.o{63}.o{63}.o{63}.example.com. + + S(N) = + + fooooooooooooooooooooooooooooooooooooooooooooooo + \[.ooooooooooooooooooooooooooooooooooooooooooooo + oooooooooooooooooo.ooooooooooooooooooooooooooooo + oooooooooooooooooooooooooooooooooo.ooooooooooooo + oooooooooooooooooooooooooooooooooooooooooooooooo + oo.example.com. + + or, in alternate notation: + + fo{47}\[.o{63}.o{63}.o{63}.example.com. + + + + + + + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 18] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where DNS name has the maximum possible sort order in the + zone, and consequently wraps to the owner name of the zone apex: + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255.\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255.\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + \255{49}.\255{63}.\255{63}.\255{63}.example.com. + + S(N) = example.com. + +5.3. Examples of Predecessors Using Modified Method + + Example of a typical case: + + P'(foo.example.com.) = + + fon\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255.example.com. + + or, in alternate notation: + + fon\255{60}.example.com. + + + + +Sisson & Laurie Experimental [Page 19] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + Example where DNS name contains more labels than DNS names in the + zone: + + P'(bar.foo.example.com.) = foo.example.com. + + Example where least significant (right-most) octet of least + significant (left-most) label has the minimum sort value: + + P'(foo\000.example.com.) = foo.example.com. + + Example where least significant (left-most) label has the minimum + sort value: + + P'(\000.example.com.) = example.com. + + Example where DNS name is the owner name of the zone apex, and + consequently wraps to the DNS name with the maximum possible sort + order in the zone: + + P'(example.com.) = + + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255.example.com. + + or, in alternate notation: + + \255{63}.example.com. + +5.4. Examples of Successors Using Modified Method + + Example of a typical case: + + S'(foo.example.com.) = foo\000.example.com. + + Example where DNS name contains more labels than DNS names in the + zone: + + S'(bar.foo.example.com.) = foo\000.example.com. + + + Example where least significant (left-most) label has the maximum + sort value, and consequently wraps to the owner name of the zone + apex: + + + + +Sisson & Laurie Experimental [Page 20] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + + N = \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255\255\255\255\255\255\255\255\255\255 + \255\255\255.example.com. + + or, in alternate notation: + + \255{63}.example.com. + + S'(N) = example.com. + +6. Security Considerations + + The derivation of some predecessors/successors requires the testing + of more conditions than others. Consequently, the effectiveness of a + denial-of-service attack may be enhanced by sending queries that + require more conditions to be tested. The modified method involves + the testing of fewer conditions than the absolute method and + consequently is somewhat less susceptible to this exposure. + +7. Acknowledgements + + The authors would like to thank Sam Weiler, Olaf Kolkman, Olafur + Gudmundsson, and Niall O'Reilly for their review and input. + +8. References + +8.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR + for specifying the location of services (DNS SRV)", + RFC 2782, February 2000. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + + + +Sisson & Laurie Experimental [Page 21] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +8.2. Informative References + + [RFC4470] Weiler, S. and J. Ihren, "Minimally Covering NSEC + Records and DNSSEC On-line Signing", RFC 4470, April + 2006. + + [DNSSEC-TRANS] Arends, R., Koch, P., and J. Schlyter, "Evaluating + DNSSEC Transition Mechanisms", Work in Progress, + February 2005. + +Authors' Addresses + + Geoffrey Sisson + Nominet + Sandford Gate + Sandy Lane West + Oxford + OX4 6LB + GB + + Phone: +44 1865 332211 + EMail: geoff@nominet.org.uk + + + Ben Laurie + Nominet + 17 Perryn Road + London + W3 7LR + GB + + Phone: +44 20 8735 0686 + EMail: ben@algroup.co.uk + + + + + + + + + + + + + + + + + + +Sisson & Laurie Experimental [Page 22] + +RFC 4471 DNS Name Predecessor and Successor September 2006 + + +Full 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the 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). + + + + + + + +Sisson & Laurie Experimental [Page 23] + diff --git a/doc/rfc/rfc4472.txt b/doc/rfc/rfc4472.txt new file mode 100644 index 000000000000..b396e9a11a55 --- /dev/null +++ b/doc/rfc/rfc4472.txt @@ -0,0 +1,1627 @@ + + + + + + +Network Working Group A. Durand +Request for Comments: 4472 Comcast +Category: Informational J. Ihren + Autonomica + P. Savola + CSC/FUNET + April 2006 + + + Operational Considerations and Issues with IPv6 DNS + +Status of This Memo + + This memo provides information for 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 + + This memo presents operational considerations and issues with IPv6 + Domain Name System (DNS), including a summary of special IPv6 + addresses, documentation of known DNS implementation misbehavior, + recommendations and considerations on how to perform 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. This memo is aimed to include a + summary of information about IPv6 DNS considerations for those who + have experience with IPv4 DNS. + +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 + + + +Durand, et al. Informational [Page 1] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + 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 ......................27 + + + + + + + + + + + + + + + + +Durand, et al. Informational [Page 2] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +1. Introduction + + This memo presents operational considerations and issues with IPv6 + DNS; it is meant to be an extensive summary and a list of pointers + for more information about IPv6 DNS considerations for those with + experience with IPv4 DNS. + + The purpose of this document is to give information about various + issues and considerations related to DNS operations with IPv6; it is + not meant to be a normative specification or standard for IPv6 DNS. + + The first section gives a brief overview of how IPv6 addresses and + names are represented in the 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 these are described + at more length in other documents. + + The second section summarizes the special IPv6 address types and how + they relate to DNS. The third section describes observed DNS + implementation misbehaviors that have a varying effect on the use of + IPv6 records with DNS. The fourth section lists recommendations and + considerations for provisioning services with DNS. The fifth section + in turn looks at recommendations and considerations about providing + IPv6 support in the resolvers. The sixth and seventh sections + describe considerations with forward and reverse DNS updates, + respectively. The eighth section introduces several miscellaneous + IPv6 issues relating to DNS for which no better place has been found + in this memo. Appendix A looks briefly at the requirements for + unique local addressing. Appendix B discusses additional data. + +1.1. Representing IPv6 Addresses in DNS Records + + In the forward zones, IPv6 addresses are represented using AAAA + records. In the reverse zones, IPv6 address are represented using + 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 information. + + In particular, one should note that the use of 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 in conjunction with A6 records; the document did not mean to + take a stance on any other use of DNAME records [RFC3364]. + + + + + + + + +Durand, et al. Informational [Page 3] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +1.2. Independence of DNS Transport and DNS Records + + DNS has been 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 the 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 is some debate whether the addresses in Additional + section could be selected or filtered using hints obtained from which + transport was being used; this has some obvious problems because in + many cases the transport protocol does not correlate with the + requests, and because a "bad" answer is in a way worse than no answer + at all (consider the case where the client is led to believe that a + name received in the additional record does not have any AAAA records + at all). + + 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 avoid the DNS name space from fragmenting into parts where some + parts of DNS are only visible using IPv4 (or IPv6) transport, the + recommendation is to always keep at least one authoritative server + IPv4-enabled, and to ensure that recursive DNS servers support IPv4. + See DNS IPv6 transport guidelines [RFC3901] for more information. + +1.4. Query Type '*' and A/AAAA Records + + QTYPE=* is typically only used for debugging or management purposes; + it is worth keeping in mind that QTYPE=* ("ANY" queries) only return + any available RRsets, not *all* the RRsets, because the caches do not + necessarily have all the RRsets and have no way of guaranteeing that + they have all the RRsets. Therefore, to get both A and AAAA records + reliably, two separate queries must be made. + + + + + + + + +Durand, et al. Informational [Page 4] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +2. DNS Considerations about Special IPv6 Addresses + + There are a couple of IPv6 address types that are somewhat special; + these are considered 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). The 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 (whether in + forward or reverse tree), because they have only local (to the + connected link) significance [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 the + current value of a node's 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 (e.g., 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 the reverse DNS population would be desirable (see Section 7.1 for + applicability), there are a number of possible ways to do so. + + [WIP-H2005] aims to design an autonomous reverse-delegation system + that anyone being 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, e.g., Regional + Internet Registries (RIRs). This is a practical solution, but may + have some scalability concerns. + +2.4. Other Transition Mechanisms + + 6to4 is mentioned as a case of an IPv6 transition mechanism requiring + special considerations. In general, mechanisms that include a + special prefix may need a custom solution; otherwise, for example, + when IPv4 address is embedded as the suffix or not embedded at all, + special solutions are likely not needed. + + + +Durand, et al. Informational [Page 5] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + Note that it does not 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 + + Several classes of misbehavior in DNS servers, load-balancers, and + resolvers have been observed. Most of these are rather generic, not + only applicable to IPv6 -- but in some cases, the consequences of + this misbehavior are extremely severe in IPv6 environments and + deserve to be mentioned. + +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 provide wrong answers to such queries (instead of a proper + negative reply). While typically these issues are not limited to + AAAA records, the problems are aggravated by the fact that AAAA + records are being queried instead of (mainly) A records. + + The problems are serious because when looking up a DNS name, typical + getaddrinfo() implementations, with AF_UNSPEC hint given, first try + to query the AAAA records of the name, and after receiving a + response, query the A records. This is done in a serial fashion -- + if the first query is never responded to (instead of properly + returning a negative answer), significant time-outs will occur. + + In consequence, this is an enormous problem for IPv6 deployments, and + in some cases, IPv6 support in the software has even been disabled + due to 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 do not seem to directly + impair IPv6 use, and are only referred to for completeness. + + + + +Durand, et al. Informational [Page 6] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +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 to be able to 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 doing this, for example: + + o It allows more flexibility and ease for migration of (only a part + of) services from one node to another, + + o It allows configuring different properties (e.g., Time to Live + (TTL)) for each service, and + + o 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 are not sufficiently widely used to be + applicable in most cases. Hence an operation technique is to use + service names instead of node names (or "hostnames"). This + operational technique is not specific to IPv6, but required to + understand the considerations described in Section 4.2 and + Section 4.3. + + For example, assume 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 using + which addresses. (Obviously, when wanting to reach a specific node, + one should use the hostname rather than a service name.) + + + + + + + + + +Durand, et al. Informational [Page 7] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +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 allows for easier service piloting, minimizing the disturbance + to the "regular" users of IPv4 service; however, the service would + not be used transparently, without the user/application explicitly + finding it and asking 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; however, this is a + suboptimal solution. Using the same service name is the "long-term" + solution, but may degrade performance for those clients whose IPv6 + performance is lower than IPv4, or does not work as well (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 the use of the same name when + confident enough that the service level will not degrade for the + users 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 following are true: + + 1. The address is assigned to the interface on the node. + + 2. The address is configured on the interface. + + 3. 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 + 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 IPv6 Internet) constraint #3 would mean + that it should not have an address in the DNS. + + + + + +Durand, et al. Informational [Page 8] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + Consider the case of two dual-stack nodes, which both are IPv6- + enabled, but the server does not have (global) IPv6 connectivity. As + the client looks up the server's name, only A records are returned + (if the recommendations above are followed), and no IPv6 + communication, which would have been unsuccessful, is even attempted. + + The issues are not always so black-and-white. Usually, it's + important that the service offered using 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::1 + + In the former case, we have "courtesy" additional data; in the + latter, we have "critical" additional data. See 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 to be useful for the + caching resolvers to discard the A record when the shorter TTL (in + this case, for the AAAA record) expires; this would avoid the + situation where there would be a window of 200 seconds when + incomplete information is returned from the cache. Further argument + + + +Durand, et al. Informational [Page 9] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + for discarding is that in the normal operation, the TTL values are so + high that very likely the incurred additional queries would not be + noticeable, compared to the obtained performance optimization. The + behavior in this scenario is unspecified. + +4.4.2. TTL with Critical Additional Data + + The difference to courtesy additional data is that the A/AAAA records + served by the parent zone cannot be queried explicitly. Therefore, + after 100 seconds the AAAA record is removed from the cache(s), but + the A record remains. Queries for the remaining 200 seconds + (provided that there are no further queries from the parent that + could refresh the caches) only return the A record, leading to a + potential operational situation with unreachable servers. + + Similar cache flushing strategies apply in this scenario; 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 ensure that the process is as smooth as possible. + +5.1. DNS Lookups May Query IPv6 Records Prematurely + + The system library that implements the getaddrinfo() function for + looking up names is a critical piece when considering the robustness + of enabling IPv6; it may come in basically three flavors: + + 1. The system library does not know whether IPv6 has been enabled in + the kernel of the operating system: it may start looking up AAAA + records with getaddrinfo() and AF_UNSPEC hint when the system is + upgraded to a system library version that supports IPv6. + + 2. The system library might start to perform IPv6 queries with + getaddrinfo() only when IPv6 has been enabled in the kernel. + However, this does not guarantee that there exists any useful + IPv6 connectivity (e.g., the node could be isolated from the + other IPv6 networks, only having link-local addresses). + + + + +Durand, et al. Informational [Page 10] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + 3. The system library might implement a toggle that would apply some + heuristics to the "IPv6-readiness" of the node before starting to + perform queries; for example, it could check whether only link- + local IPv6 address(es) exists, or if at least one global IPv6 + address exists. + + First, let us consider generic implications of unnecessary queries + for AAAA records: when looking up all the records in the DNS, AAAA + records are typically tried first, and then A records. These are + done in serial, and the A query is not performed until a response is + received to the AAAA query. Considering the misbehavior of DNS + servers and load-balancers, as described in Section 3.1, the lookup + delay for AAAA may incur additional unnecessary latency, and + introduce a component of unreliability. + + One option here could be to do the queries partially in parallel; for + example, if the final response to the AAAA query is not received in + 0.5 seconds, start performing the A query while waiting for the + result. (Immediate parallelism might not be optimal, at least + without information-sharing between the lookup threads, as that would + probably lead to duplicate non-cached delegation chain lookups.) + + An additional concern is the address selection, which may, in some + circumstances, prefer AAAA records over A records even when the node + does not have any IPv6 connectivity [WIP-RDP2004]. In some cases, + the implementation may attempt to connect or send a datagram on a + physical link [WIP-R2006], incurring very long protocol time-outs, + instead of quickly falling back to IPv4. + + Now, we can consider the issues specific to each of the three + possibilities: + + In the first case, the node performs a number of completely useless + DNS lookups as it will not be able to use the returned AAAA records + anyway. (The only exception is where the application desires to know + what's in the DNS, but not use the result for communication.) One + should be able to disable these unnecessary queries, for both latency + and reliability reasons. However, as IPv6 has not been enabled, the + connections to IPv6 addresses fail immediately, and if the + application is programmed properly, the application can fall + gracefully back to IPv4 [RFC4038]. + + The second case is similar to the first, except it happens to a + smaller set of nodes when IPv6 has been enabled but connectivity has + not been provided yet. Similar considerations apply, with the + exception that IPv6 records, when returned, will be actually tried + first, which may typically lead to long time-outs. + + + + +Durand, et al. Informational [Page 11] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + The third case is a bit more complex: optimizing away the DNS lookups + with only link-locals is probably safe (but may be desirable with + different lookup services that getaddrinfo() may support), as the + link-locals are typically automatically generated when IPv6 is + enabled, and do not indicate any form of IPv6 connectivity. That is, + performing DNS lookups only when a non-link-local address has been + configured on any interface could be beneficial -- this would be an + indication that the address has been configured either from a router + advertisement, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + [RFC3315], or manually. Each would indicate at least some form of + IPv6 connectivity, even though there would not be guarantees of it. + + These issues should be analyzed at more depth, and the fixes found + consensus on, perhaps in a separate document. + +5.2. Obtaining a List of DNS Recursive Resolvers + + In scenarios where 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 the development of alternative mechanisms for + obtaining the list of DNS recursive name servers when DHCPv6 is + unavailable or inappropriate. No decision about taking on this + development work has been reached as of this writing [RFC4339]. + + In scenarios where DHCPv6 is unavailable or inappropriate, 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 as IPv6 DNS records can be queried over IPv4 as well as + IPv6. Obviously, nodes that are meant to function 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], the recursive resolvers + should be IPv4-only or dual-stack to be able to reach any IPv4-only + DNS server. Note that this requirement is also fulfilled by an IPv6- + only stub resolver pointing to a dual-stack recursive DNS resolver. + + + + + + +Durand, et al. Informational [Page 12] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +6. Considerations about Forward DNS Updating + + While the topic of how to enable updating the forward DNS, i.e., the + mapping from names to the correct new addresses, is not specific to + IPv6, it should be considered especially due to the advent of + Stateless Address Autoconfiguration [RFC2462]. + + Typically, forward DNS updates are more manageable than doing them in + the reverse DNS, because the updater can often be assumed to "own" a + certain DNS name -- and we can create a form of security relationship + with the DNS name and the node that is allowed to update it to point + to a new address. + + A more complex form of DNS updates -- adding a whole new name into a + DNS zone, instead of updating an existing name -- is considered out + of scope for this memo as it could require zone-wide authentication. + Adding a new name in the forward zone is a problem that is still + being explored with IPv4, and IPv6 does not seem to add much new in + that area. + +6.1. Manual or Custom DNS Updates + + The DNS mappings can also be maintained by hand, in a semi-automatic + fashion or by running non-standardized protocols. These are not + considered at more length in this memo. + +6.2. Dynamic DNS + + Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized + mechanism for dynamically updating the DNS. It works equally well + with Stateless Address Autoconfiguration (SLAAC), DHCPv6, or manual + address configuration. It is important to consider how each of these + behave if IP address-based authentication, instead of stronger + mechanisms [RFC3007], was used in the updates. + + 1. Manual addresses are static and can be configured. + + 2. 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. + + 3. SLAAC addresses are typically stable for a long time, but could + require work to be configured and maintained. + + As relying on IP addresses for Dynamic DNS is rather insecure at + best, stronger authentication should always be used; however, this + requires that the authorization keying will be explicitly configured + using unspecified operational methods. + + + +Durand, et al. Informational [Page 13] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + Note that with DHCP it is also possible that the DHCP server updates + the DNS, not the host. The host might only indicate in the DHCP + exchange which hostname it would prefer, and the DHCP server would + make the appropriate updates. Nonetheless, while this makes setting + up a secure channel between the updater and the DNS server easier, it + does not help much with "content" security, i.e., whether the + hostname was acceptable -- if the DNS server does not include + policies, they must be included in the DHCP server (e.g., a regular + host should not be able to state that 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 will attempt to update their addresses, sufficient + security material for authenticating themselves to the server, and + the hostname they will be updating. Unless otherwise configured, the + first could be obtained by looking up the authoritative name servers + for the hostname; the second must be configured explicitly unless one + chooses to trust the IP address-based authentication (not a good + idea); and lastly, the nodename is typically pre-configured somehow + on the node, e.g., at install time. + + Care should be observed when updating the addresses not to use longer + TTLs for addresses than are preferred lifetimes for the addresses, so + that if the node is renumbered in a managed fashion, the amount of + stale DNS information is kept to the minimum. That is, 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 + better flexibility, the DNS TTL should be much shorter (e.g., a half + or a third) than the lifetime of an address; that way, the node can + start lowering the DNS TTL if it seems like the address has not been + renewed/refreshed in a while. Some discussion on how an + administrator could manage the DNS TTL is included in [RFC4192]; this + could be applied to (smart) hosts as well. + +7. Considerations about Reverse DNS Updating + + Updating the reverse DNS zone may be difficult because of the split + authority over an address. However, first we have to consider the + applicability of reverse DNS in the first place. + +7.1. Applicability of Reverse DNS + + Today, some applications use reverse DNS either to look up some hints + about the topological information associated with an address (e.g., + resolving web server access logs) or (as a weak form of a security + check) to get a feel whether the user's network administrator has + + + + +Durand, et al. Informational [Page 14] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + "authorized" the use of the address (on the premise that adding a + reverse record for an address would signal some form of + authorization). + + One additional, maybe slightly more useful usage is ensuring that the + reverse and forward DNS contents match (by looking up the pointer to + the name by the IP address from the reverse tree, and ensuring that a + record under the name in the forward tree points to the IP address) + and correspond to a configured name or domain. As a security check, + it is typically accompanied by other mechanisms, such as a user/ + password login; the main purpose of the reverse+forward DNS check is + to weed out the majority of unauthorized users, and if someone + managed to bypass the checks, he would still need to authenticate + "properly". + + It may also be desirable to store IPsec keying material corresponding + to an IP address in the reverse DNS, as justified and described in + [RFC4025]. + + It is not clear whether it makes sense to require or recommend that + reverse DNS records be updated. In many cases, it would just make + more sense to use proper mechanisms for security (or topological + information lookup) in the first place. At minimum, the applications + that use it as a generic authorization (in the sense that a record + exists at all) should be modified as soon as possible to avoid such + lookups completely. + + The applicability is discussed at more length in [WIP-S2005c]. + +7.2. Manual or Custom DNS Updates + + Reverse DNS can of course be updated using manual or custom methods. + These are not further described here, except for one special case. + + One way to deploy reverse DNS would be to use wildcard records, for + example, by configuring one name for a subnet (/64) or a site (/48). + As a concrete example, a site (or the site's ISP) could configure the + reverses of the prefix 2001:db8:f00::/48 to point to 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, such a name could not be verified + from the forward DNS, but would at least provide some form of + "topological information" or "weak authorization" if that is really + considered to be useful. Note that this is not actually updating the + DNS as such, as the whole point is to avoid DNS updates completely by + manually configuring a generic name. + + + + + + +Durand, et al. Informational [Page 15] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +7.3. DDNS with Stateless Address Autoconfiguration + + Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in + some regard, while being more difficult in another, as described + below. + + The address space administrator decides whether or not the hosts are + trusted to update their reverse DNS records. If they are trusted and + deployed at the same site (e.g., not across the Internet), a simple + address-based authorization is typically sufficient (i.e., check that + the DNS update is done from the same IP address as the record being + updated); stronger security can also be used [RFC3007]. If they + aren't allowed to update the reverses, no update can occur. However, + such address-based update authorization operationally requires that + ingress filtering [RFC3704] has been set up at the border of the site + where the updates occur, and as close to the updater as possible. + + Address-based authorization is simpler with reverse DNS (as there is + a connection between the record and the address) than with forward + DNS. However, 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. Note that the user may roam to + different networks and does not 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 does not typically know a priori that it + will be disconnected, and it cannot send a DNS update using the + correct source address to remove a record. + + A problem with defining the clean-up process is that it is difficult + to ensure that a specific IP address and the corresponding record are + no longer being used. Considering the huge address space, and the + unlikelihood of collision within 64 bits of the interface + identifiers, a process that would remove the record after no traffic + has been seen from a node in a long period of time (e.g., a month or + year) might be one possible approach. + + To insert or update the record, the node must discover the DNS server + to send the update to somehow, similar to as discussed in + Section 6.2. One way to automate this is looking up the DNS server + authoritative (e.g., through SOA record) for the IP address being + updated, but the security material (unless the IP address-based + authorization is trusted) must also be established by some other + means. + + + + +Durand, et al. Informational [Page 16] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + One should note that Cryptographically Generated Addresses (CGAs) + [RFC3972] may require 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 is not 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 to + the DNS that reflects the name (e.g., "dhcp-67.example.com"). One + can assume similar practice may become commonplace with DHCPv6 as + well; all such mappings would be pre-configured and would require no + updating. + + If a more explicit control is required, similar considerations as + with SLAAC apply, except for the fact 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 is yet 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 address 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, one should consider what is the location of the server where + DDNS updates are made. That is, where the DNS server is located: + + 1. At the same organization as the prefix delegator. + + 2. 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. + + + + +Durand, et al. Informational [Page 17] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + 3. 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. Like 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 + as the DNS server and the prefix delegator are in the same + administrative domain (as there is 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 slightly more + difficult, particularly as the site will have to configure the DNS + server to be authoritative for the delegated reverse zone, implying + automatic configuration of the DNS server -- as the prefix may be + dynamic. + + Managing the DDNS reverse updates is typically simple in the second + case, as 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). As there + is an explicit (security) relationship between the parties in the + third case, setting up the 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 considerations about DNS 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 TTL, and uses the result + obtained from DNS as long as it happens to be stored in the memory of + the application. For applications that run for a long time, this + + + + +Durand, et al. Informational [Page 18] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + could be days, weeks, or even months. Some applications may be + clever enough to organize the data structures and functions in such a + manner that lookups get refreshed now and then. + + While the issue appears to have a clear solution, "fix the + applications", practically, this is not reasonable immediate advice. + The TTL information is not typically 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 to achieve the ultimate goal of avoiding using the 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 in clarifying 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 + + This document reviews the operational procedures for IPv6 DNS + operations and does not have security considerations in itself. + + However, it is worth noting that in particular with Dynamic DNS + updates, security models based on the source address validation are + very weak and cannot be recommended -- they could only be considered + in the environments where ingress filtering [RFC3704] has been + deployed. On the other hand, it should be noted that setting up an + authorization mechanism (e.g., a shared secret, or public-private + keys) between a node and the DNS server has to be done manually, and + may require quite a bit of time and expertise. + + To re-emphasize what was already stated, the reverse+forward DNS + check provides very weak security at best, and the only + (questionable) security-related use for them may be in conjunction + with other mechanisms when authenticating a user. + + + + + + + + + +Durand, et al. Informational [Page 19] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +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. + + + +Durand, et al. Informational [Page 20] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + [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. + + + + + + + + +Durand, et al. Informational [Page 21] + +RFC 4472 Considerations with IPv6 DNS April 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. + + + + +Durand, et al. Informational [Page 22] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + [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. + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Informational [Page 23] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +Appendix A. Unique Local Addressing Considerations for DNS + + Unique local addresses [RFC4193] have replaced the now-deprecated + site-local addresses [RFC3879]. From the perspective of the DNS, the + locally generated unique local addresses (LUL) and site-local + addresses have similar properties. + + The interactions with DNS come in two flavors: forward and reverse + DNS. + + To actually use local addresses within a site, this implies the + deployment of a "split-faced" or a fragmented DNS name space, for the + zones internal to the site, and the outsiders' view to it. The + procedures to achieve this are not elaborated here. The implication + is that local addresses must not be published in the public DNS. + + To facilitate reverse DNS (if desired) with local addresses, the stub + resolvers must look for DNS information from the local DNS servers, + not, e.g., starting from the root servers, so that the local + information may be provided locally. Note that the experience of + private addresses in IPv4 has shown that the root servers get loaded + for requests for private address lookups in any case. This + requirement is discussed in [RFC4193]. + +Appendix B. Behavior of Additional Data in IPv4/IPv6 Environments + + DNS responses do not always fit in a single UDP packet. We'll + examine the cases that happen when this is due to too much data in + the Additional section. + +B.1. Description of Additional Data Scenarios + + There are two kinds of additional data: + + 1. "critical" additional data; this must be included in all + scenarios, with all the RRsets, and + + 2. "courtesy" additional data; this could be sent in full, with only + a few RRsets, or with no RRsets, and can be fetched separately as + well, but at the cost of additional queries. + + The responding server can algorithmically determine which type the + additional data is by checking whether it's at or below a zone cut. + + Only those additional data records (even if sometimes carelessly + termed "glue") are considered "critical" or real "glue" if and only + if they meet the above-mentioned condition, as specified in Section + 4.2.1 of [RFC1034]. + + + +Durand, et al. Informational [Page 24] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + + Remember that resource record sets (RRsets) are never "broken up", so + if a name has 4 A records and 5 AAAA records, you can either return + all 9, all 4 A records, all 5 AAAA records, or nothing. In + particular, notice that for the "critical" additional data getting + all the RRsets can be critical. + + In particular, [RFC2181] specifies (in Section 9) that: + + a. if all the "critical" RRsets do not fit, the sender should set + the TC bit, and the recipient should discard the whole response + and retry using mechanism allowing larger responses such as TCP. + + b. "courtesy" additional data should not cause the setting of the TC + bit, but instead all the non-fitting additional data RRsets + should be removed. + + An example of the "courtesy" additional data is A/AAAA records in + conjunction with MX records as shown in Section 4.4; an example of + the "critical" additional data is shown below (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::1 + + When there is too much "courtesy" additional data, at least the non- + fitting RRsets should be removed [RFC2181]; however, as the + additional data is not critical, even all of it could be safely + removed. + + When there is too much "critical" additional data, TC bit will have + 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 + issue is which data could be retained. + + However, the practice may differ from 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, while some forms of additional + data may be treated preferably. All the implementations remove some + (critical or courtesy) additional data RRsets without setting the TC + bit if the response would not otherwise fit. + + Failing to discard the response with the TC bit or omitting critical + information but not setting the TC bit lead to an unrecoverable + problem. Omitting only some of the RRsets if all would not fit (but + not setting the TC bit) leads to a performance problem. These are + discussed in the next two subsections. + + + +Durand, et al. Informational [Page 25] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +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, and we describe that behavior as well. + + If the implementation decides to keep as much data (whether + "critical" or "courtesy") as possible in the 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. + However, this breaks the model of independence of DNS transport and + resource records, as noted in Section 1.2. + + With courtesy additional data, as long as enough RRsets will be + removed so that TC will not be set, it is allowed to send as many + complete RRsets as the implementations prefers. However, the + implementations are also free to omit all such RRsets, even if + complete. Omitting all the RRsets (when removing only some would + suffice) may create a performance penalty, whereby the client may + need to issue one or more additional queries to obtain necessary + and/or consistent information. + + With critical additional data, the alternatives are either returning + nothing (and absolutely requiring a retry with TCP) or returning + something (working also in the case if the recipient does not discard + the response and retry using TCP) in addition to setting the TC bit. + 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 if one looked at the transport of + the query, it would have a larger possibility of being right than + just 50/50. In other words, if the returned critical additional data + would have to be selected somehow, using something more sophisticated + than a random process would seem justifiable. + + That is, leaving in some intelligently selected critical additional + data is a trade-off between creating an optimization for those + resolvers that ignore the "should discard" recommendation and causing + a protocol problem by propagating inconsistent information about + "critical" records in 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. + + + + + + +Durand, et al. Informational [Page 26] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +B.3. Discussion of the Potential Problems + + As noted above, the temptation for omitting only some of the + additional data could be problematic. This is discussed more below. + + For courtesy additional data, this causes a potential performance + problem as this requires that the clients issue re-queries for the + potentially omitted RRsets. For critical additional data, this + causes a potential unrecoverable problem if the response is not + discarded and the query not re-tried with TCP, as the nameservers + might be reachable only through the omitted RRsets. + + If an implementation would look at the transport used for the query, + it is worth remembering that often the host using the records is + different from the node requesting 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 those of the requestor. This might + result in, e.g., inappropriately returning A records to an IPv6-only + node, going through a translation, or opening 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 would be consistent and complete -- or if that + is not 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 entering too many records that will be + returned truncated (or missing some RRsets, depending on + implementations) 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, pushing 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 the DNS server implementations + return a warning when the administrators create zones that would + result in too much additional data being returned. Further, DNS + server implementations should warn of or disallow such zone + configurations that are recursive or otherwise difficult to manage by + the protocol. + + + + + + + + + + + +Durand, et al. Informational [Page 27] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +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.fi + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Informational [Page 28] + +RFC 4472 Considerations with IPv6 DNS April 2006 + + +Full 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the 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). + + + + + + + +Durand, et al. Informational [Page 29] + diff --git a/doc/rfc/rfc4509.txt b/doc/rfc/rfc4509.txt new file mode 100644 index 000000000000..4eaf296c7baf --- /dev/null +++ b/doc/rfc/rfc4509.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group W. Hardaker +Request for Comments: 4509 Sparta +Category: Standards Track May 2006 + + + Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document specifies how to use the SHA-256 digest type in DNS + Delegation Signer (DS) Resource Records (RRs). DS records, when + stored in a parent zone, point to DNSKEYs in a child zone. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Implementing the SHA-256 Algorithm for DS Record Support ........2 + 2.1. DS Record Field Values .....................................2 + 2.2. DS Record with SHA-256 Wire Format .........................3 + 2.3. Example DS Record Using SHA-256 ............................3 + 3. Implementation Requirements .....................................3 + 4. Deployment Considerations .......................................4 + 5. IANA Considerations .............................................4 + 6. Security Considerations .........................................4 + 6.1. Potential Digest Type Downgrade Attacks ....................4 + 6.2. SHA-1 vs SHA-256 Considerations for DS Records .............5 + 7. Acknowledgements ................................................5 + 8. References ......................................................6 + 8.1. Normative References .......................................6 + 8.2. Informative References .....................................6 + + + + + + + + +Hardaker Standards Track [Page 1] + +RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 + + +1. Introduction + + The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent + zones to distribute a cryptographic digest of one key in a child's + DNSKEY RRset. The DS RRset is signed by at least one of the parent + zone's private zone data signing keys for each algorithm in use by + the parent. Each signature is published in an RRSIG resource record, + owned by the same domain as the DS RRset, with a type covered of DS. + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in [RFC2119]. + +2. Implementing the SHA-256 Algorithm for DS Record Support + + This document specifies that the digest type code 2 has been assigned + to SHA-256 [SHA256] [SHA256CODE] for use within DS records. The + results of the digest algorithm MUST NOT be truncated, and the entire + 32 byte digest result is to be published in the DS record. + +2.1. DS Record Field Values + + Using the SHA-256 digest algorithm within a DS record will make use + of the following DS-record fields: + + Digest type: 2 + + Digest: A SHA-256 bit digest value calculated by using the following + formula ("|" denotes concatenation). The resulting value is not + truncated, and the entire 32 byte result is to be used in the + resulting DS record and related calculations. + + digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) + + where DNSKEY RDATA is defined by [RFC4034] as: + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key + + The Key Tag field and Algorithm fields remain unchanged by this + document and are specified in the [RFC4034] specification. + + + + + + + + + + + +Hardaker Standards Track [Page 2] + +RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 + + +2.2. DS Record with SHA-256 Wire Format + + The resulting on-the-wire format for the resulting DS record will be + as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | DigestType=2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest (length for SHA-256 is 32 bytes) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + +2.3. Example DS Record Using SHA-256 + + The following is an example DNSKEY and matching DS record. This + DNSKEY record comes from the example DNSKEY/DS records found in + section 5.4 of [RFC4034]. + + The DNSKEY record: + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + The resulting DS record covering the above DNSKEY record using a + SHA-256 digest: + + dskey.example.com. 86400 IN DS 60485 5 2 ( D4B7D520E7BB5F0F67674A0C + CEB1E3E0614B93C4F9E99B83 + 83F6A1E4469DA50A ) + +3. Implementation Requirements + + Implementations MUST support the use of the SHA-256 algorithm in DS + RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 + digests if DS RRs with SHA-256 digests are present in the DS RRset. + + + + + + +Hardaker Standards Track [Page 3] + +RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 + + +4. Deployment Considerations + + If a validator does not support the SHA-256 digest type and no other + DS RR exists in a zone's DS RRset with a supported digest type, then + the validator has no supported authentication path leading from the + parent to the child. The resolver should treat this case as it would + the case of an authenticated NSEC RRset proving that no DS RRset + exists, as described in [RFC4035], Section 5.2. + + Because zone administrators cannot control the deployment speed of + support for SHA-256 in validators that may be referencing any of + their zones, zone operators should consider deploying both SHA-1 and + SHA-256 based DS records. This should be done for every DNSKEY for + which DS records are being generated. Whether to make use of both + digest types and for how long is a policy decision that extends + beyond the scope of this document. + +5. IANA Considerations + + Only one IANA action is required by this document: + + The Digest Type to be used for supporting SHA-256 within DS records + has been assigned by IANA. + + At the time of this writing, the current digest types assigned for + use in DS records are as follows: + + VALUE Digest Type Status + 0 Reserved - + 1 SHA-1 MANDATORY + 2 SHA-256 MANDATORY + 3-255 Unassigned - + +6. Security Considerations + +6.1. Potential Digest Type Downgrade Attacks + + A downgrade attack from a stronger digest type to a weaker one is + possible if all of the following are true: + + o A zone includes multiple DS records for a given child's DNSKEY, + each of which uses a different digest type. + + o A validator accepts a weaker digest even if a stronger one is + present but invalid. + + + + + + +Hardaker Standards Track [Page 4] + +RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 + + + For example, if the following conditions are all true: + + o Both SHA-1 and SHA-256 based digests are published in DS records + within a parent zone for a given child zone's DNSKEY. + + o The DS record with the SHA-1 digest matches the digest computed + using the child zone's DNSKEY. + + o The DS record with the SHA-256 digest fails to match the digest + computed using the child zone's DNSKEY. + + Then, if the validator accepts the above situation as secure, then + this can be used as a downgrade attack since the stronger SHA-256 + digest is ignored. + +6.2. SHA-1 vs. SHA-256 Considerations for DS Records + + Users of DNSSEC are encouraged to deploy SHA-256 as soon as software + implementations allow for it. SHA-256 is widely believed to be more + resilient to attack than SHA-1, and confidence in SHA-1's strength is + being eroded by recently announced attacks. Regardless of whether + the attacks on SHA-1 will affect DNSSEC, it is believed (at the time + of this writing) that SHA-256 is the better choice for use in DS + records. + + At the time of this publication, the SHA-256 digest algorithm is + considered sufficiently strong for the immediate future. It is also + considered sufficient for use in DNSSEC DS RRs for the immediate + future. However, future published attacks may weaken the usability + of this algorithm within the DS RRs. It is beyond the scope of this + document to speculate extensively on the cryptographic strength of + the SHA-256 digest algorithm. + + Likewise, it is also beyond the scope of this document to specify + whether or for how long SHA-1 based DS records should be + simultaneously published alongside SHA-256 based DS records. + +7. Acknowledgements + + This document is a minor extension to the existing DNSSEC documents + and those authors are gratefully appreciated for the hard work that + went into the base documents. + + The following people contributed to portions of this document in some + fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, + Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam + Weiler. + + + + +Hardaker Standards Track [Page 5] + +RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [SHA256] National Institute of Standards and Technology, "Secure + Hash Algorithm. NIST FIPS 180-2", August 2002. + +8.2. Informative References + + [SHA256CODE] Eastlake, D., "US Secure Hash Algorithms (SHA)", Work in + Progress. + +Author's Address + + Wes Hardaker + Sparta + P.O. Box 382 + Davis, CA 95617 + USA + + EMail: hardaker@tislabs.com + + + + + + + + + + + + + + + +Hardaker Standards Track [Page 6] + +RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 + + +Full 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the 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). + + + + + + + +Hardaker Standards Track [Page 7] + diff --git a/doc/rfc/rfc4635.txt b/doc/rfc/rfc4635.txt new file mode 100644 index 000000000000..554502dc91e6 --- /dev/null +++ b/doc/rfc/rfc4635.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group D. Eastlake 3rd +Request for Comments: 4635 Motorola Laboratories +Category: Standards Track August 2006 + + + HMAC SHA TSIG Algorithm Identifiers + + Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + Use of the Domain Name System TSIG resource record requires + specification of a cryptographic message authentication code. + Currently, identifiers have been specified only for HMAC MD5 (Hashed + Message Authentication Code, Message Digest 5) and GSS (Generic + Security Service) TSIG algorithms. This document standardizes + identifiers and implementation requirements for additional HMAC SHA + (Secure Hash Algorithm) TSIG algorithms and standardizes how to + specify and handle the truncation of HMAC values in TSIG. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Algorithms and Identifiers ......................................2 + 3. Specifying Truncation ...........................................3 + 3.1. Truncation Specification ...................................4 + 4. TSIG Truncation Policy and Error Provisions .....................4 + 5. IANA Considerations .............................................5 + 6. Security Considerations .........................................5 + 7. Normative References ............................................6 + 8. Informative References. .........................................7 + + + + + + + + + + +Eastlake 3rd Standards Track [Page 1] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + +1. Introduction + + [RFC2845] specifies a TSIG Resource Record (RR) that can be used to + authenticate DNS (Domain Name System [STD13]) queries and responses. + This RR contains a domain name syntax data item that names the + authentication algorithm used. [RFC2845] defines the + HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC + (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5 + (Message Digest 5) [RFC1321] hash algorithm. IANA has also + registered "gss-tsig" as an identifier for TSIG authentication where + the cryptographic operations are delegated to the Generic Security + Service (GSS) [RFC3645]. + + Note that use of TSIG presumes prior agreement, between the resolver + and server involved, as to the algorithm and key to be used. + + In Section 2, this document specifies additional names for TSIG + authentication algorithms based on US NIST SHA (United States, + National Institute of Science and Technology, Secure Hash Algorithm) + algorithms and HMAC and specifies the implementation requirements for + those algorithms. + + In Section 3, this document specifies the effect of inequality + between the normal output size of the specified hash function and the + length of MAC (Message Authentication Code) data given in the TSIG + RR. In particular, it specifies that a shorter-length field value + specifies truncation and that a longer-length field is an error. + + In Section 4, policy restrictions and implications related to + truncation are described and specified, as is a new error code to + indicate truncation shorter than that permitted by policy. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in + this document are to be interpreted as described in [RFC2119]. + +2. Algorithms and Identifiers + + TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS + queries and responses. They are intended to be efficient symmetric + authentication codes based on a shared secret. (Asymmetric + signatures can be provided using the SIG RR [RFC2931]. In + particular, SIG(0) can be used for transaction signatures.) Used + with a strong hash function, HMAC [RFC2104] provides a way to + calculate such symmetric authentication codes. The only specified + HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG- + ALG.REG.INT, based on MD5 [RFC1321]. + + + + + +Eastlake 3rd Standards Track [Page 2] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + + The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as + compared with the 128 bits for MD5, and additional hash algorithms in + the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and + 512 bits may be preferred in some cases. This is because + increasingly successful cryptanalytic attacks are being made on the + shorter hashes. + + Use of TSIG between a DNS resolver and server is by mutual agreement. + That agreement can include the support of additional algorithms and + criteria as to which algorithms and truncations are acceptable, + subject to the restriction and guidelines in Sections 3 and 4 below. + Key agreement can be by the TKEY mechanism [RFC2930] or some other + mutually agreeable method. + + The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are + included in the table below for convenience. Implementations that + support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY + implement gss-tsig and the other algorithms listed below. + + Mandatory HMAC-MD5.SIG-ALG.REG.INT + Optional gss-tsig + Mandatory hmac-sha1 + Optional hmac-sha224 + Mandatory hmac-sha256 + Optional hamc-sha384 + Optional hmac-sha512 + + SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. + +3. Specifying Truncation + + When space is at a premium and the strength of the full length of an + HMAC is not needed, it is reasonable to truncate the HMAC output and + use the truncated value for authentication. HMAC SHA-1 truncated to + 96 bits is an option available in several IETF protocols, including + IPsec and TLS. + + The TSIG RR [RFC2845] includes a "MAC size" field, which gives the + size of the MAC field in octets. However, [RFC2845] does not specify + what to do if this MAC size differs from the length of the output of + HMAC for a particular hash function. Truncation is indicated by a + MAC size less than the HMAC size, as specified below. + + + + + + + + + +Eastlake 3rd Standards Track [Page 3] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + +3.1. Truncation Specification + + The specification for TSIG handling is changed as follows: + + 1. If "MAC size" field is greater than HMAC output length: + + This case MUST NOT be generated and, if received, MUST cause + the packet to be dropped and RCODE 1 (FORMERR) to be returned. + + 2. If "MAC size" field equals HMAC output length: + + Operation is as described in [RFC2845], and the entire output + HMAC output is present. + + 3. "MAC size" field is less than HMAC output length but greater than + that specified in case 4, below: + + This is sent when the signer has truncated the HMAC output to + an allowable length, as described in RFC 2104, taking initial + octets and discarding trailing octets. TSIG truncation can only + be to an integral number of octets. On receipt of a packet with + truncation thus indicated, the locally calculated MAC is similarly + truncated and only the truncated values are compared for + authentication. The request MAC used when calculating the TSIG + MAC for a reply is the truncated request MAC. + + 4. "MAC size" field is less than the larger of 10 (octets) and half + the length of the hash function in use: + + With the exception of certain TSIG error messages described in + RFC 2845, Section 3.2, where it is permitted that the MAC size be + zero, this case MUST NOT be generated and, if received, MUST cause + the packet to be dropped and RCODE 1 (FORMERR) to be returned. + The size limit for this case can also, for the hash functions + mentioned in this document, be stated as less than half the hash + function length for hash functions other than MD5 and less than 10 + octets for MD5. + +4. TSIG Truncation Policy and Error Provisions + + Use of TSIG is by mutual agreement between a resolver and server. + Implicit in such "agreement" are criterion as to acceptable keys and + algorithms and, with the extensions in this document, truncations. + Note that it is common for implementations to bind the TSIG secret + key or keys that may be in place at a resolver and server to + particular algorithms. Thus, such implementations only permit the + + + + + +Eastlake 3rd Standards Track [Page 4] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + + use of an algorithm if there is an associated key in place. Receipt + of an unknown, unimplemented, or disabled algorithm typically results + in a BADKEY error. + + Local policies MAY require the rejection of TSIGs, even though + they use an algorithm for which implementation is mandatory. + + When a local policy permits acceptance of a TSIG with a particular + algorithm and a particular non-zero amount of truncation, it SHOULD + also permit the use of that algorithm with lesser truncation (a + longer MAC) up to the full HMAC output. + + Regardless of a lower acceptable truncated MAC length specified by + local policy, a reply SHOULD be sent with a MAC at least as long as + that in the corresponding request, unless the request specified a MAC + length longer than the HMAC output. + + Implementations permitting multiple acceptable algorithms and/or + truncations SHOULD permit this list to be ordered by presumed + strength and SHOULD allow different truncations for the same + algorithm to be treated as separate entities in this list. When so + implemented, policies SHOULD accept a presumed stronger algorithm and + truncation than the minimum strength required by the policy. + + If a TSIG is received with truncation that is permitted under + Section 3 above but the MAC is too short for the local policy in + force, an RCODE of 22 (BADTRUNC) MUST be returned. + +5. IANA Considerations + + This document (1) registers the new TSIG algorithm identifiers listed + in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in + Section 4 [RFC2845]. + +6. Security Considerations + + For all of the message authentication code algorithms listed herein, + those producing longer values are believed to be stronger; however, + while there have been some arguments that mild truncation can + strengthen a MAC by reducing the information available to an + attacker, excessive truncation clearly weakens authentication by + reducing the number of bits an attacker has to try to break the + authentication by brute force [RFC2104]. + + Significant progress has been made recently in cryptanalysis of hash + function of the types used herein, all of which ultimately derive + from the design of MD4. While the results so far should not effect + + + + +Eastlake 3rd Standards Track [Page 5] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + + HMAC, the stronger SHA-1 and SHA-256 algorithms are being made + mandatory due to caution. + + See the Security Considerations section of [RFC2845]. See also the + Security Considerations section of [RFC2104] from which the limits on + truncation in this RFC were taken. + +7. Normative References + + [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US + Federal Information Processing Standard, with Change + Notice 1, February 2004. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC + 1321, April 1992. + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for + DNS (TSIG)", RFC 2845, May 2000. + + [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm + 1 (SHA1)", RFC 3174, September 2001. + + [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", + RFC 3874, September 2004. + + [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms + (SHA)", RFC 4634, July 2006. + + [STD13] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + + + + + + + + + +Eastlake 3rd Standards Track [Page 6] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + +8. Informative References. + + [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, September 2000. + + [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., + and R. Hall, "Generic Security Service Algorithm for + Secret Key Transaction Authentication for DNS (GSS- + TSIG)", RFC 3645, October 2003. + +Author's Address + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Phone: +1-508-786-7554 (w) + EMail: Donald.Eastlake@motorola.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eastlake 3rd Standards Track [Page 7] + +RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 + + +Full 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the 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). + + + + + + + +Eastlake 3rd Standards Track [Page 8] + diff --git a/doc/rfc/rfc4697.txt b/doc/rfc/rfc4697.txt new file mode 100644 index 000000000000..773507ca6904 --- /dev/null +++ b/doc/rfc/rfc4697.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group M. Larson +Request for Comments: 4697 P. Barber +BCP: 123 VeriSign, Inc. +Category: Best Current Practice October 2006 + + + Observed DNS Resolution Misbehavior + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This memo describes DNS iterative resolver behavior that results in a + significant query volume sent to the root and top-level domain (TLD) + name servers. We offer implementation advice to iterative resolver + developers to alleviate these unnecessary queries. The + recommendations made in this document are a direct byproduct of + observation and analysis of abnormal query traffic patterns seen at + two of the thirteen root name servers and all thirteen com/net TLD + name servers. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. A Note about Terminology in this Memo ......................3 + 1.2. Key Words ..................................................3 + 2. Observed Iterative Resolver Misbehavior .........................3 + 2.1. Aggressive Requerying for Delegation Information ...........3 + 2.1.1. Recommendation ......................................5 + 2.2. Repeated Queries to Lame Servers ...........................6 + 2.2.1. Recommendation ......................................6 + 2.3. Inability to Follow Multiple Levels of Indirection .........7 + 2.3.1. Recommendation ......................................7 + 2.4. Aggressive Retransmission when Fetching Glue ...............8 + 2.4.1. Recommendation ......................................9 + 2.5. Aggressive Retransmission behind Firewalls .................9 + 2.5.1. Recommendation .....................................10 + 2.6. Misconfigured NS Records ..................................10 + 2.6.1. Recommendation .....................................11 + + + + +Larson & Barber Best Current Practice [Page 1] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + 2.7. Name Server Records with Zero TTL .........................11 + 2.7.1. Recommendation .....................................12 + 2.8. Unnecessary Dynamic Update Messages .......................12 + 2.8.1. Recommendation .....................................13 + 2.9. Queries for Domain Names Resembling IPv4 Addresses ........13 + 2.9.1. Recommendation .....................................14 + 2.10. Misdirected Recursive Queries ............................14 + 2.10.1. Recommendation ....................................14 + 2.11. Suboptimal Name Server Selection Algorithm ...............15 + 2.11.1. Recommendation ....................................15 + 3. Security Considerations ........................................16 + 4. Acknowledgements ...............................................16 + 5. Internationalization Considerations ............................16 + 6. References .....................................................16 + 6.1. Normative References ......................................16 + 6.2. Informative References ....................................16 + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net Top-Level Domain (TLD) name servers has revealed + that a large proportion of the total traffic often consists of + "requeries". A requery is the same question (<QNAME, QTYPE, QCLASS>) + asked repeatedly at an unexpectedly high rate. We have observed + requeries from both a single IP address and multiple IP addresses + (i.e., the same query received simultaneously from multiple IP + addresses). + + By analyzing requery events, we have found that the cause of the + duplicate traffic is almost always a deficient iterative resolver, + stub resolver, or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of indirection must be followed, and aggressive retry by stub + resolvers or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (Denial of Service (DoS) attacks, crashes, maintenance, + routing failures, congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. None of the changes recommended affects the core DNS protocol + specification; instead, this document consists of guidelines to + implementors of iterative resolvers. + + + + + +Larson & Barber Best Current Practice [Page 2] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +1.1. A Note about Terminology in This Memo + + To recast an old saying about standards, the nice thing about DNS + terms is that there are so many of them to choose from. Writing or + talking about DNS can be difficult and can cause confusion resulting + from a lack of agreed-upon terms for its various components. Further + complicating matters are implementations that combine multiple roles + into one piece of software, which makes naming the result + problematic. An example is the entity that accepts recursive + queries, issues iterative queries as necessary to resolve the initial + recursive query, caches responses it receives, and which is also able + to answer questions about certain zones authoritatively. This entity + is an iterative resolver combined with an authoritative name server + and is often called a "recursive name server" or a "caching name + server". + + This memo is concerned principally with the behavior of iterative + resolvers, which are typically found as part of a recursive name + server. This memo uses the more precise term "iterative resolver", + because the focus is usually on that component. In instances where + the name server role of this entity requires mentioning, this memo + uses the term "recursive name server". As an example of the + difference, the name server component of a recursive name server + receives DNS queries and the iterative resolver component sends + queries. + + The advent of IPv6 requires mentioning AAAA records as well as A + records when discussing glue. To avoid continuous repetition and + qualification, this memo uses the general term "address record" to + encompass both A and AAAA records when a particular situation is + relevant to both types. + +1.2. Key Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +2. Observed Iterative Resolver Misbehavior + +2.1. Aggressive Requerying for Delegation Information + + There can be times when every name server in a zone's NS RRSet is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host), or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider an iterative resolver + that attempts to resolve a query for a domain name in such a zone and + + + +Larson & Barber Best Current Practice [Page 3] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation whose + iterative resolver then verifies the zone's NS RRSet in its cache by + querying for the zone's delegation information: it sends a query for + the zone's NS RRSet to one of the parent zone's name servers. (Note + that queries with QTYPE=NS are not required by the standard + resolution algorithm described in Section 4.3.2 of RFC 1034 [2]. + These NS queries represent this implementation's addition to that + algorithm.) + + For example, suppose that "example.com" has the following NS RRSet: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this iterative resolver implementation immediately queries a + "com" zone name server for the "example.com" NS RRSet to verify that + it has the proper delegation information. This implementation + performs this query to a zone's parent zone for each recursive query + it receives that fails because of a completely unresponsive set of + name servers for the target zone. Consider the effect when a popular + zone experiences a catastrophic failure of all its name servers: now + every recursive query for domain names in that zone sent to this + recursive name server implementation results in a query to the failed + zone's parent name servers. On one occasion when several dozen + popular zones became unreachable, the query load on the com/net name + servers increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: when an iterative resolver is resolving a query for a + domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent would be pointless: this query to the parent would come so + quickly on the heels of the referral that it would be almost certain + to contain the same list of name servers. The chance of discovering + any new information is slim. + + The other possibility is that the iterative resolver successfully + contacts one of the target zone's name servers and then caches the NS + RRSet from the authority section of a response, the proper behavior + according to Section 5.4.1 of RFC 2181 [3], because the NS RRSet from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the iterative resolver discovers that none of the name servers + + + +Larson & Barber Best Current Practice [Page 4] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + specified in the cached NS RRSet is available or authoritative, + querying the parent would be wrong. An NS RRSet from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured or decommissioned AND the + delegation information in the parent zone would have to be updated + with the new set of name servers, all within the Time to Live (TTL) + of the target zone's NS RRSet. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually when at all possible, with servers + removed from the NS RRSet left authoritative for the zone as long as + possible. The scenarios that we can envision that would benefit from + the parent requery behavior do not outweigh its damaging effects. + + This section should not be understood to claim that all queries to a + zone's parent are bad. In some cases, such queries are not only + reasonable but required. Consider the situation when required + information, such as the address of a name server (i.e., the address + record corresponding to the RDATA of an NS record), has timed out of + an iterative resolver's cache before the corresponding NS record. If + the name of the name server is below the apex of the zone, then the + name server's address record is only available as glue in the parent + zone. For example, consider this NS record: + + example.com. IN NS ns.example.com. + + If a cache has this NS record but not the address record for + "ns.example.com", it is unable to contact the "example.com" zone + directly and must query the "com" zone to obtain the address record. + Note, however, that such a query would not have QTYPE=NS according to + the standard resolution algorithm. + +2.1.1. Recommendation + + An iterative resolver MUST NOT send a query for the NS RRSet of a + non-responsive zone to any of the name servers for that zone's parent + zone. For the purposes of this injunction, a non-responsive zone is + defined as a zone for which every name server listed in the zone's NS + RRSet: + + 1. is not authoritative for the zone (i.e., lame), or + + 2. returns a server failure response (RCODE=2), or + + 3. is dead or unreachable according to Section 7.2 of RFC 2308 [4]. + + + + +Larson & Barber Best Current Practice [Page 5] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.2. Repeated Queries to Lame Servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is when a subset of a zone's name servers is + unavailable or misconfigured. Different failure modes have different + expected durations. Some symptoms indicate problems that are + potentially transient, for example, various types of ICMP unreachable + messages because a name server process is not running or a host or + network is unreachable, or a complete lack of a response to a query. + Such responses could be the result of a host rebooting or temporary + outages; these events do not necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + + It should also be noted, however, that some authoritative name server + implementations appear to be lame only for queries of certain types + as described in RFC 4074 [5]. In this case, it makes sense to retry + the "lame" servers for other types of queries, particularly when all + known authoritative name servers appear to be "lame". + +2.2.1. Recommendation + + Iterative resolvers SHOULD cache name servers that they discover are + not authoritative for zones delegated to them (i.e., lame servers). + If this caching is performed, lame servers MUST be cached against the + specific query tuple <zone name, class, server IP address>. Zone + name can be derived from the owner name of the NS record that was + referenced to query the name server that was discovered to be lame. + + Implementations that perform lame server caching MUST refrain from + sending queries to known lame servers for a configurable time + interval after the server is discovered to be lame. A minimum + interval of thirty minutes is RECOMMENDED. + + + + + + + + +Larson & Barber Best Current Practice [Page 6] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + An exception to this recommendation occurs if all name servers for a + zone are marked lame. In that case, the iterative resolver SHOULD + temporarily ignore the servers' lameness status and query one or more + servers. This behavior is a workaround for the type-specific + lameness issue described in the previous section. + + Implementors should take care not to make lame server avoidance logic + overly broad: note that a name server could be lame for a parent zone + but not a child zone, e.g., lame for "example.com" but properly + authoritative for "sub.example.com". Therefore, a name server should + not be automatically considered lame for subzones. In the case + above, even if a name server is known to be lame for "example.com", + it should be queried for QNAMEs at or below "sub.example.com" if an + NS record indicates that it should be authoritative for that zone. + +2.3. Inability to Follow Multiple Levels of Indirection + + Some iterative resolver implementations are unable to follow + sufficient levels of indirection. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + An iterative resolver resolving the name "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" or "ns2.test.example.net" in order to obtain + address records for "ns1.example.com" or "ns2.example.com" in order + to query those name servers for the address records of + "www.foo.example". Although this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + top-level domains (gTLDs) become active. We anticipate many zones in + new gTLDs will use name servers in existing gTLDs, increasing the + number of delegations using out-of-zone name servers. + +2.3.1. Recommendation + + Clearly constructing a delegation that relies on multiple levels of + indirection is not a good administrative practice. However, the + practice is widespread enough to require that iterative resolvers be + able to cope with it. Iterative resolvers SHOULD be able to handle + arbitrary levels of indirection resulting from out-of-zone name + + + +Larson & Barber Best Current Practice [Page 7] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + servers. Iterative resolvers SHOULD implement a level-of-effort + counter to avoid loops or otherwise performing too much work in + resolving pathological cases. + + A best practice that avoids this entire issue of indirection is to + name one or more of a zone's name servers in the zone itself. For + example, if the zone is named "example.com", consider naming some of + the name servers "ns{1,2,...}.example.com" (or similar). + +2.4. Aggressive Retransmission when Fetching Glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in Section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include address records for every NS record in + the authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing address records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such an entity will not + normally generate any queries of its own. Instead it answers non- + recursive queries from iterative resolvers looking for information in + zones it serves. With glue fetching enabled, however, an + authoritative server invokes an iterative resolver to look up an + unknown address record to complete the additional section of a + response. + + We have observed situations where the iterative resolver of a glue- + fetching name server can send queries that reach other name servers, + but is apparently prevented from receiving the responses. For + example, perhaps the name server is authoritative-only and therefore + its administrators expect it to receive only queries and not + responses. Perhaps unaware of glue fetching and presuming that the + name server's iterative resolver will generate no queries, its + administrators place the name server behind a network device that + prevents it from receiving responses. If this is the case, all + glue-fetching queries will go unanswered. + + We have observed name server implementations whose iterative + resolvers retry excessively when glue-fetching queries are + unanswered. A single com/net name server has received hundreds of + queries per second from a single such source. Judging from the + + + +Larson & Barber Best Current Practice [Page 8] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + specific queries received and based on additional analysis, we + believe these queries result from overly aggressive glue fetching. + +2.4.1. Recommendation + + Implementers whose name servers support glue fetching SHOULD take + care to avoid sending queries at excessive rates. Implementations + SHOULD support throttling logic to detect when queries are sent but + no responses are received. + +2.5. Aggressive Retransmission behind Firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, an + iterative resolver is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose iterative resolvers' + traffic is improperly filtered in this manner. Stub resolvers in the + organization could be configured to query multiple recursive name + servers. Consider the case where a stub resolver queries a filtered + recursive name server first. The iterative resolver of this + recursive name server sends one or more queries whose replies are + filtered, so it cannot respond to the stub resolver, which times out. + Then the stub resolver retransmits to a recursive name server that is + able to provide an answer. Since resolution ultimately succeeds the + underlying problem might not be recognized or corrected. A popular + stub resolver implementation has a very aggressive retransmission + schedule, including simultaneous queries to multiple recursive name + servers, which could explain how such a situation could persist + without being detected. + + + + + + + + +Larson & Barber Best Current Practice [Page 9] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.5.1. Recommendation + + The most obvious recommendation is that administrators SHOULD take + care not to place iterative resolvers behind a firewall that allows + queries, but not the resulting replies, to pass through. + + Iterative resolvers SHOULD take care to avoid sending queries at + excessive rates. Implementations SHOULD support throttling logic to + detect when queries are sent but no responses are received. + +2.6. Misconfigured NS Records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. An iterative resolver + attempting to resolve address records for "www.example.com" with no + cached information for this zone will query a "com" authoritative + server. The "com" server responds with a referral to the + "example.com" zone, consisting of NS records with valid RDATA and + associated glue records. (This example assumes that the + "example.com" zone delegation information is correct in the "com" + zone.) The iterative resolver caches the NS RRSet from the "com" + server and follows the referral by querying one of the "example.com" + authoritative servers. This server responds with the + "www.example.com" address record in the answer section and, + typically, the "example.com" NS records in the authority section and, + if space in the message remains, glue address records in the + additional section. According to Section 5.4.1 of RFC 2181 [3], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a non- + authoritative answer. Thus, the "example.com" NS RRSet just received + from the "example.com" authoritative server overrides the + "example.com" NS RRSet received moments ago from the "com" + authoritative server. + + + + + +Larson & Barber Best Current Practice [Page 10] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + But the "example.com" zone contains the erroneous NS RRSet as shown + in the example above. Subsequent queries for names in "example.com" + will cause the iterative resolver to attempt to use the incorrect NS + records and so it will try to resolve the nonexistent names + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the iterative resolver cannot reach any "example.com" name + servers. Therefore, attempts to resolve these names result in + address record queries to the "com" authoritative servers. Queries + for such obviously bogus glue address records occur frequently at the + com/net name servers. + +2.6.1. Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that exists somewhere under the apex of the zone + that the NS record appears in. Note that further levels of + delegation are possible, so a missing trailing dot could + inadvertently create a name server name that actually exists in a + subzone. + + An authoritative name server SHOULD issue a warning when one of a + zone's NS records references a name server below the zone's apex when + a corresponding address record does not exist in the zone AND there + are no delegated subzones where the address record could exist. + +2.7. Name Server Records with Zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRSet, however, carries + additional consequences beyond the zone itself: if an iterative + resolver cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRSet expected to change frequently is extreme but + permissible. A zone's NS RRSet is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + zone parent/child relationships that we are aware of, there is + + + +Larson & Barber Best Current Practice [Page 11] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + typically some delay involved in effecting changes. Furthermore, + changes to the set of a zone's authoritative name servers (and + therefore to the zone's NS RRSet) are typically relatively rare: + providing reliable authoritative service requires a reasonably stable + set of servers. Therefore, an extremely low or zero TTL on a zone's + NS RRSet rarely makes sense, except in anticipation of an upcoming + change. In this case, when the zone's administrator has planned a + change and does not want iterative resolvers throughout the Internet + to cache the NS RRSet for a long period of time, a low TTL is + reasonable. + +2.7.1. Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers resulting from a zero TTL on a zone's NS RRSet, + under such circumstances authoritative name servers SHOULD issue a + warning when loading a zone. + +2.8. Unnecessary Dynamic Update Messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's Start of Authority (SOA) + record's MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone entails walking up the name + space tree by sending repeated UPDATE messages until successful. For + example, consider an agent attempting to add an address record with + the name "foo.bar.example.com". The agent could first attempt to + update the "foo.bar.example.com" zone. If the attempt failed, the + update could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A valid question is why the algorithm proceeds to send + updates all the way to TLD and root name servers. This behavior is + not entirely unreasonable: in enterprise DNS architectures with an + + + +Larson & Barber Best Current Practice [Page 12] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + "internal root" design, there could conceivably be private, non- + public TLD or root zones that would be the appropriate targets for a + dynamic update. + + A significant deficiency with this algorithm is that knowledge of a + given UPDATE message's failure is not helpful in directing future + UPDATE messages to the appropriate servers. A better algorithm would + be to find the closest enclosing zone by walking up the name space + with queries for SOA or NS rather than "probing" with UPDATE + messages. Once the appropriate zone is found, an UPDATE message can + be sent. In addition, the results of these queries can be cached to + aid in determining the closest enclosing zones for future updates. + Once the closest enclosing zone is determined with this method, the + update will either succeed or fail and there is no need to send + further updates to higher-level zones. The important point is that + walking up the tree with queries yields cacheable information, + whereas walking up the tree by sending UPDATE messages does not. + +2.8.1. Recommendation + + Dynamic update agents SHOULD send SOA or NS queries to progressively + higher-level names to find the closest enclosing zone for a given + name to update. Only after the appropriate zone is found should the + client send an UPDATE message to one of the zone's authoritative + servers. Update clients SHOULD NOT "probe" using UPDATE messages by + walking up the tree to progressively higher-level zones. + +2.9. Queries for Domain Names Resembling IPv4 Addresses + + The root name servers receive a significant number of A record + queries where the QNAME looks like an IPv4 address. The source of + these queries is unknown. It could be attributed to situations where + a user believes that an application will accept either a domain name + or an IP address in a given configuration option. The user enters an + IP address, but the application assumes that any input is a domain + name and attempts to resolve it, resulting in an A record lookup. + There could also be applications that produce such queries in a + misguided attempt to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. An iterative + resolver can negatively cache such responses, but each response + requires a separate cache entry; i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + + + + + + + +Larson & Barber Best Current Practice [Page 13] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.9.1. Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + bandwidth. A possible solution is to delegate these numeric TLDs + from the root zone to a separate set of servers to absorb the + traffic. The "black hole servers" used by the AS 112 Project + (http://www.as112.net), which are currently delegated the + in-addr.arpa zones corresponding to RFC 1918 [7] private use address + space, would be a possible choice to receive these delegations. Of + course, the proper and usual root zone change procedures would have + to be followed to make such a change to the root zone. + +2.10. Misdirected Recursive Queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the Recursion Desired (RD) bit set in the + header). Since none of the root servers offers recursion, the + servers' response in such a situation ignores the request for + recursion and the response probably does not contain the data the + querier anticipated. Some of these queries result from users + configuring stub resolvers to query a root server. (This situation + is not hypothetical: we have received complaints from users when this + configuration does not work as hoped.) Of course, users should not + direct stub resolvers to use name servers that do not offer + recursion, but we are not aware of any stub resolver implementation + that offers any feedback to the user when so configured, aside from + simply "not working". + +2.10.1. Recommendation + + When the IP address of a name server that supposedly offers recursion + is configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server indeed + supports recursion (i.e., verify that the response has the RA bit set + in the header). The user could be notified immediately if the server + is non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting SHOULD be throttled to avoid a + notification or log message for every response from a non-recursive + server. + + + + + + + + +Larson & Barber Best Current Practice [Page 14] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +2.11. Suboptimal Name Server Selection Algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully under-specified, requiring + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by an iterative resolver. When an iterative resolver wants + to contact one of a zone's authoritative name servers, how does it + choose from the NS records listed in the zone's NS RRSet? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1. Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. That is, these changes + would help spread the query load evenly. + + o Do not make assumptions based on NS RRSet order: all NS RRs SHOULD + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for + "a.gtld-servers.net" first in the authority section of referrals. + Apparently as a result, this server receives disproportionately + more traffic than the other twelve authoritative servers for + "com".) + + o Use all NS records in an RRSet. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + + o Do not lock onto the best-performing of a zone's name servers. An + iterative resolver SHOULD periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + +Larson & Barber Best Current Practice [Page 15] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +3. Security Considerations + + The iterative resolver misbehavior discussed in this document exposes + the root and TLD name servers to increased risk of both intentional + and unintentional Denial of Service attacks. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + +4. Acknowledgements + + The authors would like to thank the following people for their + comments that improved this document: Andras Salamon, Dave Meyer, + Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy, + Olafur Gudmundsson, Pekka Savola, Peter Koch, and Rob Austein. We + apologize if we have omitted anyone; any oversight was unintentional. + +5. Internationalization Considerations + + There are no new internationalization considerations introduced by + this memo. + +6. References + +6.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + +6.2. Informative References + + [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS + Queries for IPv6 Addresses", RFC 4074, May 2005. + + [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April + 1997. + + + +Larson & Barber Best Current Practice [Page 16] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + + [7] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: pbarber@verisign.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Best Current Practice [Page 17] + +RFC 4697 Observed DNS Resolution Misbehavior October 2006 + + +Full 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the 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). + + + + + + + +Larson & Barber Best Current Practice [Page 18] + diff --git a/doc/rfc/rfc4892.txt b/doc/rfc/rfc4892.txt new file mode 100644 index 000000000000..a89d3fb0892f --- /dev/null +++ b/doc/rfc/rfc4892.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Woolf +Request for Comments: 4892 Internet Systems Consortium, Inc. +Category: Informational D. Conrad + ICANN + June 2007 + + + Requirements for a Mechanism Identifying a Name Server Instance + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. A standardized mechanism to + determine the identity of a name server responding to a particular + query would be useful, particularly as a diagnostic aid for + administrators. Existing ad hoc mechanisms for addressing this need + have some shortcomings, not the least of which is the lack of prior + analysis of exactly how such a mechanism should be designed and + deployed. This document describes the existing convention used in + some widely deployed implementations of the DNS protocol, including + advantages and disadvantages, and discusses some attributes of an + improved mechanism. + +1. Introduction and Rationale + + Identifying which name server is responding to queries is often + useful, particularly in attempting to diagnose name server + difficulties. This is most obviously useful for authoritative + nameservers in the attempt to diagnose the source or prevalence of + inaccurate data, but can also conceivably be useful for caching + resolvers in similar and other situations. Furthermore, the ability + to identify which server is responding to a query has become more + useful as DNS has become more critical to more Internet users, and as + network and server deployment topologies have become more complex. + + + + + +Woolf & Conrad Informational [Page 1] + +RFC 4892 Serverid June 2007 + + + The conventional means for determining which of several possible + servers is answering a query has traditionally been based on the use + of the server's IP address as a unique identifier. However, the + modern Internet has seen the deployment of various load balancing, + fault-tolerance, or attack-resistance schemes such as shared use of + unicast IP addresses as documented in [RFC3258]. An unfortunate side + effect of these schemes has been to make the use of IP addresses as + identifiers associated with DNS (or any other) service somewhat + problematic. Specifically, multiple dedicated DNS queries may not go + to the same server even though sent to the same IP address. Non-DNS + methods such as ICMP ping, TCP connections, or non-DNS UDP packets + (such as those generated by tools like "traceroute"), etc., may well + be even less certain to reach the same server as the one which + receives the DNS queries. + + There is a well-known and frequently-used technique for determining + an identity for a nameserver more specific than the possibly-non- + unique "server that answered the query I sent to IP address A.B.C.D". + The widespread use of the existing convention suggests a need for a + documented, interoperable means of querying the identity of a + nameserver that may be part of an anycast or load-balancing cluster. + At the same time, however, it also has some drawbacks that argue + against standardizing it as it's been practiced so far. + +2. Existing Conventions + + For some time, the commonly deployed Berkeley Internet Name Domain + (BIND) implementation of the DNS protocol suite from the Internet + Systems Consortium [BIND] has supported a way of identifying a + particular server via the use of a standards-compliant, if somewhat + unusual, DNS query. Specifically, a query to a recent BIND server + for a TXT resource record in class 3 (CHAOS) for the domain name + "HOSTNAME.BIND." will return a string that can be configured by the + name server administrator to provide a unique identifier for the + responding server. (The value defaults to the result of a + gethostname() call). This mechanism, which is an extension of the + BIND convention of using CHAOS class TXT RR queries to sub-domains of + the "BIND." domain for version information, has been copied by + several name server vendors. + + A refinement to the BIND-based mechanism, which dropped the + implementation-specific label, replaces "BIND." with "SERVER.". Thus + the query label to learn the unique name of a server may appear as + "ID.SERVER.". + + (For reference, the other well-known name used by recent versions of + BIND within the CHAOS class "BIND." domain is "VERSION.BIND.". A + query for a CHAOS TXT RR for this name will return an + + + +Woolf & Conrad Informational [Page 2] + +RFC 4892 Serverid June 2007 + + + administratively defined string which defaults to the software + version of the server responding. This is, however, not generally + implemented by other vendors.) + +2.1. Advantages + + There are several valuable attributes to this mechanism, which + account for its usefulness. + + 1. The "HOSTNAME.BIND." or "ID.SERVER." query response mechanism is + within the DNS protocol itself. An identification mechanism that + relies on the DNS protocol is more likely to be successful + (although not guaranteed) in going to the same system as a + "normal" DNS query. + + 2. Since the identity information is requested and returned within + the DNS protocol, it doesn't require allowing any other query + mechanism to the server, such as holes in firewalls for + otherwise-unallowed ICMP Echo requests. Thus it is likely to + reach the same server over a path subject to the same routing, + resource, and security policy as the query, without any special + exceptions to site security policy. + + 3. It is simple to configure. An administrator can easily turn on + this feature and control the results of the relevant query. + + 4. It allows the administrator complete control of what information + is given out in the response, minimizing passive leakage of + implementation or configuration details. Such details are often + considered sensitive by infrastructure operators. + +2.2. Disadvantages + + At the same time, there are some serious drawbacks to the CHAOS/TXT + query mechanism that argue against standardizing it as it currently + operates. + + 1. It requires an additional query to correlate between the answer + to a DNS query under normal conditions and the supposed identity + of the server receiving the query. There are a number of + situations in which this simply isn't reliable. + + 2. It reserves an entire class in the DNS (CHAOS) for what amounts + to one zone. While CHAOS class is defined in [RFC1034] and + [RFC1035], it's not clear that supporting it solely for this + purpose is a good use of the namespace or of implementation + effort. + + + + +Woolf & Conrad Informational [Page 3] + +RFC 4892 Serverid June 2007 + + + 3. The initial and still common form, using "BIND.", is + implementation specific. BIND is one DNS implementation. At the + time of this writing, it is probably most prevalent for + authoritative servers. This does not justify standardizing on + its ad hoc solution to a problem shared across many operators and + implementors. Meanwhile, the aforementioned refinement changes + the query label but preserves the ad hoc CHAOS/TXT mechanism. + + 4. There is no convention or shared understanding of what + information an answer to such a query for a server identity could + or should contain, including a possible encoding or + authentication mechanism. + + 5. Hypothetically, since DNSSEC has been defined to cover all DNS + classes, the TXT RRs returned in response to the "ID.SERVER." + query could be signed, which has the advantages described in + [RFC4033]. However, since DNSSEC deployment for the CHAOS class + is neither existent nor foreseeable, and since the "ID.SERVER." + TXT RR is expected to be unique per server, this would be + impossible in practice. + + The first of the listed disadvantages may be technically the most + serious. It argues for an attempt to design a good answer to the + problem, "I need to know what nameserver is answering my queries", + not simply a convenient one. + +3. Characteristics of an Implementation Neutral Convention + + The discussion above of advantages and disadvantages to the + "HOSTNAME.BIND." mechanism suggest some requirements for a better + solution to the server identification problem. These are summarized + here as guidelines for any effort to provide appropriate protocol + extensions: + + 1. The mechanism adopted must be in-band for the DNS protocol. That + is, it needs to allow the query for the server's identifying + information to be part of a normal, operational query. It should + also permit a separate, dedicated query for the server's + identifying information. But it should preserve the ability of + the CHAOS/TXT query-based mechanism to work through firewalls and + in other situations where only DNS can be relied upon to reach + the server of interest. + + 2. The new mechanism should not require dedicated namespaces or + other reserved values outside of the existing protocol mechanisms + for these, i.e., the OPT pseudo-RR. In particular, it should not + propagate the existing drawback of requiring support for a CLASS + + + + +Woolf & Conrad Informational [Page 4] + +RFC 4892 Serverid June 2007 + + + and top level domain in the authoritative server (or the querying + tool) to be useful. + + 3. Support for the identification functionality should be easy to + implement and easy to enable. It must be easy to disable and + should lend itself to access controls on who can query for it. + + 4. It should be possible to return a unique identifier for a server + without requiring the exposure of information that may be non- + public and considered sensitive by the operator, such as a + hostname or unicast IP address maintained for administrative + purposes. + + 5. It should be possible to authenticate the received data by some + mechanism analogous to those provided by DNSSEC. In this + context, the need could be met by including encryption options in + the specification of a new mechanism. + + 6. The identification mechanism should not be implementation- + specific. + +4. IANA Considerations + + This document proposes no specific IANA action. Protocol extensions, + if any, to meet the requirements described are out of scope for this + document. A proposed extension, specified and adopted by normal IETF + process, is described in [NSID], including relevant IANA action. + +5. Security Considerations + + Providing identifying information as to which server is responding to + a particular query from a particular location in the Internet can be + seen as information leakage and thus a security risk. This motivates + the suggestion above that a new mechanism for server identification + allow the administrator to disable the functionality altogether or + partially restrict availability of the data. It also suggests that + the server identification data should not be readily correlated with + a hostname or unicast IP address that may be considered private to + the nameserver operator's management infrastructure. + + Propagation of protocol or service meta-data can sometimes expose the + application to denial of service or other attack. As the DNS is a + critically important infrastructure service for the production + Internet, extra care needs to be taken against this risk for + designers, implementors, and operators of a new mechanism for server + identification. + + + + + +Woolf & Conrad Informational [Page 5] + +RFC 4892 Serverid June 2007 + + + Both authentication and confidentiality of server identification data + are potentially of interest to administrators -- that is, operators + may wish to make such data available and reliable to themselves and + their chosen associates only. This constraint would imply both an + ability to authenticate it to themselves and to keep it private from + arbitrary other parties, which leads to characteristics 4 and 5 of an + improved solution. + +6. Acknowledgements + + The technique for host identification documented here was initially + implemented by Paul Vixie of the Internet Software Consortium in the + Berkeley Internet Name Daemon package. Comments and questions on + earlier versions were provided by Bob Halley, Brian Wellington, + Andreas Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and + members of the ICANN Root Server System Advisory Committee. The + newest version takes a significantly different direction from + previous versions, owing to discussion among contributors to the + DNSOP working group and others, particularly Olafur Gudmundsson, Ed + Lewis, Bill Manning, Sam Weiler, and Rob Austein. + +7. References + +7.1. Normative References + + [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via + Shared Unicast Addresses", RFC 3258, April 2002. + +7.2. Informative References + + [BIND] ISC, "BIND 9 Configuration Reference". + + [NSID] Austein, R., "DNS Name Server Identifier Option (NSID)", + Work in Progress, June 2006. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + + + + + + +Woolf & Conrad Informational [Page 6] + +RFC 4892 Serverid June 2007 + + +Authors' Addresses + + Suzanne Woolf + Internet Systems Consortium, Inc. + 950 Charter Street + Redwood City, CA 94063 + US + + Phone: +1 650 423-1333 + EMail: woolf@isc.org + URI: http://www.isc.org/ + + + David Conrad + ICANN + 4676 Admiralty Way + Marina del Rey, CA 90292 + US + + Phone: +1 310 823 9358 + EMail: david.conrad@icann.org + URI: http://www.iana.org/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woolf & Conrad Informational [Page 7] + +RFC 4892 Serverid June 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Woolf & Conrad Informational [Page 8] + diff --git a/doc/rfc/rfc4955.txt b/doc/rfc/rfc4955.txt new file mode 100644 index 000000000000..2d2eb84e0fb8 --- /dev/null +++ b/doc/rfc/rfc4955.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group D. Blacka +Request for Comments: 4955 VeriSign, Inc. +Category: Standards Track July 2007 + + + DNS Security (DNSSEC) Experiments + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document describes a methodology for deploying alternate, non- + backwards-compatible, DNS Security (DNSSEC) methodologies in an + experimental fashion without disrupting the deployment of standard + DNSSEC. + +Table of Contents + + 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2 + 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4 + 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 + + + + + + + + + + + + +Blacka Standards Track [Page 1] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + +1. Overview + + Historically, experimentation with DNSSEC alternatives has been a + problematic endeavor. There has typically been a desire to both + introduce non-backwards-compatible changes to DNSSEC and to try these + changes on real zones in the public DNS. This creates a problem when + the change to DNSSEC would make all or part of the zone using those + changes appear bogus (bad) or otherwise broken to existing security- + aware resolvers. + + This document describes a standard methodology for setting up DNSSEC + experiments. This methodology addresses the issue of coexistence + with standard DNSSEC and DNS by using unknown algorithm identifiers + to hide the experimental DNSSEC protocol modifications from standard + security-aware resolvers. + +2. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and + RFC 4035 [4]) is assumed. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +3. Experiments + + When discussing DNSSEC experiments, it is necessary to classify these + experiments into two broad categories: + + Backwards-Compatible: describes experimental changes that, while not + strictly adhering to the DNSSEC standard, are nonetheless + interoperable with clients and servers that do implement the + DNSSEC standard. + + Non-Backwards-Compatible: describes experiments that would cause a + standard security-aware resolver to (incorrectly) determine that + all or part of a zone is bogus, or to otherwise not interoperate + with standard DNSSEC clients and servers. + + Not included in these terms are experiments with the core DNS + protocol itself. + + The methodology described in this document is not necessary for + backwards-compatible experiments, although it certainly may be used + if desired. + + + + +Blacka Standards Track [Page 2] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + +4. Method + + The core of the methodology is the use of strictly unknown algorithm + identifiers when signing the experimental zone, and more importantly, + having only unknown algorithm identifiers in the DS records for the + delegation to the zone at the parent. + + This technique works because of the way DNSSEC-compliant validators + are expected to work in the presence of a DS set with only unknown + algorithm identifiers. From RFC 4035 [4], Section 5.2: + + If the validator does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + And further: + + If the resolver does not support any of the algorithms listed in + an authenticated DS RRset, then the resolver will not be able to + verify the authentication path to the child zone. In this case, + the resolver SHOULD treat the child zone as if it were unsigned. + + Although this behavior isn't strictly mandatory (as marked by MUST), + it is unlikely for a validator to implement a substantially different + behavior. Essentially, if the validator does not have a usable chain + of trust to a child zone, then it can only do one of two things: + treat responses from the zone as insecure (the recommended behavior), + or treat the responses as bogus. If the validator chooses the + latter, this will both violate the expectation of the zone owner and + defeat the purpose of the above rule. However, with local policy, it + is within the right of a validator to refuse to trust certain zones + based on any criteria, including the use of unknown signing + algorithms. + + Because we are talking about experiments, it is RECOMMENDED that + private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1. + Note that secure handling of private algorithms requires special + handing by the validator logic. See "Clarifications and + Implementation Notes for DNSSECbis" [6] for further details.) + Normally, instead of actually inventing new signing algorithms, the + recommended path is to create alternate algorithm identifiers that + are aliases for the existing, known algorithms. While, strictly + speaking, it is only necessary to create an alternate identifier for + the mandatory algorithms, it is suggested that all optional defined + algorithms be aliased as well. + + + +Blacka Standards Track [Page 3] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + + It is RECOMMENDED that for a particular DNSSEC experiment, a + particular domain name base is chosen for all new algorithms, then + the algorithm number (or name) is prepended to it. For example, for + experiment A, the base name of "dnssec-experiment-a.example.com" is + chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are + defined to be "3.dnssec-experiment-a.example.com" and + "5.dnssec-experiment-a.example.com". However, any unique identifier + will suffice. + + Using this method, resolvers (or, more specifically, DNSSEC + validators) essentially indicate their ability to understand the + DNSSEC experiment's semantics by understanding what the new algorithm + identifiers signify. + + This method creates two classes of security-aware servers and + resolvers: servers and resolvers that are aware of the experiment + (and thus recognize the experiment's algorithm identifiers and + experimental semantics), and servers and resolvers that are unaware + of the experiment. + + This method also precludes any zone from being both in an experiment + and in a classic DNSSEC island of security. That is, a zone is + either in an experiment and only possible to validate experimentally, + or it is not. + +5. Defining an Experiment + + The DNSSEC experiment MUST define the particular set of (previously + unknown) algorithm identifiers that identify the experiment and + define what each unknown algorithm identifier means. Typically, + unless the experiment is actually experimenting with a new DNSSEC + algorithm, this will be a mapping of private algorithm identifiers to + existing, known algorithms. + + Normally the experiment will choose a DNS name as the algorithm + identifier base. This DNS name SHOULD be under the control of the + authors of the experiment. Then the experiment will define a mapping + between known mandatory and optional algorithms into this private + algorithm identifier space. Alternately, the experiment MAY use the + Object Identifier (OID) private algorithm space instead (using + algorithm number 254), or MAY choose non-private algorithm numbers, + although this would require an IANA allocation. + + For example, an experiment might specify in its description the DNS + name "dnssec-experiment-a.example.com" as the base name, and declare + that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC + algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an + alias of DNSSEC algorithm 5 (RSASHA1). + + + +Blacka Standards Track [Page 4] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + + Resolvers MUST only recognize the experiment's semantics when present + in a zone signed by one or more of these algorithm identifiers. This + is necessary to isolate the semantics of one experiment from any + others that the resolver might understand. + + In general, resolvers involved in the experiment are expected to + understand both standard DNSSEC and the defined experimental DNSSEC + protocol, although this isn't required. + +6. Considerations + + There are a number of considerations with using this methodology. + + 1. If an unaware validator does not correctly follow the rules laid + out in RFC 4035 (e.g., the validator interprets a DNSSEC record + prior to validating it), or if the experiment is broader in scope + that just modifying the DNSSEC semantics, the experiment may not + be sufficiently masked by this technique. This may cause + unintended resolution failures. + + 2. It will not be possible for security-aware resolvers unaware of + the experiment to build a chain of trust through an experimental + zone. + +7. Use in Non-Experiments + + This general methodology MAY be used for non-backwards compatible + DNSSEC protocol changes that start out as or become standards. In + this case: + + o The protocol change SHOULD use public IANA allocated algorithm + identifiers instead of private algorithm identifiers. This will + help identify the protocol change as a standard, rather than an + experiment. + + o Resolvers MAY recognize the protocol change in zones not signed + (or not solely signed) using the new algorithm identifiers. + +8. Security Considerations + + Zones using this methodology will be considered insecure by all + resolvers except those aware of the experiment. It is not generally + possible to create a secure delegation from an experimental zone that + will be followed by resolvers unaware of the experiment. + + Implementers should take into account any security issues that may + result from environments being configured to trust both experimental + and non-experimental zones. If the experimental zone is more + + + +Blacka Standards Track [Page 5] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + + vulnerable to attacks, it could, for example, be used to promote + trust in zones not part of the experiment, possibly under the control + of an attacker. + +9. References + +9.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + +9.2. Informative References + + [5] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [6] Weiler, S. and R. Austein, "Clarifications and Implementation + Notes for DNSSECbis", Work in Progress, March 2007. + +Author's Address + + David Blacka + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + +Blacka Standards Track [Page 6] + +RFC 4955 DNS Security (DNSSEC) Experiments July 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Blacka Standards Track [Page 7] + diff --git a/doc/rfc/rfc4956.txt b/doc/rfc/rfc4956.txt new file mode 100644 index 000000000000..536c680cbafc --- /dev/null +++ b/doc/rfc/rfc4956.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4956 Nominet +Category: Experimental M. Kosters + D. Blacka + VeriSign, Inc. + July 2007 + + + DNS Security (DNSSEC) Opt-In + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + In the DNS security (DNSSEC) extensions, delegations to unsigned + subzones are cryptographically secured. Maintaining this + cryptography is not always practical or necessary. This document + describes an experimental "Opt-In" model that allows administrators + to omit this cryptography and manage the cost of adopting DNSSEC with + large zones. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Experimental [Page 1] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + +Table of Contents + + 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 + 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4 + 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Server Considerations . . . . . . . . . . . . . . . . . . 6 + 4.1.1. Delegations Only . . . . . . . . . . . . . . . . . . . 6 + 4.1.2. Insecure Delegation Responses . . . . . . . . . . . . 6 + 4.1.3. Dynamic Update . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Client Considerations . . . . . . . . . . . . . . . . . . 7 + 4.2.1. Delegations Only . . . . . . . . . . . . . . . . . . . 7 + 4.2.2. Validation Process Changes . . . . . . . . . . . . . . 7 + 4.2.3. NSEC Record Caching . . . . . . . . . . . . . . . . . 8 + 4.2.4. Use of the AD bit . . . . . . . . . . . . . . . . . . 8 + 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 + Appendix A. Implementing Opt-In Using "Views" . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Experimental [Page 2] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + +1. Overview + + The cost to cryptographically secure delegations to unsigned zones is + high for large delegation-centric zones and zones where insecure + delegations will be updated rapidly. For these zones, the costs of + maintaining the NextSECure (NSEC) record chain may be extremely high + relative to the gain of cryptographically authenticating existence of + unsecured zones. + + This document describes an experimental method of eliminating the + superfluous cryptography present in secure delegations to unsigned + zones. Using "Opt-In", a zone administrator can choose to remove + insecure delegations from the NSEC chain. This is accomplished by + extending the semantics of the NSEC record by using a redundant bit + in the type map. + +2. Definitions and Terminology + + Throughout this document, familiarity with the DNS system (RFC 1035 + [1]), DNS security extensions ([4], [5], and [6], referred to in this + document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090 + [10]) is assumed. + + The following abbreviations and terms are used in this document: + + RR: is used to refer to a DNS resource record. + + RRset: refers to a Resource Record Set, as defined by [8]. In this + document, the RRset is also defined to include the covering RRSIG + records, if any exist. + + signed name: refers to a DNS name that has, at minimum, a (signed) + NSEC record. + + unsigned name: refers to a DNS name that does not (at least) have an + NSEC record. + + covering NSEC record/RRset: is the NSEC record used to prove + (non)existence of a particular name or RRset. This means that for + a RRset or name 'N', the covering NSEC record has the name 'N', or + has an owner name less than 'N' and "next" name greater than 'N'. + + delegation: refers to an NS RRset with a name different from the + current zone apex (non-zone-apex), signifying a delegation to a + subzone. + + + + + + +Arends, et al. Experimental [Page 3] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + secure delegation: refers to a signed name containing a delegation + (NS RRset), and a signed DS RRset, signifying a delegation to a + signed subzone. + + insecure delegation: refers to a signed name containing a delegation + (NS RRset), but lacking a DS RRset, signifying a delegation to an + unsigned subzone. + + Opt-In insecure delegation: refers to an unsigned name containing + only a delegation NS RRset. The covering NSEC record uses the + Opt-In methodology described in this document. + + The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [2]. + +3. Experimental Status + + This document describes an EXPERIMENTAL extension to DNSSEC. It + interoperates with non-experimental DNSSEC using the technique + described in [7]. This experiment is identified with the following + private algorithms (using algorithm 253): + + "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA, + and + + "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5, + RSASHA1. + + Servers wishing to sign and serve zones that utilize Opt-In MUST sign + the zone with only one or more of these private algorithms and MUST + NOT use any other algorithms. + + Resolvers MUST NOT apply the Opt-In validation rules described in + this document unless a zone is signed using one or more of these + private algorithms. + + This experimental protocol relaxes the restriction that validators + MUST ignore the setting of the NSEC bit in the type map as specified + in RFC 4035 [6] Section 5.4. + + The remainder of this document assumes that the servers and resolvers + involved are aware of and are involved in this experiment. + + + + + + + + +Arends, et al. Experimental [Page 4] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + +4. Protocol Additions + + In DNSSEC, delegation NS RRsets are not signed, but are instead + accompanied by an NSEC RRset of the same name and (possibly) a DS + record. The security status of the subzone is determined by the + presence or absence of the DS RRset, cryptographically proven by the + NSEC record. Opt-In expands this definition by allowing insecure + delegations to exist within an otherwise signed zone without the + corresponding NSEC record at the delegation's owner name. These + insecure delegations are proven insecure by using a covering NSEC + record. + + Since this represents a change of the interpretation of NSEC records, + resolvers must be able to distinguish between RFC standard DNSSEC + NSEC records and Opt-In NSEC records. This is accomplished by + "tagging" the NSEC records that cover (or potentially cover) insecure + delegation nodes. This tag is indicated by the absence of the NSEC + bit in the type map. Since the NSEC bit in the type map merely + indicates the existence of the record itself, this bit is redundant + and safe for use as a tag. + + An Opt-In tagged NSEC record does not assert the (non)existence of + the delegations that it covers (except for a delegation with the same + name). This allows for the addition or removal of these delegations + without recalculating or resigning records in the NSEC chain. + However, Opt-In tagged NSEC records do assert the (non)existence of + other RRsets. + + An Opt-In NSEC record MAY have the same name as an insecure + delegation. In this case, the delegation is proven insecure by the + lack of a DS bit in the type map, and the signed NSEC record does + assert the existence of the delegation. + + Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC + records and standard DNSSEC NSEC records. If an NSEC record is not + Opt-In, there MUST NOT be any insecure delegations (or any other + records) between it and the RRsets indicated by the 'next domain + name' in the NSEC RDATA. If it is Opt-In, there MUST only be + insecure delegations between it and the next node indicated by the + 'next domain name' in the NSEC RDATA. + + In summary, + + o An Opt-In NSEC type is identified by a zero-valued (or not- + specified) NSEC bit in the type bit map of the NSEC record. + + + + + + +Arends, et al. Experimental [Page 5] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + o A standard DNSSEC NSEC type is identified by a one-valued NSEC bit + in the type bit map of the NSEC record. + + and + + o An Opt-In NSEC record does not assert the non-existence of a name + between its owner name and "next" name, although it does assert + that any name in this span MUST be an insecure delegation. + + o An Opt-In NSEC record does assert the (non)existence of RRsets + with the same owner name. + +4.1. Server Considerations + + Opt-In imposes some new requirements on authoritative DNS servers. + +4.1.1. Delegations Only + + This specification dictates that only insecure delegations may exist + between the owner and "next" names of an Opt-In tagged NSEC record. + Signing tools MUST NOT generate signed zones that violate this + restriction. Servers MUST refuse to load and/or serve zones that + violate this restriction. Servers also MUST reject AXFR or IXFR + responses that violate this restriction. + +4.1.2. Insecure Delegation Responses + + When returning an Opt-In insecure delegation, the server MUST return + the covering NSEC RRset in the Authority section. + + In standard DNSSEC, NSEC records already must be returned along with + the insecure delegation. The primary difference that this proposal + introduces is that the Opt-In tagged NSEC record will have a + different owner name from the delegation RRset. This may require + implementations to search for the covering NSEC RRset. + +4.1.3. Dynamic Update + + Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In + particular, it introduces the need for rules that describe when to + add or remove a delegation name from the NSEC chain. This document + does not attempt to define these rules. Until these rules are + defined, servers MUST NOT process DNS Dynamic Update requests against + zones that use Opt-In NSEC records. Servers SHOULD return responses + to update requests with RCODE=REFUSED. + + + + + + +Arends, et al. Experimental [Page 6] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + +4.2. Client Considerations + + Opt-In imposes some new requirements on security-aware resolvers + (caching or otherwise). + +4.2.1. Delegations Only + + As stated in Section 4.1 above, this specification restricts the + namespace covered by Opt-In tagged NSEC records to insecure + delegations only. Clients are not expected to take any special + measures to enforce this restriction; instead, it forms an underlying + assumption that clients may rely on. + +4.2.2. Validation Process Changes + + This specification does not change the resolver's resolution + algorithm. However, it does change the DNSSEC validation process. + +4.2.2.1. Referrals + + Resolvers MUST be able to use Opt-In tagged NSEC records to + cryptographically prove the validity and security status (as + insecure) of a referral. Resolvers determine the security status of + the referred-to zone as follows: + + o In standard DNSSEC, the security status is proven by the existence + or absence of a DS RRset at the same name as the delegation. The + existence of the DS RRset indicates that the referred-to zone is + signed. The absence of the DS RRset is proven using a verified + NSEC record of the same name that does not have the DS bit set in + the type map. This NSEC record MAY also be tagged as Opt-In. + + o Using Opt-In, the security status is proven by the existence of a + DS record (for signed) or the presence of a verified Opt-In tagged + NSEC record that covers the delegation name. That is, the NSEC + record does not have the NSEC bit set in the type map, and the + delegation name falls between the NSEC's owner and "next" name. + + Using Opt-In does not substantially change the nature of following + referrals within DNSSEC. At every delegation point, the resolver + will have cryptographic proof that the referred-to subzone is signed + or unsigned. + +4.2.2.2. Queries for DS Resource Records + + Since queries for DS records are directed to the parent side of a + zone cut (see [5], Section 5), negative responses to these queries + may be covered by an Opt-In flagged NSEC record. + + + +Arends, et al. Experimental [Page 7] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + Resolvers MUST be able to use Opt-In tagged NSEC records to + cryptographically prove the validity and security status of negative + responses to queries for DS records. In particular, a NOERROR/NODATA + (i.e., RCODE=3, but the answer section is empty) response to a DS + query may be proven by an Opt-In flagged covering NSEC record, rather + than an NSEC record matching the query name. + +4.2.3. NSEC Record Caching + + Caching resolvers MUST be able to retrieve the appropriate covering + Opt-In NSEC record when returning referrals that need them. This + requirement differs from standard DNSSEC in that the covering NSEC + will not have the same owner name as the delegation. Some + implementations may have to use new methods for finding these NSEC + records. + +4.2.4. Use of the AD bit + + The AD bit, as defined by [3] and [6], MUST NOT be set when: + + o sending a Name Error (RCODE=3) response where the covering NSEC is + tagged as Opt-In. + + o sending an Opt-In insecure delegation response, unless the + covering (Opt-In) NSEC record's owner name equals the delegation + name. + + o sending a NOERROR/NODATA response when query type is DS and the + covering NSEC is tagged as Opt-In, unless NSEC record's owner name + matches the query name. + + This rule is based on what the Opt-In NSEC record actually proves: + for names that exist between the Opt-In NSEC record's owner and + "next" names, the Opt-In NSEC record cannot prove the non-existence + or existence of the name. As such, not all data in the response has + been cryptographically verified, so the AD bit cannot be set. + +5. Benefits + + Using Opt-In allows administrators of large and/or changing + delegation-centric zones to minimize the overhead involved in + maintaining the security of the zone. + + Opt-In accomplishes this by eliminating the need for NSEC records for + insecure delegations. This, in a zone with a large number of + delegations to unsigned subzones, can lead to substantial space + savings (both in memory and on disk). Additionally, Opt-In allows + for the addition or removal of insecure delegations without modifying + + + +Arends, et al. Experimental [Page 8] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + the NSEC record chain. Zones that are frequently updating insecure + delegations (e.g., Top-Level Domains (TLDs)) can avoid the + substantial overhead of modifying and resigning the affected NSEC + records. + +6. Example + + Consider the zone EXAMPLE shown below. This is a zone where all of + the NSEC records are tagged as Opt-In. + + Example A: Fully Opt-In Zone. + + EXAMPLE. SOA ... + EXAMPLE. RRSIG SOA ... + EXAMPLE. NS FIRST-SECURE.EXAMPLE. + EXAMPLE. RRSIG NS ... + EXAMPLE. DNSKEY ... + EXAMPLE. RRSIG DNSKEY ... + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. ( + SOA NS RRSIG DNSKEY ) + EXAMPLE. RRSIG NSEC ... + + FIRST-SECURE.EXAMPLE. A ... + FIRST-SECURE.EXAMPLE. RRSIG A ... + FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG + FIRST-SECURE.EXAMPLE. RRSIG NSEC ... + + NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NS.NOT-SECURE.EXAMPLE. A ... + + NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE. + NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG + NOT-SECURE-2.EXAMPLE RRSIG NSEC ... + + SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE. + SECOND-SECURE.EXAMPLE. DS ... + SECOND-SECURE.EXAMPLE. RRSIG DS ... + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE. + NS.UNSIGNED.EXAMPLE. A ... + + + Example A. + + + + + + +Arends, et al. Experimental [Page 9] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + In this example, a query for a signed RRset (e.g., "FIRST- + SECURE.EXAMPLE A") or a secure delegation ("WWW.SECOND-SECURE.EXAMPLE + A") will result in a standard DNSSEC response. + + A query for a nonexistent RRset will result in a response that + differs from standard DNSSEC by the following: the NSEC record will + be tagged as Opt-In, there may be no NSEC record proving the non- + existence of a matching wildcard record, and the AD bit will not be + set. + + A query for an insecure delegation RRset (or a referral) will return + both the answer (in the Authority section) and the corresponding + Opt-In NSEC record to prove that it is not secure. + + Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A + + + RCODE=NOERROR, AD=0 + + Answer Section: + + Authority Section: + UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE + SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS + SECOND-SECURE.EXAMPLE. RRSIG NSEC ... + + Additional Section: + NS.UNSIGNED.EXAMPLE. A ... + + Example A.1 + + In the Example A.1 zone, the EXAMPLE. node MAY use either style of + NSEC record, because there are no insecure delegations that occur + between it and the next node, FIRST-SECURE.EXAMPLE. In other words, + Example A would still be a valid zone if the NSEC record for EXAMPLE. + was changed to the following RR: + + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS + RRSIG DNSKEY NSEC ) + + However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND- + SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure + delegations in the range they define. (NOT-SECURE.EXAMPLE. and + UNSIGNED.EXAMPLE., respectively). + + NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is + part of the NSEC chain and also covered by an Opt-In tagged NSEC + record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be + + + +Arends, et al. Experimental [Page 10] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + removed from the zone without modifying and resigning the prior NSEC + record. Delegations with names that fall between NOT-SECURE- + 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without + resigning any NSEC records. + +7. Transition Issues + + Opt-In is not backwards compatible with standard DNSSEC and is + considered experimental. Standard DNSSEC-compliant implementations + would not recognize Opt-In tagged NSEC records as different from + standard NSEC records. Because of this, standard DNSSEC + implementations, if they were to validate Opt-In style responses, + would reject all Opt-In insecure delegations within a zone as + invalid. However, by only signing with private algorithms, standard + DNSSEC implementations will treat Opt-In responses as unsigned. + + It should be noted that all elements in the resolution path between + (and including) the validator and the authoritative name server must + be aware of the Opt-In experiment and implement the Opt-In semantics + for successful validation to be possible. In particular, this + includes any caching middleboxes between the validator and + authoritative name server. + +8. Security Considerations + + Opt-In allows for unsigned names, in the form of delegations to + unsigned subzones, to exist within an otherwise signed zone. All + unsigned names are, by definition, insecure, and their validity or + existence cannot be cryptographically proven. + + In general: + + o Records with unsigned names (whether or not existing) suffer from + the same vulnerabilities as records in an unsigned zone. These + vulnerabilities are described in more detail in [12] (note in + particular Sections 2.3, "Name Games" and 2.6, "Authenticated + Denial"). + + o Records with signed names have the same security whether or not + Opt-In is used. + + Note that with or without Opt-In, an insecure delegation may have its + contents undetectably altered by an attacker. Because of this, the + primary difference in security that Opt-In introduces is the loss of + the ability to prove the existence or nonexistence of an insecure + delegation within the span of an Opt-In NSEC record. + + + + + +Arends, et al. Experimental [Page 11] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + In particular, this means that a malicious entity may be able to + insert or delete records with unsigned names. These records are + normally NS records, but this also includes signed wildcard + expansions (while the wildcard record itself is signed, its expanded + name is an unsigned name), which can be undetectably removed or used + to replace an existing unsigned delegation. + + For example, if a resolver received the following response from the + example zone above: + + Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A + + RCODE=NOERROR + + Answer Section: + + Authority Section: + DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED. + EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \ + RRSIG DNSKEY + EXAMPLE. RRSIG NSEC ... + + Additional Section: + + + Attacker has forged a name + + The resolver would have no choice but to believe that the referral to + NS.FORGED. is valid. If a wildcard existed that would have been + expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could + have undetectably removed it and replaced it with the forged + delegation. + + Note that being able to add a delegation is functionally equivalent + to being able to add any record type: an attacker merely has to forge + a delegation to the nameserver under his/her control and place + whatever records are needed at the subzone apex. + + While in particular cases, this issue may not present a significant + security problem, in general it should not be lightly dismissed. + Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly. + In particular, zone signing tools SHOULD NOT default to Opt-In, and + MAY choose not to support Opt-In at all. + + + + + + + + +Arends, et al. Experimental [Page 12] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + +9. Acknowledgments + + The contributions, suggestions, and remarks of the following persons + (in alphabetic order) to this document are acknowledged: + + Mats Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill + Manning, Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, + Brian Wellington. + +10. References + +10.1. Normative References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "DNS Security Introduction and Requirements", RFC 4033, + March 2005. + + [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, + "Protocol Modifications for the DNS Security Extensions", + RFC 4035, March 2005. + + [7] Blacka, D., "DNSSEC Experiments", RFC 4955, July 2007. + +10.2. Informative References + + [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [9] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [10] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + + + + +Arends, et al. Experimental [Page 13] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, + December 2001. + + [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name + System (DNS)", RFC 3833, August 2004. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Experimental [Page 14] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + +Appendix A. Implementing Opt-In Using "Views" + + In many cases, it may be convenient to implement an Opt-In zone by + combining two separately maintained "views" of a zone at request + time. In this context, "view" refers to a particular version of a + zone, not to any specific DNS implementation feature. + + In this scenario, one view is the secure view, the other is the + insecure (or legacy) view. The secure view consists of an entirely + signed zone using Opt-In tagged NSEC records. The insecure view + contains no DNSSEC information. It is helpful, although not + necessary, for the secure view to be a subset (minus DNSSEC records) + of the insecure view. + + In addition, the only RRsets that may solely exist in the insecure + view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and + the zone apex NS RRset) MUST be signed and in the secure view. + + These two views may be combined at request time to provide a virtual, + single Opt-In zone. The following algorithm is used when responding + to each query: + + V_A is the secure view as described above. + + V_B is the insecure view as described above. + + R_A is a response generated from V_A, following standard DNSSEC. + + R_B is a response generated from V_B, following DNS resolution as + per RFC 1035 [1]. + + R_C is the response generated by combining R_A with R_B, as + described below. + + A query is DNSSEC-aware if it either has the DO bit [11] turned on + or is for a DNSSEC-specific record type. + + 1. If V_A is a subset of V_B and the query is not DNSSEC-aware, + generate and return R_B, otherwise + + 2. Generate R_A. + + 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise + + + + + + + + +Arends, et al. Experimental [Page 15] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + + 4. Generate R_B and combine it with R_A to form R_C: + + For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the + records from R_A into R_B, EXCEPT the AUTHORITY section SOA + record, if R_B's RCODE = NOERROR. + + 5. Return R_C. + +Authors' Addresses + + Roy Arends + Nominet + Sandford Gate + Sandy Lane West + Oxford OX4 6LB + UNITED KINGDOM + + Phone: +44 1865 332211 + EMail: roy@nominet.org.uk + + + Mark Kosters + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: mkosters@verisign.com + URI: http://www.verisignlabs.com + + + David Blacka + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + Phone: +1 703 948 3200 + EMail: davidb@verisign.com + URI: http://www.verisignlabs.com + + + + + + + + + + +Arends, et al. Experimental [Page 16] + +RFC 4956 DNS Security (DNSSEC) Opt-In July 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Experimental [Page 17] + diff --git a/doc/rfc/rfc5001.txt b/doc/rfc/rfc5001.txt new file mode 100644 index 000000000000..fe153393694b --- /dev/null +++ b/doc/rfc/rfc5001.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group R. Austein +Request for Comments: 5001 ISC +Category: Standards Track August 2007 + + + DNS Name Server Identifier (NSID) Option + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. While existing ad-hoc + mechanisms allow an operator to send follow-up queries when it is + necessary to debug such a configuration, the only completely reliable + way to obtain the identity of the name server that responded is to + have the name server include this information in the response itself. + This note defines a protocol extension to support this functionality. + + + + + + + + + + + + + + + + + + + + + +Austein Standards Track [Page 1] + +RFC 5001 DNS NSID August 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 3 + 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 3 + 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4 + 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 4 + 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 7 + 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 7 + 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 + +1. Introduction + + With the increased use of DNS anycast, load balancing, and other + mechanisms allowing more than one DNS name server to share a single + IP address, it is sometimes difficult to tell which of a pool of name + servers has answered a particular query. + + Existing ad-hoc mechanisms allow an operator to send follow-up + queries when it is necessary to debug such a configuration, but there + are situations in which this is not a totally satisfactory solution, + since anycast routing may have changed, or the server pool in + question may be behind some kind of extremely dynamic load balancing + hardware. Thus, while these ad-hoc mechanisms are certainly better + than nothing (and have the advantage of already being deployed), a + better solution seems desirable. + + Given that a DNS query is an idempotent operation with no retained + state, it would appear that the only completely reliable way to + obtain the identity of the name server that responded to a particular + query is to have that name server include identifying information in + the response itself. This note defines a protocol enhancement to + achieve this. + + + + + + + + +Austein Standards Track [Page 2] + +RFC 5001 DNS NSID August 2007 + + +1.1. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Protocol + + This note uses an EDNS [RFC2671] option to signal the resolver's + desire for information identifying the name server and to hold the + name server's response, if any. + +2.1. Resolver Behavior + + A resolver signals its desire for information identifying a name + server by sending an empty NSID option (Section 2.3) in an EDNS OPT + pseudo-RR in the query message. + + The resolver MUST NOT include any NSID payload data in the query + message. + + The semantics of an NSID request are not transitive. That is: the + presence of an NSID option in a query is a request that the name + server which receives the query identify itself. If the name server + side of a recursive name server receives an NSID request, the client + is asking the recursive name server to identify itself; if the + resolver side of the recursive name server wishes to receive + identifying information, it is free to add NSID requests in its own + queries, but that is a separate matter. + +2.2. Name Server Behavior + + A name server that understands the NSID option and chooses to honor a + particular NSID request responds by including identifying information + in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR in the + response message. + + The name server MUST ignore any NSID payload data that might be + present in the query message. + + The NSID option is not transitive. A name server MUST NOT send an + NSID option back to a resolver which did not request it. In + particular, while a recursive name server may choose to add an NSID + option when sending a query, this has no effect on the presence or + absence of the NSID option in the recursive name server's response to + the original client. + + + + + +Austein Standards Track [Page 3] + +RFC 5001 DNS NSID August 2007 + + + As stated in Section 2.1, this mechanism is not restricted to + authoritative name servers; the semantics are intended to be equally + applicable to recursive name servers. + +2.3. The NSID Option + + The OPTION-CODE for the NSID option is 3. + + The OPTION-DATA for the NSID option is an opaque byte string, the + semantics of which are deliberately left outside the protocol. See + Section 3.1 for discussion. + +2.4. Presentation Format + + User interfaces MUST read and write the contents of the NSID option + as a sequence of hexadecimal digits, two digits per payload octet. + + The NSID payload is binary data. Any comparison between NSID + payloads MUST be a comparison of the raw binary data. Copy + operations MUST NOT assume that the raw NSID payload is null- + terminated. Any resemblance between raw NSID payload data and any + form of text is purely a convenience, and does not change the + underlying nature of the payload data. + + See Section 3.3 for discussion. + +3. Discussion + + This section discusses certain aspects of the protocol and explains + considerations that led to the chosen design. + +3.1. The NSID Payload + + The syntax and semantics of the content of the NSID option are + deliberately left outside the scope of this specification. + + Choosing the NSID content is a prerogative of the server + administrator. The server administrator might choose to encode the + NSID content in such a way that the server operator (or clients + authorized by the server operator) can decode the NSID content to + obtain more information than other clients can. Alternatively, the + server operator might choose unencoded NSID content that is equally + meaningful to any client. + + This section describes some of the kinds of data that server + administrators might choose to provide as the content of the NSID + option, and explains the reasoning behind specifying a simple opaque + byte string in Section 2.3. + + + +Austein Standards Track [Page 4] + +RFC 5001 DNS NSID August 2007 + + + There are several possibilities for the payload of the NSID option: + + o It could be the "real" name of the specific name server within the + name server pool. + + o It could be the "real" IP address (IPv4 or IPv6) of the name + server within the name server pool. + + o It could be some sort of pseudo-random number generated in a + predictable fashion somehow using the server's IP address or name + as a seed value. + + o It could be some sort of probabilistically unique identifier + initially derived from some sort of random number generator then + preserved across reboots of the name server. + + o It could be some sort of dynamically generated identifier so that + only the name server operator could tell whether or not any two + queries had been answered by the same server. + + o It could be a blob of signed data, with a corresponding key which + might (or might not) be available via DNS lookups. + + o It could be a blob of encrypted data, the key for which could be + restricted to parties with a need to know (in the opinion of the + server operator). + + o It could be an arbitrary string of octets chosen at the discretion + of the name server operator. + + Each of these options has advantages and disadvantages: + + o Using the "real" name is simple, but the name server may not have + a "real" name. + + o Using the "real" address is also simple, and the name server + almost certainly does have at least one non-anycast IP address for + maintenance operations, but the operator of the name server may + not be willing to divulge its non-anycast address. + + o Given that one common reason for using anycast DNS techniques is + an attempt to harden a critical name server against denial of + service attacks, some name server operators are likely to want an + identifier other than the "real" name or "real" address of the + name server instance. + + o Using a hash or pseudo-random number can provide a fixed length + value that the resolver can use to tell two name servers apart + + + +Austein Standards Track [Page 5] + +RFC 5001 DNS NSID August 2007 + + + without necessarily being able to tell where either one of them + "really" is, but makes debugging more difficult if one happens to + be in a friendly open environment. Furthermore, hashing might not + add much value, since a hash based on an IPv4 address still only + involves a 32-bit search space, and DNS names used for servers + that operators might have to debug at 4am tend not to be very + random. + + o Probabilistically unique identifiers have properties similar to + hashed identifiers, but (given a sufficiently good random number + generator) are immune to the search space issues. However, the + strength of this approach is also its weakness: there is no + algorithmic transformation by which even the server operator can + associate name server instances with identifiers while debugging, + which might be annoying. This approach also requires the name + server instance to preserve the probabilistically unique + identifier across reboots, but this does not appear to be a + serious restriction, since authoritative nameservers almost always + have some form of non-volatile storage. In the rare case of a + name server that does not have any way to store such an + identifier, nothing terrible will happen if the name server + generates a new identifier every time it reboots. + + o Using an arbitrary octet string gives name server operators yet + another setting to configure, or mis-configure, or forget to + configure. Having all the nodes in an anycast name server + constellation identify themselves as "My Name Server" would not be + particularly useful. + + o A signed blob is not particularly useful as an NSID payload unless + the signed data is dynamic and includes some kind of replay + protection, such as a timestamp or some kind of data identifying + the requestor. Signed blobs that meet these criteria could + conceivably be useful in some situations but would require + detailed security analysis beyond the scope of this document. + + o A static encrypted blob would not be particularly useful, as it + would be subject to replay attacks and would, in effect, just be a + random number to any party that does not possess the decryption + key. Dynamic encrypted blobs could conceivably be useful in some + situations but, as with signed blobs, dynamic encrypted blobs + would require detailed security analysis beyond the scope of this + document. + + Given all of the issues listed above, there does not appear to be a + single solution that will meet all needs. Section 2.3 therefore + defines the NSID payload to be an opaque byte string and leaves the + choice of payload up to the implementor and name server operator. + + + +Austein Standards Track [Page 6] + +RFC 5001 DNS NSID August 2007 + + + The following guidelines may be useful to implementors and server + operators: + + o Operators for whom divulging the unicast address is an issue could + use the raw binary representation of a probabilistically unique + random number. This should probably be the default implementation + behavior. + + o Operators for whom divulging the unicast address is not an issue + could just use the raw binary representation of a unicast address + for simplicity. This should only be done via an explicit + configuration choice by the operator. + + o Operators who really need or want the ability to set the NSID + payload to an arbitrary value could do so, but this should only be + done via an explicit configuration choice by the operator. + + This approach appears to provide enough information for useful + debugging without unintentionally leaking the maintenance addresses + of anycast name servers to nogoodniks, while also allowing name + server operators who do not find such leakage threatening to provide + more information at their own discretion. + +3.2. NSID Is Not Transitive + + As specified in Section 2.1 and Section 2.2, the NSID option is not + transitive. This is strictly a hop-by-hop mechanism. + + Most of the discussion of name server identification to date has + focused on identifying authoritative name servers, since the best + known cases of anycast name servers are a subset of the name servers + for the root zone. However, given that anycast DNS techniques are + also applicable to recursive name servers, the mechanism may also be + useful with recursive name servers. The hop-by-hop semantics support + this. + + While there might be some utility in having a transitive variant of + this mechanism (so that, for example, a stub resolver could ask a + recursive server to tell it which authoritative name server provided + a particular answer to the recursive name server), the semantics of + such a variant would be more complicated, and are left for future + work. + +3.3. User Interface Issues + + Given the range of possible payload contents described in + Section 3.1, it is not possible to define a single presentation + format for the NSID payload that is efficient, convenient, + + + +Austein Standards Track [Page 7] + +RFC 5001 DNS NSID August 2007 + + + unambiguous, and aesthetically pleasing. In particular, while it is + tempting to use a presentation format that uses some form of textual + strings, attempting to support this would significantly complicate + what's intended to be a very simple debugging mechanism. + + In some cases the content of the NSID payload may be binary data + meaningful only to the name server operator, and may not be + meaningful to the user or application, but the user or application + must be able to capture the entire content anyway in order for it to + be useful. Thus, the presentation format must support arbitrary + binary data. + + In cases where the name server operator derives the NSID payload from + textual data, a textual form such as US-ASCII or UTF-8 strings might + at first glance seem easier for a user to deal with. There are, + however, a number of complex issues involving internationalized text + which, if fully addressed here, would require a set of rules + significantly longer than the rest of this specification. See + [RFC2277] for an overview of some of these issues. + + It is much more important for the NSID payload data to be passed + unambiguously from server administrator to user and back again than + it is for the payload data to be pretty while in transit. In + particular, it's critical that it be straightforward for a user to + cut and paste an exact copy of the NSID payload output by a debugging + tool into other formats such as email messages or web forms without + distortion. Hexadecimal strings, while ugly, are also robust. + +3.4. Truncation + + In some cases, adding the NSID option to a response message may + trigger message truncation. This specification does not change the + rules for DNS message truncation in any way, but implementors will + need to pay attention to this issue. + + Including the NSID option in a response is always optional, so this + specification never requires name servers to truncate response + messages. + + By definition, a resolver that requests NSID responses also supports + EDNS, so a resolver that requests NSID responses can also use the + "sender's UDP payload size" field of the OPT pseudo-RR to signal a + receive buffer size large enough to make truncation unlikely. + +4. IANA Considerations + + IANA has allocated EDNS option code 3 for the NSID option + (Section 2.3). + + + +Austein Standards Track [Page 8] + +RFC 5001 DNS NSID August 2007 + + +5. Security Considerations + + This document describes a channel signaling mechanism intended + primarily for debugging. Channel signaling mechanisms are outside + the scope of DNSSEC, per se. Applications that require integrity + protection for the data being signaled will need to use a channel + security mechanism such as TSIG [RFC2845]. + + Section 3.1 discusses a number of different kinds of information that + a name server operator might choose to provide as the value of the + NSID option. Some of these kinds of information are security + sensitive in some environments. This specification deliberately + leaves the syntax and semantics of the NSID option content up to the + implementation and the name server operator. + + Two of the possible kinds of payload data discussed in Section 3.1 + involve a digital signature and encryption, respectively. While this + specification discusses some of the pitfalls that might lurk for + careless users of these kinds of payload data, full analysis of the + issues that would be involved in these kinds of payload data would + require knowledge of the content to be signed or encrypted, + algorithms to be used, and so forth, which is beyond the scope of + this document. Implementors should seek competent advice before + attempting to use these kinds of NSID payloads. + +6. Acknowledgements + + Thanks to: Joe Abley, Harald Alvestrand, Dean Anderson, Mark Andrews, + Roy Arends, Steve Bellovin, Alex Bligh, Randy Bush, David Conrad, + John Dickinson, Alfred Hoenes, Johan Ihren, Daniel Karrenberg, Peter + Koch, William Leibzon, Ed Lewis, Thomas Narten, Mike Patton, Geoffrey + Sisson, Andrew Sullivan, Mike StJohns, Tom Taylor, Paul Vixie, Sam + Weiler, and Suzanne Woolf, none of whom are responsible for what the + author did with their comments and suggestions. Apologies to anyone + inadvertently omitted from the above list. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + + + + + +Austein Standards Track [Page 9] + +RFC 5001 DNS NSID August 2007 + + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + +7.2. Informative References + + [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and + Languages", RFC 2277, BCP 18, January 1998. + +Author's Address + + Rob Austein + ISC + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Austein Standards Track [Page 10] + +RFC 5001 DNS NSID August 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Austein Standards Track [Page 11] + diff --git a/doc/rfc/rfc5011.txt b/doc/rfc/rfc5011.txt new file mode 100644 index 000000000000..42235e977f89 --- /dev/null +++ b/doc/rfc/rfc5011.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. StJohns +Request for Comments: 5011 Independent +Category: Standards Track September 2007 + + + Automated Updates of DNS Security (DNSSEC) Trust Anchors + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document describes a means for automated, authenticated, and + authorized updating of DNSSEC "trust anchors". The method provides + protection against N-1 key compromises of N keys in the trust point + key set. Based on the trust established by the presence of a current + anchor, other anchors may be added at the same place in the + hierarchy, and, ultimately, supplant the existing anchor(s). + + This mechanism will require changes to resolver management behavior + (but not resolver resolution behavior), and the addition of a single + flag bit to the DNSKEY record. + + + + + + + + + + + + + + + + + + + + + + + + +StJohns Standards Track [Page 1] + +RFC 5011 Trust Anchor Update September 2007 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Compliance Nomenclature ....................................3 + 2. Theory of Operation .............................................3 + 2.1. Revocation .................................................4 + 2.2. Add Hold-Down ..............................................4 + 2.3. Active Refresh .............................................5 + 2.4. Resolver Parameters ........................................6 + 2.4.1. Add Hold-Down Time ..................................6 + 2.4.2. Remove Hold-Down Time ...............................6 + 2.4.3. Minimum Trust Anchors per Trust Point ...............6 + 3. Changes to DNSKEY RDATA Wire Format .............................6 + 4. State Table .....................................................6 + 4.1. Events .....................................................7 + 4.2. States .....................................................7 + 5. Trust Point Deletion ............................................8 + 6. Scenarios - Informative .........................................9 + 6.1. Adding a Trust Anchor ......................................9 + 6.2. Deleting a Trust Anchor ....................................9 + 6.3. Key Roll-Over .............................................10 + 6.4. Active Key Compromised ....................................10 + 6.5. Stand-by Key Compromised ..................................10 + 6.6. Trust Point Deletion ......................................10 + 7. IANA Considerations ............................................11 + 8. Security Considerations ........................................11 + 8.1. Key Ownership vs. Acceptance Policy .......................11 + 8.2. Multiple Key Compromise ...................................12 + 8.3. Dynamic Updates ...........................................12 + 9. Normative References ...........................................12 + 10. Informative References ........................................12 + +1. Introduction + + As part of the reality of fielding DNSSEC (Domain Name System + Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has + come to the realization that there will not be one signed name space, + but rather islands of signed name spaces each originating from + specific points (i.e., 'trust points') in the DNS tree. Each of + those islands will be identified by the trust point name, and + validated by at least one associated public key. For the purpose of + this document, we'll call the association of that name and a + particular key a 'trust anchor'. A particular trust point can have + more than one key designated as a trust anchor. + + For a DNSSEC-aware resolver to validate information in a DNSSEC + protected branch of the hierarchy, it must have knowledge of a trust + anchor applicable to that branch. It may also have more than one + + + +StJohns Standards Track [Page 2] + +RFC 5011 Trust Anchor Update September 2007 + + + trust anchor for any given trust point. Under current rules, a chain + of trust for DNSSEC-protected data that chains its way back to ANY + known trust anchor is considered 'secure'. + + Because of the probable balkanization of the DNSSEC tree due to + signing voids at key locations, a resolver may need to know literally + thousands of trust anchors to perform its duties (e.g., consider an + unsigned ".COM"). Requiring the owner of the resolver to manually + manage these many relationships is problematic. It's even more + problematic when considering the eventual requirement for key + replacement/update for a given trust anchor. The mechanism described + herein won't help with the initial configuration of the trust anchors + in the resolvers, but should make trust point key + replacement/rollover more viable. + + As mentioned above, this document describes a mechanism whereby a + resolver can update the trust anchors for a given trust point, mainly + without human intervention at the resolver. There are some corner + cases discussed (e.g., multiple key compromise) that may require + manual intervention, but they should be few and far between. This + document DOES NOT discuss the general problem of the initial + configuration of trust anchors for the resolver. + +1.1. Compliance Nomenclature + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, [RFC2119]. + +2. Theory of Operation + + The general concept of this mechanism is that existing trust anchors + can be used to authenticate new trust anchors at the same point in + the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a + DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section + 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is + validated by an existing trust anchor, then the resolver can add the + new key to its set of valid trust anchors for that trust point. + + There are some issues with this approach that need to be mitigated. + For example, a compromise of one of the existing keys could allow an + attacker to add their own 'valid' data. This implies a need for a + method to revoke an existing key regardless of whether or not that + key is compromised. As another example, assuming a single key + compromise, we need to prevent an attacker from adding a new key and + revoking all the other old keys. + + + + + +StJohns Standards Track [Page 3] + +RFC 5011 Trust Anchor Update September 2007 + + +2.1. Revocation + + Assume two trust anchor keys A and B. Assume that B has been + compromised. Without a specific revocation bit, B could invalidate A + simply by sending out a signed trust point key set that didn't + contain A. To fix this, we add a mechanism that requires knowledge + of the private key of a DNSKEY to revoke that DNSKEY. + + A key is considered revoked when the resolver sees the key in a + self-signed RRSet and the key has the REVOKE bit (see Section 7 + below) set to '1'. Once the resolver sees the REVOKE bit, it MUST + NOT use this key as a trust anchor or for any other purpose except to + validate the RRSIG it signed over the DNSKEY RRSet specifically for + the purpose of validating the revocation. Unlike the 'Add' operation + below, revocation is immediate and permanent upon receipt of a valid + revocation at the resolver. + + A self-signed RRSet is a DNSKEY RRSet that contains the specific + DNSKEY and for which there is a corresponding validated RRSIG record. + It's not a special DNSKEY RRSet, just a way of describing the + validation requirements for that RRSet. + + N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint + than one without the bit set. This affects the matching of a DNSKEY + to DS records in the parent [RFC3755], or the fingerprint stored at a + resolver used to configure a trust point. + + In the given example, the attacker could revoke B because it has + knowledge of B's private key, but could not revoke A. + +2.2. Add Hold-Down + + Assume two trust point keys A and B. Assume that B has been + compromised. An attacker could generate and add a new trust anchor + key C (by adding C to the DNSKEY RRSet and signing it with B), and + then invalidate the compromised key. This would result in both the + attacker and owner being able to sign data in the zone and have it + accepted as valid by resolvers. + + To mitigate but not completely solve this problem, we add a hold-down + time to the addition of the trust anchor. When the resolver sees a + new SEP key in a validated trust point DNSKEY RRSet, the resolver + starts an acceptance timer, and remembers all the keys that validated + the RRSet. If the resolver ever sees the DNSKEY RRSet without the + new key but validly signed, it stops the acceptance process for that + key and resets the acceptance timer. If all of the keys that were + + + + + +StJohns Standards Track [Page 4] + +RFC 5011 Trust Anchor Update September 2007 + + + originally used to validate this key are revoked prior to the timer + expiring, the resolver stops the acceptance process and resets the + timer. + + Once the timer expires, the new key will be added as a trust anchor + the next time the validated RRSet with the new key is seen at the + resolver. The resolver MUST NOT treat the new key as a trust anchor + until the hold-down time expires AND it has retrieved and validated a + DNSKEY RRSet after the hold-down time that contains the new key. + + N.B.: Once the resolver has accepted a key as a trust anchor, the key + MUST be considered a valid trust anchor by that resolver until + explicitly revoked as described above. + + In the given example, the zone owner can recover from a compromise by + revoking B and adding a new key D and signing the DNSKEY RRSet with + both A and B. + + The reason this does not completely solve the problem has to do with + the distributed nature of DNS. The resolver only knows what it sees. + A determined attacker who holds one compromised key could keep a + single resolver from realizing that the key had been compromised by + intercepting 'real' data from the originating zone and substituting + their own (e.g., using the example, signed only by B). This is no + worse than the current situation assuming a compromised key. + +2.3. Active Refresh + + A resolver that has been configured for an automatic update of keys + from a particular trust point MUST query that trust point (e.g., do a + lookup for the DNSKEY RRSet and related RRSIG records) no less often + than the lesser of 15 days, half the original TTL for the DNSKEY + RRSet, or half the RRSIG expiration interval and no more often than + once per hour. The expiration interval is the amount of time from + when the RRSIG was last retrieved until the expiration time in the + RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL, + 1/2*RRSigExpirationInterval)) + + If the query fails, the resolver MUST repeat the query until + satisfied no more often than once an hour and no less often than the + lesser of 1 day, 10% of the original TTL, or 10% of the original + expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day, + .1 * origTTL, .1 * expireInterval)). + + + + + + + + +StJohns Standards Track [Page 5] + +RFC 5011 Trust Anchor Update September 2007 + + +2.4. Resolver Parameters + +2.4.1. Add Hold-Down Time + + The add hold-down time is 30 days or the expiration time of the + original TTL of the first trust point DNSKEY RRSet that contained the + new key, whichever is greater. This ensures that at least two + validated DNSKEY RRSets that contain the new key MUST be seen by the + resolver prior to the key's acceptance. + +2.4.2. Remove Hold-Down Time + + The remove hold-down time is 30 days. This parameter is solely a key + management database bookeeping parameter. Failure to remove + information about the state of defunct keys from the database will + not adversely impact the security of this protocol, but may end up + with a database cluttered with obsolete key information. + +2.4.3. Minimum Trust Anchors per Trust Point + + A compliant resolver MUST be able to manage at least five SEP keys + per trust point. + +3. Changes to DNSKEY RDATA Wire Format + + Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag. + If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) + signed by the associated key, then the resolver MUST consider this + key permanently invalid for all purposes except for validating the + revocation. + +4. State Table + + The most important thing to understand is the resolver's view of any + key at a trust point. The following state table describes this view + at various points in the key's lifetime. The table is a normative + part of this specification. The initial state of the key is 'Start'. + The resolver's view of the state of the key changes as various events + occur. + + This is the state of a trust-point key as seen from the resolver. + The column on the left indicates the current state. The header at + the top shows the next state. The intersection of the two shows the + event that will cause the state to transition from the current state + to the next. + + + + + + +StJohns Standards Track [Page 6] + +RFC 5011 Trust Anchor Update September 2007 + + + NEXT STATE + -------------------------------------------------- + FROM |Start |AddPend |Valid |Missing|Revoked|Removed| + ---------------------------------------------------------- + Start | |NewKey | | | | | + ---------------------------------------------------------- + AddPend |KeyRem | |AddTime| | | | + ---------------------------------------------------------- + Valid | | | |KeyRem |Revbit | | + ---------------------------------------------------------- + Missing | | |KeyPres| |Revbit | | + ---------------------------------------------------------- + Revoked | | | | | |RemTime| + ---------------------------------------------------------- + Removed | | | | | | | + ---------------------------------------------------------- + + State Table + +4.1. Events + + NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. + That key will become a new trust anchor for the named trust + point after it's been present in the RRSet for at least 'add + time'. + + KeyPres The key has returned to the valid DNSKEY RRSet. + + KeyRem The resolver sees a valid DNSKEY RRSet that does not contain + this key. + + AddTime The key has been in every valid DNSKEY RRSet seen for at + least the 'add time'. + + RemTime A revoked key has been missing from the trust-point DNSKEY + RRSet for sufficient time to be removed from the trust set. + + RevBit The key has appeared in the trust anchor DNSKEY RRSet with + its "REVOKED" bit set, and there is an RRSig over the DNSKEY + RRSet signed by this key. + +4.2. States + + Start The key doesn't yet exist as a trust anchor at the resolver. + It may or may not exist at the zone server, but either + hasn't yet been seen at the resolver or was seen but was + absent from the last DNSKEY RRSet (e.g., KeyRem event). + + + + +StJohns Standards Track [Page 7] + +RFC 5011 Trust Anchor Update September 2007 + + + AddPend The key has been seen at the resolver, has its 'SEP' bit + set, and has been included in a validated DNSKEY RRSet. + There is a hold-down time for the key before it can be used + as a trust anchor. + + Valid The key has been seen at the resolver and has been included + in all validated DNSKEY RRSets from the time it was first + seen through the hold-down time. It is now valid for + verifying RRSets that arrive after the hold-down time. + Clarification: The DNSKEY RRSet does not need to be + continuously present at the resolver (e.g., its TTL might + expire). If the RRSet is seen and is validated (i.e., + verifies against an existing trust anchor), this key MUST be + in the RRSet, otherwise a 'KeyRem' event is triggered. + + Missing This is an abnormal state. The key remains a valid trust- + point key, but was not seen at the resolver in the last + validated DNSKEY RRSet. This is an abnormal state because + the zone operator should be using the REVOKE bit prior to + removal. + + Revoked This is the state a key moves to once the resolver sees an + RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet + contains this key with its REVOKE bit set to '1'. Once in + this state, this key MUST permanently be considered invalid + as a trust anchor. + + Removed After a fairly long hold-down time, information about this + key may be purged from the resolver. A key in the removed + state MUST NOT be considered a valid trust anchor. (Note: + this state is more or less equivalent to the "Start" state, + except that it's bad practice to re-introduce previously + used keys -- think of this as the holding state for all the + old keys for which the resolver no longer needs to track + state.) + +5. Trust Point Deletion + + A trust point that has all of its trust anchors revoked is considered + deleted and is treated as if the trust point was never configured. + If there are no superior configured trust points, data at and below + the deleted trust point are considered insecure by the resolver. If + there ARE superior configured trust points, data at and below the + deleted trust point are evaluated with respect to the superior trust + point(s). + + Alternately, a trust point that is subordinate to another configured + trust point MAY be deleted by a resolver after 180 days, where such a + + + +StJohns Standards Track [Page 8] + +RFC 5011 Trust Anchor Update September 2007 + + + subordinate trust point validly chains to a superior trust point. + The decision to delete the subordinate trust anchor is a local + configuration decision. Once the subordinate trust point is deleted, + validation of the subordinate zone is dependent on validating the + chain of trust to the superior trust point. + +6. Scenarios - Informative + + The suggested model for operation is to have one active key and one + stand-by key at each trust point. The active key will be used to + sign the DNSKEY RRSet. The stand-by key will not normally sign this + RRSet, but the resolver will accept it as a trust anchor if/when it + sees the signature on the trust point DNSKEY RRSet. + + Since the stand-by key is not in active signing use, the associated + private key may (and should) be provided with additional protections + not normally available to a key that must be used frequently (e.g., + locked in a safe, split among many parties, etc). Notionally, the + stand-by key should be less subject to compromise than an active key, + but that will be dependent on operational concerns not addressed + here. + +6.1. Adding a Trust Anchor + + Assume an existing trust anchor key 'A'. + + 1. Generate a new key pair. + + 2. Create a DNSKEY record from the key pair and set the SEP and Zone + Key bits. + + 3. Add the DNSKEY to the RRSet. + + 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - + 'A'. + + 5. Wait for various resolvers' timers to go off and for them to + retrieve the new DNSKEY RRSet and signatures. + + 6. The new trust anchor will be populated at the resolvers on the + schedule described by the state table and update algorithm -- see + Sections 2 and 4 above. + +6.2. Deleting a Trust Anchor + + Assume existing trust anchors 'A' and 'B' and that you want to revoke + and delete 'A'. + + + + +StJohns Standards Track [Page 9] + +RFC 5011 Trust Anchor Update September 2007 + + + 1. Set the revocation bit on key 'A'. + + 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked. + The operator should include the revoked 'A' in the RRSet for at + least the remove hold-down time, but then may remove it from the + DNSKEY RRSet. + +6.3. Key Roll-Over + + Assume existing keys A and B. 'A' is actively in use (i.e. has been + signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been + in the DNSKEY RRSet and is a valid trust anchor, but wasn't being + used to sign the RRSet). + + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'A'. + 4. Sign the RRSet with 'A' and 'B'. + + 'A' is now revoked, 'B' is now the active key, and 'C' will be the + stand-by key once the hold-down expires. The operator should include + the revoked 'A' in the RRSet for at least the remove hold-down time, + but may then remove it from the DNSKEY RRSet. + +6.4. Active Key Compromised + + This is the same as the mechanism for Key Roll-Over (Section 6.3) + above, assuming 'A' is the active key. + +6.5. Stand-by Key Compromised + + Using the same assumptions and naming conventions as Key Roll-Over + (Section 6.3) above: + + 1. Generate a new key pair 'C'. + 2. Add 'C' to the DNSKEY RRSet. + 3. Set the revocation bit on key 'B'. + 4. Sign the RRSet with 'A' and 'B'. + + 'B' is now revoked, 'A' remains the active key, and 'C' will be the + stand-by key once the hold-down expires. 'B' should continue to be + included in the RRSet for the remove hold-down time. + +6.6. Trust Point Deletion + + To delete a trust point that is subordinate to another configured + trust point (e.g., example.com to .com) requires some juggling of the + data. The specific process is: + + + +StJohns Standards Track [Page 10] + +RFC 5011 Trust Anchor Update September 2007 + + + 1. Generate a new DNSKEY and DS record and provide the DS record to + the parent along with DS records for the old keys. + + 2. Once the parent has published the DSs, add the new DNSKEY to the + RRSet and revoke ALL of the old keys at the same time, while + signing the DNSKEY RRSet with all of the old and new keys. + + 3. After 30 days, stop publishing the old, revoked keys and remove + any corresponding DS records in the parent. + + Revoking the old trust-point keys at the same time as adding new keys + that chain to a superior trust prevents the resolver from adding the + new keys as trust anchors. Adding DS records for the old keys avoids + a race condition where either the subordinate zone becomes unsecure + (because the trust point was deleted) or becomes bogus (because it + didn't chain to the superior zone). + +7. IANA Considerations + + The IANA has assigned a bit in the DNSKEY flags field (see Section 7 + of [RFC4034]) for the REVOKE bit (8). + +8. Security Considerations + + In addition to the following sections, see also Theory of Operation + above (Section 2) and especially Section 2.2 for related discussions. + + Security considerations for trust anchor rollover not specific to + this protocol are discussed in [RFC4986]. + +8.1. Key Ownership vs. Acceptance Policy + + The reader should note that, while the zone owner is responsible for + creating and distributing keys, it's wholly the decision of the + resolver owner as to whether to accept such keys for the + authentication of the zone information. This implies the decision to + update trust-anchor keys based on trusting a current trust-anchor key + is also the resolver owner's decision. + + The resolver owner (and resolver implementers) MAY choose to permit + or prevent key status updates based on this mechanism for specific + trust points. If they choose to prevent the automated updates, they + will need to establish a mechanism for manual or other out-of-band + updates, which are outside the scope of this document. + + + + + + + +StJohns Standards Track [Page 11] + +RFC 5011 Trust Anchor Update September 2007 + + +8.2. Multiple Key Compromise + + This scheme permits recovery as long as at least one valid trust- + anchor key remains uncompromised, e.g., if there are three keys, you + can recover if two of them are compromised. The zone owner should + determine their own level of comfort with respect to the number of + active, valid trust anchors in a zone and should be prepared to + implement recovery procedures once they detect a compromise. A + manual or other out-of-band update of all resolvers will be required + if all trust-anchor keys at a trust point are compromised. + +8.3. Dynamic Updates + + Allowing a resolver to update its trust anchor set based on in-band + key information is potentially less secure than a manual process. + However, given the nature of the DNS, the number of resolvers that + would require update if a trust anchor key were compromised, and the + lack of a standard management framework for DNS, this approach is no + worse than the existing situation. + +9. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer (DS)", RFC 3755, May 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +10. Informative References + + [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, + "Requirements Related to DNS Security (DNSSEC) Trust + Anchor Rollover", RFC 4986, August 2007. + + + + + + +StJohns Standards Track [Page 12] + +RFC 5011 Trust Anchor Update September 2007 + + +Author's Address + + Michael StJohns + Independent + + EMail: mstjohns@comcast.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +StJohns Standards Track [Page 13] + +RFC 5011 Trust Anchor Update September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +StJohns Standards Track [Page 14] + diff --git a/doc/rfc/rfc5205.txt b/doc/rfc/rfc5205.txt new file mode 100644 index 000000000000..4e17b1d960e8 --- /dev/null +++ b/doc/rfc/rfc5205.txt @@ -0,0 +1,955 @@ + + + + + + +Network Working Group P. Nikander +Request for Comments: 5205 Ericsson Research NomadicLab +Category: Experimental J. Laganier + DoCoMo Euro-Labs + April 2008 + + + Host Identity Protocol (HIP) Domain Name System (DNS) Extension + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Abstract + + This document specifies a new resource record (RR) for the Domain + Name System (DNS), and how to use it with the Host Identity Protocol + (HIP). This RR allows a HIP node to store in the DNS its Host + Identity (HI, the public component of the node public-private key + pair), Host Identity Tag (HIT, a truncated hash of its public key), + and the Domain Names of its rendezvous servers (RVSs). + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nikander & Laganier Experimental [Page 1] + +RFC 5205 HIP DNS Extension April 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 + 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Simple Static Singly Homed End-Host . . . . . . . . . . . 5 + 3.2. Mobile end-host . . . . . . . . . . . . . . . . . . . . . 6 + 4. Overview of Using the DNS with HIP . . . . . . . . . . . . . . 8 + 4.1. Storing HI, HIT, and RVS in the DNS . . . . . . . . . . . 8 + 4.2. Initiating Connections Based on DNS Names . . . . . . . . 8 + 5. HIP RR Storage Format . . . . . . . . . . . . . . . . . . . . 9 + 5.1. HIT Length Format . . . . . . . . . . . . . . . . . . . . 9 + 5.2. PK Algorithm Format . . . . . . . . . . . . . . . . . . . 9 + 5.3. PK Length Format . . . . . . . . . . . . . . . . . . . . . 10 + 5.4. HIT Format . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5.5. Public Key Format . . . . . . . . . . . . . . . . . . . . 10 + 5.6. Rendezvous Servers Format . . . . . . . . . . . . . . . . 10 + 6. HIP RR Presentation Format . . . . . . . . . . . . . . . . . . 10 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 8.1. Attacker Tampering with an Insecure HIP RR . . . . . . . . 12 + 8.2. Hash and HITs Collisions . . . . . . . . . . . . . . . . . 13 + 8.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 11.1. Normative references . . . . . . . . . . . . . . . . . . . 14 + 11.2. Informative references . . . . . . . . . . . . . . . . . . 15 + + + + + + + + + + + + + + + + + + + + + + + +Nikander & Laganier Experimental [Page 2] + +RFC 5205 HIP DNS Extension April 2008 + + +1. Introduction + + This document specifies a new resource record (RR) for the Domain + Name System (DNS) [RFC1034], and how to use it with the Host Identity + Protocol (HIP) [RFC5201]. This RR allows a HIP node to store in the + DNS its Host Identity (HI, the public component of the node public- + private key pair), Host Identity Tag (HIT, a truncated hash of its + HI), and the Domain Names of its rendezvous servers (RVSs) [RFC5204]. + + Currently, most of the Internet applications that need to communicate + with a remote host first translate a domain name (often obtained via + user input) into one or more IP address(es). This step occurs prior + to communication with the remote host, and relies on a DNS lookup. + + With HIP, IP addresses are intended to be used mostly for on-the-wire + communication between end hosts, while most Upper Layer Protocols + (ULP) and applications use HIs or HITs instead (ICMP might be an + example of an ULP not using them). Consequently, we need a means to + translate a domain name into an HI. Using the DNS for this + translation is pretty straightforward: We define a new HIP resource + record. Upon query by an application or ULP for a name to IP address + lookup, the resolver would then additionally perform a name to HI + lookup, and use it to construct the resulting HI to IP address + mapping (which is internal to the HIP layer). The HIP layer uses the + HI to IP address mapping to translate HIs and HITs into IP addresses + and vice versa. + + The HIP Rendezvous Extension [RFC5204] allows a HIP node to be + reached via the IP address(es) of a third party, the node's + rendezvous server (RVS). An Initiator willing to establish a HIP + association with a Responder served by an RVS would typically + initiate a HIP exchange by sending an I1 towards the RVS IP address + rather than towards the Responder IP address. Consequently, we need + a means to find the name of a rendezvous server for a given host + name. + + This document introduces the new HIP DNS resource record to store the + Rendezvous Server (RVS), Host Identity (HI), and Host Identity Tag + (HIT) information. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + + + + + +Nikander & Laganier Experimental [Page 3] + +RFC 5205 HIP DNS Extension April 2008 + + +3. Usage Scenarios + + In this section, we briefly introduce a number of usage scenarios + where the DNS is useful with the Host Identity Protocol. + + With HIP, most applications and ULPs are unaware of the IP addresses + used to carry packets on the wire. Consequently, a HIP node could + take advantage of having multiple IP addresses for fail-over, + redundancy, mobility, or renumbering, in a manner that is transparent + to most ULPs and applications (because they are bound to HIs; hence, + they are agnostic to these IP address changes). + + In these situations, for a node to be reachable by reference to its + Fully Qualified Domain Name (FQDN), the following information should + be stored in the DNS: + + o A set of IP address(es) via A [RFC1035] and AAAA [RFC3596] RR sets + (RRSets [RFC2181]). + + o A Host Identity (HI), Host Identity Tag (HIT), and possibly a set + of rendezvous servers (RVS) through HIP RRs. + + When a HIP node wants to initiate communication with another HIP + node, it first needs to perform a HIP base exchange to set up a HIP + association towards its peer. Although such an exchange can be + initiated opportunistically, i.e., without prior knowledge of the + Responder's HI, by doing so both nodes knowingly risk man-in-the- + middle attacks on the HIP exchange. To prevent these attacks, it is + recommended that the Initiator first obtain the HI of the Responder, + and then initiate the exchange. This can be done, for example, + through manual configuration or DNS lookups. Hence, a new HIP RR is + introduced. + + When a HIP node is frequently changing its IP address(es), the + natural DNS latency for propagating changes may prevent it from + publishing its new IP address(es) in the DNS. For solving this + problem, the HIP Architecture [RFC4423] introduces rendezvous servers + (RVSs) [RFC5204]. A HIP host uses a rendezvous server as a + rendezvous point to maintain reachability with possible HIP + initiators while moving [RFC5206]. Such a HIP node would publish in + the DNS its RVS domain name(s) in a HIP RR, while keeping its RVS up- + to-date with its current set of IP addresses. + + When a HIP node wants to initiate a HIP exchange with a Responder, it + will perform a number of DNS lookups. Depending on the type of + implementation, the order in which those lookups will be issued may + vary. For instance, implementations using HIT in APIs may typically + first query for HIP resource records at the Responder FQDN, while + + + +Nikander & Laganier Experimental [Page 4] + +RFC 5205 HIP DNS Extension April 2008 + + + those using an IP address in APIs may typically first query for A + and/or AAAA resource records. + + In the following, we assume that the Initiator first queries for HIP + resource records at the Responder FQDN. + + If the query for the HIP type was responded to with a DNS answer with + RCODE=3 (Name Error), then the Responder's information is not present + in the DNS and further queries for the same owner name SHOULD NOT be + made. + + In case the query for the HIP records returned a DNS answer with + RCODE=0 (No Error) and an empty answer section, it means that no HIP + information is available at the responder name. In such a case, if + the Initiator has been configured with a policy to fallback to + opportunistic HIP (initiating without knowing the Responder's HI) or + plain IP, it would send out more queries for A and AAAA types at the + Responder's FQDN. + + Depending on the combinations of answers, the situations described in + Section 3.1 and Section 3.2 can occur. + + Note that storing HIP RR information in the DNS at an FQDN that is + assigned to a non-HIP node might have ill effects on its reachability + by HIP nodes. + +3.1. Simple Static Singly Homed End-Host + + A HIP node (R) with a single static network attachment, wishing to be + reachable by reference to its FQDN (www.example.com), would store in + the DNS, in addition to its IP address(es) (IP-R), its Host Identity + (HI-R) and Host Identity Tag (HIT-R) in a HIP resource record. + + An Initiator willing to associate with a node would typically issue + the following queries: + + o QNAME=www.example.com, QTYPE=HIP + + o (QCLASS=IN is assumed and omitted from the examples) + + Which returns a DNS packet with RCODE=0 and one or more HIP RRs with + the HIT and HI (e.g., HIT-R and HI-R) of the Responder in the answer + section, but no RVS. + + + + + + + + +Nikander & Laganier Experimental [Page 5] + +RFC 5205 HIP DNS Extension April 2008 + + + o QNAME=www.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA + + Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs + containing IP address(es) of the Responder (e.g., IP-R) in the answer + section. + + Caption: In the remainder of this document, for the sake of keeping + diagrams simple and concise, several DNS queries and answers + are represented as one single transaction, while in fact + there are several queries and answers flowing back and + forth, as described in the textual examples. + + [HIP? A? ] + [www.example.com] +-----+ + +-------------------------------->| | + | | DNS | + | +-------------------------------| | + | | [HIP? A? ] +-----+ + | | [www.example.com] + | | [HIP HIT-R HI-R ] + | | [A IP-R ] + | v + +-----+ +-----+ + | |--------------I1------------->| | + | I |<-------------R1--------------| R | + | |--------------I2------------->| | + | |<-------------R2--------------| | + +-----+ +-----+ + + Static Singly Homed Host + + The Initiator would then send an I1 to the Responder's IP addresses + (IP-R). + +3.2. Mobile end-host + + A mobile HIP node (R) wishing to be reachable by reference to its + FQDN (www.example.com) would store in the DNS, possibly in addition + to its IP address(es) (IP-R), its HI (HI-R), HIT (HIT-R), and the + domain name(s) of its rendezvous server(s) (e.g., rvs.example.com) in + HIP resource record(s). The mobile HIP node also needs to notify its + rendezvous servers of any change in its set of IP address(es). + + An Initiator willing to associate with such a mobile node would + typically issue the following queries: + + o QNAME=www.example.com, QTYPE=HIP + + + + +Nikander & Laganier Experimental [Page 6] + +RFC 5205 HIP DNS Extension April 2008 + + + Which returns a DNS packet with RCODE=0 and one or more HIP RRs with + the HIT, HI, and RVS domain name(s) (e.g., HIT-R, HI-R, and + rvs.example.com) of the Responder in the answer section. + + o QNAME=rvs.example.com, QTYPE=A QNAME=www.example.com, QTYPE=AAAA + + Which returns DNS packets with RCODE=0 and one or more A or AAAA RRs + containing IP address(es) of the Responder's RVS (e.g., IP-RVS) in + the answer section. + + [HIP? ] + [www.example.com] + + [A? ] + [rvs.example.com] +-----+ + +----------------------------------------->| | + | | DNS | + | +----------------------------------------| | + | | [HIP? ] +-----+ + | | [www.example.com ] + | | [HIP HIT-R HI-R rvs.example.com] + | | + | | [A? ] + | | [rvs.example.com] + | | [A IP-RVS ] + | | + | | +-----+ + | | +------I1----->| RVS |-----I1------+ + | | | +-----+ | + | | | | + | | | | + | v | v + +-----+ +-----+ + | |<---------------R1------------| | + | I |----------------I2----------->| R | + | |<---------------R2------------| | + +-----+ +-----+ + + Mobile End-Host + + The Initiator would then send an I1 to the RVS IP address (IP-RVS). + Following, the RVS will relay the I1 up to the mobile node's IP + address (IP-R), which will complete the HIP exchange. + + + + + + + + +Nikander & Laganier Experimental [Page 7] + +RFC 5205 HIP DNS Extension April 2008 + + +4. Overview of Using the DNS with HIP + +4.1. Storing HI, HIT, and RVS in the DNS + + For any HIP node, its Host Identity (HI), the associated Host + Identity Tag (HIT), and the FQDN of its possible RVSs can be stored + in a DNS HIP RR. Any conforming implementation may store a Host + Identity (HI) and its associated Host Identity Tag (HIT) in a DNS HIP + RDATA format. HI and HIT are defined in Section 3 of the HIP + specification [RFC5201]. + + Upon return of a HIP RR, a host MUST always calculate the HI- + derivative HIT to be used in the HIP exchange, as specified in + Section 3 of the HIP specification [RFC5201], while the HIT possibly + embedded along SHOULD only be used as an optimization (e.g., table + lookup). + + The HIP resource record may also contain one or more domain name(s) + of rendezvous server(s) towards which HIP I1 packets might be sent to + trigger the establishment of an association with the entity named by + this resource record [RFC5204]. + + The rendezvous server field of the HIP resource record stored at a + given owner name MAY include the owner name itself. A semantically + equivalent situation occurs if no rendezvous server is present in the + HIP resource record stored at that owner name. Such situations occur + in two cases: + + o The host is mobile, and the A and/or AAAA resource record(s) + stored at its host name contain the IP address(es) of its + rendezvous server rather than its own one. + + o The host is stationary, and can be reached directly at the IP + address(es) contained in the A and/or AAAA resource record(s) + stored at its host name. This is a degenerated case of rendezvous + service where the host somewhat acts as a rendezvous server for + itself. + + An RVS receiving such an I1 would then relay it to the appropriate + Responder (the owner of the I1 receiver HIT). The Responder will + then complete the exchange with the Initiator, typically without + ongoing help from the RVS. + +4.2. Initiating Connections Based on DNS Names + + On a HIP node, a Host Identity Protocol exchange SHOULD be initiated + whenever a ULP attempts to communicate with an entity and the DNS + lookup returns HIP resource records. + + + +Nikander & Laganier Experimental [Page 8] + +RFC 5205 HIP DNS Extension April 2008 + + +5. HIP RR Storage Format + + The RDATA for a HIP RR consists of a public key algorithm type, the + HIT length, a HIT, a public key, and optionally one or more + rendezvous server(s). + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HIT length | PK algorithm | PK length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ HIT ~ + | | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+ + + | Public Key | + ~ ~ + | | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Rendezvous Servers ~ + | | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+ + + The HIT length, PK algorithm, PK length, HIT, and Public Key fields + are REQUIRED. The Rendezvous Servers field is OPTIONAL. + +5.1. HIT Length Format + + The HIT length indicates the length in bytes of the HIT field. This + is an 8-bit unsigned integer. + +5.2. PK Algorithm Format + + The PK algorithm field indicates the public key cryptographic + algorithm and the implied public key field format. This is an 8-bit + unsigned integer. This document reuses the values defined for the + 'algorithm type' of the IPSECKEY RR [RFC4025]. + + Presently defined values are listed in Section 9 for reference. + + + + + +Nikander & Laganier Experimental [Page 9] + +RFC 5205 HIP DNS Extension April 2008 + + +5.3. PK Length Format + + The PK length indicates the length in bytes of the Public key field. + This is a 16-bit unsigned integer in network byte order. + +5.4. HIT Format + + The HIT is stored as a binary value in network byte order. + +5.5. Public Key Format + + Both of the public key types defined in this document (RSA and DSA) + reuse the public key formats defined for the IPSECKEY RR [RFC4025]. + + The DSA key format is defined in RFC 2536 [RFC2536]. + + The RSA key format is defined in RFC 3110 [RFC3110] and the RSA key + size limit (4096 bits) is relaxed in the IPSECKEY RR [RFC4025] + specification. + +5.6. Rendezvous Servers Format + + The Rendezvous Servers field indicates one or more variable length + wire-encoded domain names of rendezvous server(s), as described in + Section 3.3 of RFC 1035 [RFC1035]. The wire-encoded format is self- + describing, so the length is implicit. The domain names MUST NOT be + compressed. The rendezvous server(s) are listed in order of + preference (i.e., first rendezvous server(s) are preferred), defining + an implicit order amongst rendezvous servers of a single RR. When + multiple HIP RRs are present at the same owner name, this implicit + order of rendezvous servers within an RR MUST NOT be used to infer a + preference order between rendezvous servers stored in different RRs. + +6. HIP RR Presentation Format + + This section specifies the representation of the HIP RR in a zone + master file. + + The HIT length field is not represented, as it is implicitly known + thanks to the HIT field representation. + + The PK algorithm field is represented as unsigned integers. + + The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a. + hex or hexadecimal) of the HIT. The encoding MUST NOT contain + whitespaces to distinguish it from the public key field. + + + + + +Nikander & Laganier Experimental [Page 10] + +RFC 5205 HIP DNS Extension April 2008 + + + The Public Key field is represented as the Base64 encoding [RFC4648] + of the public key. The encoding MUST NOT contain whitespace(s) to + distinguish it from the Rendezvous Servers field. + + The PK length field is not represented, as it is implicitly known + thanks to the Public key field representation containing no + whitespaces. + + The Rendezvous Servers field is represented by one or more domain + name(s) separated by whitespace(s). + + The complete representation of the HPIHI record is: + + IN HIP ( pk-algorithm + base16-encoded-hit + base64-encoded-public-key + rendezvous-server[1] + ... + rendezvous-server[n] ) + + When no RVSs are present, the representation of the HPIHI record is: + + IN HIP ( pk-algorithm + base16-encoded-hit + base64-encoded-public-key ) + +7. Examples + + In the examples below, the public key field containing no whitespace + is wrapped since it does not fit in a single line of this document. + + Example of a node with HI and HIT but no RVS: + +www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 + AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p +9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ +b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D ) + + Example of a node with a HI, HIT, and one RVS: + +www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 + AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p +9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ +b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D + rvs.example.com. ) + + + + + + +Nikander & Laganier Experimental [Page 11] + +RFC 5205 HIP DNS Extension April 2008 + + + Example of a node with a HI, HIT, and two RVSs: + +www.example.com. IN HIP ( 2 200100107B1A74DF365639CC39F1D578 + AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p +9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ +b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D + rvs1.example.com. + rvs2.example.com. ) + +8. Security Considerations + + This section contains a description of the known threats involved + with the usage of the HIP DNS Extension. + + In a manner similar to the IPSECKEY RR [RFC4025], the HIP DNS + Extension allows for the provision of two HIP nodes with the public + keying material (HI) of their peer. These HIs will be subsequently + used in a key exchange between the peers. Hence, the HIP DNS + Extension introduces the same kind of threats that IPSECKEY does, + plus threats caused by the possibility given to a HIP node to + initiate or accept a HIP exchange using "opportunistic" or + "unpublished Initiator HI" modes. + + A HIP node SHOULD obtain HIP RRs from a trusted party trough a secure + channel ensuring data integrity and authenticity of the RRs. DNSSEC + [RFC4033] [RFC4034] [RFC4035] provides such a secure channel. + However, it should be emphasized that DNSSEC only offers data + integrity and authenticity guarantees to the channel between the DNS + server publishing a zone and the HIP node. DNSSEC does not ensure + that the entity publishing the zone is trusted. Therefore, the RRSIG + signature of the HIP RRSet MUST NOT be misinterpreted as a + certificate binding the HI and/or the HIT to the owner name. + + In the absence of a proper secure channel, both parties are + vulnerable to MitM and DoS attacks, and unrelated parties might be + subject to DoS attacks as well. These threats are described in the + following sections. + +8.1. Attacker Tampering with an Insecure HIP RR + + The HIP RR contains public keying material in the form of the named + peer's public key (the HI) and its secure hash (the HIT). Both of + these are not sensitive to attacks where an adversary gains knowledge + of them. However, an attacker that is able to mount an active attack + on the DNS, i.e., tampers with this HIP RR (e.g., using DNS + spoofing), is able to mount Man-in-the-Middle attacks on the + cryptographic core of the eventual HIP exchange (Responder's HIP RR + rewritten by the attacker). + + + +Nikander & Laganier Experimental [Page 12] + +RFC 5205 HIP DNS Extension April 2008 + + + The HIP RR may contain a rendezvous server domain name resolved into + a destination IP address where the named peer is reachable by an I1, + as per the HIP Rendezvous Extension [RFC5204]. Thus, an attacker + able to tamper with this RR is able to redirect I1 packets sent to + the named peer to a chosen IP address for DoS or MitM attacks. Note + that this kind of attack is not specific to HIP and exists + independently of whether or not HIP and the HIP RR are used. Such an + attacker might tamper with A and AAAA RRs as well. + + An attacker might obviously use these two attacks in conjunction: It + will replace the Responder's HI and RVS IP address by its own in a + spoofed DNS packet sent to the Initiator HI, then redirect all + exchanged packets to him and mount a MitM on HIP. In this case, HIP + won't provide confidentiality nor Initiator HI protection from + eavesdroppers. + +8.2. Hash and HITs Collisions + + As with many cryptographic algorithms, some secure hashes (e.g., + SHA1, used by HIP to generate a HIT from an HI) eventually become + insecure, because an exploit has been found in which an attacker with + reasonable computation power breaks one of the security features of + the hash (e.g., its supposed collision resistance). This is why a + HIP end-node implementation SHOULD NOT authenticate its HIP peers + based solely on a HIT retrieved from the DNS, but SHOULD rather use + HI-based authentication. + +8.3. DNSSEC + + In the absence of DNSSEC, the HIP RR is subject to the threats + described in RFC 3833 [RFC3833]. + +9. IANA Considerations + + IANA has allocated one new RR type code (55) for the HIP RR from the + standard RR type space. + + IANA does not need to open a new registry for public key algorithms + of the HIP RR because the HIP RR reuses "algorithms types" defined + for the IPSECKEY RR [RFC4025]. Presently defined values are shown + here for reference only: + + 0 is reserved + + 1 is DSA + + 2 is RSA + + + + +Nikander & Laganier Experimental [Page 13] + +RFC 5205 HIP DNS Extension April 2008 + + + In the future, if a new algorithm is to be used for the HIP RR, a new + algorithm type and corresponding public key encoding should be + defined for the IPSECKEY RR. The HIP RR should reuse both the same + algorithm type and the same corresponding public key format as the + IPSECKEY RR. + +10. Acknowledgments + + As usual in the IETF, this document is the result of a collaboration + between many people. The authors would like to thank the author + (Michael Richardson), contributors, and reviewers of the IPSECKEY RR + [RFC4025] specification, after which this document was framed. The + authors would also like to thank the following people, who have + provided thoughtful and helpful discussions and/or suggestions, that + have helped improve this document: Jeff Ahrenholz, Rob Austein, Hannu + Flinck, Olafur Gudmundsson, Tom Henderson, Peter Koch, Olaf Kolkman, + Miika Komu, Andrew McGregor, Erik Nordmark, and Gabriel Montenegro. + Some parts of this document stem from the HIP specification + [RFC5201]. + +11. References + +11.1. Normative references + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [RFC4025] Richardson, M., "A Method for Storing IPsec Keying + Material in DNS", RFC 4025, March 2005. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + + + + +Nikander & Laganier Experimental [Page 14] + +RFC 5205 HIP DNS Extension April 2008 + + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + + [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. + Henderson, "Host Identity Protocol", RFC 5201, April 2008. + + [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) + Rendezvous Extension", RFC 5204, April 2008. + +11.2. Informative references + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol + (HIP) Architecture", RFC 4423, May 2006. + + [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming + with the Host Identity Protocol", RFC 5206, April 2008. + + + + + + + + + + + + + + + + + + +Nikander & Laganier Experimental [Page 15] + +RFC 5205 HIP DNS Extension April 2008 + + +Authors' Addresses + + Pekka Nikander + Ericsson Research NomadicLab + JORVAS FIN-02420 + FINLAND + + Phone: +358 9 299 1 + EMail: pekka.nikander@nomadiclab.com + + + Julien Laganier + DoCoMo Communications Laboratories Europe GmbH + Landsberger Strasse 312 + Munich 80687 + Germany + + Phone: +49 89 56824 231 + EMail: julien.ietf@laposte.net + URI: http://www.docomolab-euro.com/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nikander & Laganier Experimental [Page 16] + +RFC 5205 HIP DNS Extension April 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + 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, THE IETF TRUST 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; nor does it 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 and 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 that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Nikander & Laganier Experimental [Page 17] + diff --git a/doc/rfc/rfc5452.txt b/doc/rfc/rfc5452.txt new file mode 100644 index 000000000000..6f59bf57acfb --- /dev/null +++ b/doc/rfc/rfc5452.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group A. Hubert +Request for Comments: 5452 Netherlabs Computer Consulting BV. +Updates: 2181 R. van Mook +Category: Standards Track Equinix + January 2009 + + + Measures for Making DNS More Resilient against Forged Answers + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + The current Internet climate poses serious threats to the Domain Name + System. In the interim period before the DNS protocol can be secured + more fully, measures can already be taken to harden the DNS to make + 'spoofing' a recursing nameserver many orders of magnitude harder. + + Even a cryptographically secured DNS benefits from having the ability + to discard bogus responses quickly, as this potentially saves large + amounts of computation. + + By describing certain behavior that has previously not been + standardized, this document sets out how to make the DNS more + resilient against accepting incorrect responses. This document + updates RFC 2181. + + + + + + + + +Hubert & van Mook Standards Track [Page 1] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements and Definitions . . . . . . . . . . . . . . . . . 4 + 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Description of DNS Spoofing . . . . . . . . . . . . . . . . . 5 + 4. Detailed Description of Spoofing Scenarios . . . . . . . . . . 6 + 4.1. Forcing a Query . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Matching the Question Section . . . . . . . . . . . . . . 7 + 4.3. Matching the ID Field . . . . . . . . . . . . . . . . . . 7 + 4.4. Matching the Source Address of the Authentic Response . . 7 + 4.5. Matching the Destination Address and Port of the + Authentic Response . . . . . . . . . . . . . . . . . . . . 8 + 4.6. Have the Response Arrive before the Authentic Response . . 8 + 5. Birthday Attacks . . . . . . . . . . . . . . . . . . . . . . . 9 + 6. Accepting Only In-Domain Records . . . . . . . . . . . . . . . 9 + 7. Combined Difficulty . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Symbols Used in Calculation . . . . . . . . . . . . . . . 10 + 7.2. Calculation . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Repetitive Spoofing Attempts for a Single Domain Name . . 13 + 9. Forgery Countermeasures . . . . . . . . . . . . . . . . . . . 13 + 9.1. Query Matching Rules . . . . . . . . . . . . . . . . . . . 13 + 9.2. Extending the Q-ID Space by Using Ports and Addresses . . 14 + 9.2.1. Justification and Discussion . . . . . . . . . . . . . 14 + 9.3. Spoof Detection and Countermeasure . . . . . . . . . . . . 15 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 + + + + + + + + + + + + + + + + + + + +Hubert & van Mook Standards Track [Page 2] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +1. Introduction + + This document describes several common problems in DNS + implementations, which, although previously recognized, remain + largely unsolved. Besides briefly recapping these problems, this + document contains rules that, if implemented, make complying + resolvers vastly more resistant to the attacks described. The goal + is to make the existing DNS as secure as possible within the current + protocol boundaries. + + The words below are aimed at authors of resolvers: it is up to + operators to decide which nameserver implementation to use, or which + options to enable. Operational constraints may override the security + concerns described below. However, implementations are expected to + allow an operator to enable functionality described in this document. + + Almost every transaction on the Internet involves the Domain Name + System, which is described in [RFC1034], [RFC1035], and beyond. + + Additionally, it has recently become possible to acquire Secure + Socket Layer/Transport Layer Security (SSL/TLS) certificates with no + other confirmation of identity than the ability to respond to a + verification email sent via SMTP ([RFC5321]) -- which generally uses + DNS for its routing. + + In other words, any party that (temporarily) controls the Domain Name + System is in a position to reroute most kinds of Internet + transactions, including the verification steps in acquiring an SSL/ + TLS certificate for a domain. This in turn means that even + transactions protected by SSL/TLS could be diverted. + + It is entirely conceivable that such rerouted traffic could be used + to the disadvantage of Internet users. + + These and other developments have made the security and + trustworthiness of DNS of renewed importance. Although the DNS + community is working hard on finalizing and implementing a + cryptographically enhanced DNS protocol, steps should be taken to + make sure that the existing use of DNS is as secure as possible + within the bounds of the relevant standards. + + It should be noted that the most commonly used resolvers currently do + not perform as well as possible in this respect, making this document + of urgent importance. + + A thorough analysis of risks facing DNS can be found in [RFC3833]. + + + + + +Hubert & van Mook Standards Track [Page 3] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + This document expands on some of the risks mentioned in RFC 3833, + especially those outlined in the sections on "ID Guessing and Query + Prediction" and "Name Chaining". Furthermore, it emphasizes a number + of existing rules and guidelines embodied in the relevant DNS + protocol specifications. The following also specifies new + requirements to make sure the Domain Name System can be relied upon + until a more secure protocol has been standardized and deployed. + + It should be noted that even when all measures suggested below are + implemented, protocol users are not protected against third parties + with the ability to observe, modify, or inject packets in the traffic + of a resolver. + + For protocol extensions that offer protection against these + scenarios, see [RFC4033] and beyond. + +2. Requirements and Definitions + +2.1. Definitions + + This document uses the following definitions: + + Client: typically a 'stub-resolver' on an end-user's computer. + + Resolver: a nameserver performing recursive service for clients, + also known as a caching server, or a full service resolver + ([RFC1123], Section 6.1.3.1). + + Stub resolver: a very limited resolver on a client computer, that + leaves the recursing work to a full resolver. + + Query: a question sent out by a resolver, typically in a UDP + packet + + Response: the answer sent back by an authoritative nameserver, + typically in a UDP packet. + + Third party: any entity other than the resolver or the intended + recipient of a question. The third party may have access to an + arbitrary authoritative nameserver, but has no access to packets + transmitted by the resolver or authoritative server. + + Attacker: malicious third party. + + Spoof: the activity of attempting to subvert the DNS process by + getting a chosen answer accepted. + + + + + +Hubert & van Mook Standards Track [Page 4] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + Authentic response: the correct answer that comes from the right + authoritative server. + + Target domain name: domain for which the attacker wishes to spoof + in an answer + + Fake data: response chosen by the attacker. + +2.2. Key Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Description of DNS Spoofing + + When certain steps are taken, it is feasible to "spoof" the current + deployed majority of resolvers with carefully crafted and timed DNS + packets. Once spoofed, a caching server will repeat the data it + wrongfully accepted, and make its clients contact the wrong, and + possibly malicious, servers. + + To understand how this process works it is important to know what + makes a resolver accept a response. + + The following sentence in Section 5.3.3 of [RFC1034] presaged the + present problem: + + The resolver should be highly paranoid in its parsing of responses. + It should also check that the response matches the query it sent + using the ID field in the response. + + DNS data is to be accepted by a resolver if and only if: + + 1. The question section of the reply packet is equivalent to that of + a question packet currently waiting for a response. + + 2. The ID field of the reply packet matches that of the question + packet. + + 3. The response comes from the same network address to which the + question was sent. + + 4. The response comes in on the same network address, including port + number, from which the question was sent. + + In general, the first response matching these four conditions is + accepted. + + + +Hubert & van Mook Standards Track [Page 5] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + If a third party succeeds in meeting the four conditions before the + response from the authentic nameserver does so, it is in a position + to feed a resolver fabricated data. When it does so, we dub it an + "attacker", attempting to spoof in fake data. + + All conditions mentioned above can theoretically be met by a third + party, with the difficulty being a function of the resolver + implementation and zone configuration. + +4. Detailed Description of Spoofing Scenarios + + The previous paragraph discussed a number of requirements an attacker + must match in order to spoof in manipulated (or fake) data. This + section discusses the relative difficulties and how implementation- + defined choices impact the amount of work an attacker has to perform + to meet said difficulties. + + Some more details can be found in Section 2.2 of [RFC3833]. + +4.1. Forcing a Query + + Formally, there is no need for a nameserver to perform service except + for its operator, its customers, or more generally its users. + Recently, open recursing nameservers have been used to amplify + denial-of-service attacks. + + Providing full service enables the third party to send the target + resolver a query for the domain name it intends to spoof. On + receiving this query, and not finding the answer in its cache, the + resolver will transmit queries to relevant authoritative nameservers. + This opens up a window of opportunity for getting fake answer data + accepted. + + Queries may however be forced indirectly, for example, by inducing a + mail server to perform DNS lookups. + + Some operators restrict access by not recursing for unauthorized IP + addresses, but only respond with data from the cache. This makes + spoofing harder for a third party as it cannot then force the exact + moment a question will be asked. It is still possible however to + determine a time range when this will happen, because nameservers + helpfully publish the decreasing time to live (TTL) of entries in the + cache, which indicate from which absolute time onwards a new query + could be sent to refresh the expired entry. + + The time to live of the target domain name's RRSets determines how + often a window of opportunity is available, which implies that a + short TTL makes spoofing far more viable. + + + +Hubert & van Mook Standards Track [Page 6] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + Note that the attacker might very well have authorized access to the + target resolver by virtue of being a customer or employee of its + operator. In addition, access may be enabled through the use of + reflectors as outlined in [RFC5358]. + +4.2. Matching the Question Section + + DNS packets, both queries and responses, contain a question section. + Incoming responses should be verified to have a question section that + is equivalent to that of the outgoing query. + +4.3. Matching the ID Field + + The DNS ID field is 16 bits wide, meaning that if full use is made of + all these bits, and if their contents are truly random, it will + require on average 32768 attempts to guess. Anecdotal evidence + suggests there are implementations utilizing only 14 bits, meaning on + average 8192 attempts will suffice. + + Additionally, if the target nameserver can be forced into having + multiple identical queries outstanding, the "Birthday Attack" + phenomenon means that any fake data sent by the attacker is matched + against multiple outstanding queries, significantly raising the + chance of success. Further details in Section 5. + +4.4. Matching the Source Address of the Authentic Response + + It should be noted that meeting this condition entails being able to + transmit packets on behalf of the address of the authoritative + nameserver. While two Best Current Practice documents ([RFC2827] and + [RFC3013] specifically) direct Internet access providers to prevent + their customers from assuming IP addresses that are not assigned to + them, these recommendations are not universally (nor even widely) + implemented. + + Many zones have two or three authoritative nameservers, which make + matching the source address of the authentic response very likely + with even a naive choice having a double digit success rate. + + Most recursing nameservers store relative performance indications of + authoritative nameservers, which may make it easier to predict which + nameserver would originally be queried -- the one most likely to + respond the quickest. + + Generally, this condition requires at most two or three attempts + before it is matched. + + + + + +Hubert & van Mook Standards Track [Page 7] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +4.5. Matching the Destination Address and Port of the Authentic + Response + + Note that the destination address of the authentic response is the + source address of the original query. + + The actual address of a recursing nameserver is generally known; the + port used for asking questions is harder to determine. Most current + resolvers pick an arbitrary port at startup (possibly at random) and + use this for all outgoing queries. In quite a number of cases, the + source port of outgoing questions is fixed at the traditional DNS + assigned server port number of 53. + + If the source port of the original query is random, but static, any + authoritative nameserver under observation by the attacker can be + used to determine this port. This means that matching this + conditions often requires no guess work. + + If multiple ports are used for sending queries, this enlarges the + effective ID space by a factor equal to the number of ports used. + + Less common resolving servers choose a random port per outgoing + query. If this strategy is followed, this port number can be + regarded as an additional ID field, again containing up to 16 bits. + + If the maximum ports range is utilized, on average, around 32256 + source ports would have to be tried before matching the source port + of the original query, as ports below 1024 may be unavailable for + use, leaving 64512 options. + + It is in general safe for DNS to use ports in the range 1024-49152 + even though some of these ports are allocated to other protocols. + DNS resolvers will not be able to use any ports that are already in + use. If a DNS resolver uses a port, it will release that port after + a short time and migrate to a different port. Only in the case of a + high-volume resolver is it possible that an application wanting a + particular UDP port suffers a long term block-out. + + It should be noted that a firewall will not prevent the matching of + this address, as it will accept answers that (appear to) come from + the correct address, offering no additional security. + +4.6. Have the Response Arrive before the Authentic Response + + Once any packet has matched the previous four conditions (plus + possible additional conditions), no further responses are generally + accepted. + + + + +Hubert & van Mook Standards Track [Page 8] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + This means that the third party has a limited time in which to inject + its spoofed response. For calculations, we will assume a window in + order of at most 100 ms (depending on the network distance to the + authentic authoritative nameserver). + + This time period can be far longer if the authentic authoritative + nameservers are (briefly) overloaded by queries, perhaps by the + attacker. + +5. Birthday Attacks + + The so-called "birthday paradox" implies that a group of 23 people + suffices to have a more than even chance of having two or more + members of the group share a birthday. + + An attacker can benefit from this exact phenomenon if it can force + the target resolver to have multiple equivalent (identical QNAME, + QTYPE, and QCLASS) outstanding queries at any one time to the same + authoritative server. + + Any packet the attacker sends then has a much higher chance of being + accepted because it only has to match any of the outstanding queries + for that single domain. Compared to the birthday analogy above, of + the group composed of queries and responses, the chance of having any + of these share an ID rises quickly. + + As long as small numbers of queries are sent out, the chance of + successfully spoofing a response rises linearly with the number of + outstanding queries for the exact domain and nameserver. + + For larger numbers, this effect is less pronounced. + + More details are available in US-CERT [vu-457875]. + +6. Accepting Only In-Domain Records + + Responses from authoritative nameservers often contain information + that is not part of the zone for which we deem it authoritative. As + an example, a query for the MX record of a domain might get as its + responses a mail exchanger in another domain, and additionally the IP + address of this mail exchanger. + + If accepted uncritically, the resolver stands the chance of accepting + data from an untrusted source. Care must be taken to only accept + data if it is known that the originator is authoritative for the + QNAME or a parent of the QNAME. + + + + + +Hubert & van Mook Standards Track [Page 9] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + One very simple way to achieve this is to only accept data if it is + part of the domain for which the query was intended. + +7. Combined Difficulty + + Given a known or static destination port, matching ID field, the + source and destination address requires on average in the order of 2 + * 2^15 = 65000 packets, assuming a zone has 2 authoritative + nameservers. + + If the window of opportunity available is around 100 ms, as assumed + above, an attacker would need to be able to briefly transmit 650000 + packets/s to have a 50% chance to get spoofed data accepted on the + first attempt. + + A realistic minimal DNS response consists of around 80 bytes, + including IP headers, making the packet rate above correspond to a + respectable burst of 416 Mbit/s. + + As of mid-2006, this kind of bandwidth was not common but not scarce + either, especially among those in a position to control many servers. + + These numbers change when a window of a full second is assumed, + possibly because the arrival of the authentic response can be + prevented by overloading the bona fide authoritative hosts with decoy + queries. This reduces the needed bandwidth to 42 Mbit/s. + + If, in addition, the attacker is granted more than a single chance + and allowed up to 60 minutes of work on a domain with a time to live + of 300 seconds, a meager 4 Mbit/s suffices for a 50% chance at + getting fake data accepted. Once equipped with a longer time, + matching condition 1 mentioned above is straightforward -- any + popular domain will have been queried a number of times within this + hour, and given the short TTL, this would lead to queries to + authoritative nameservers, opening windows of opportunity. + +7.1. Symbols Used in Calculation + + Assume the following symbols are used: + + I: Number distinct IDs available (maximum 65536) + + P: Number of ports used (maximum around 64000 as ports under 1024 are + not always available, but often 1) + + N: Number of authoritative nameservers for a domain (averages around + 2.5) + + + + +Hubert & van Mook Standards Track [Page 10] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + F: Number of "fake" packets sent by the attacker + + R: Number of packets sent per second by the attacker + + W: Window of opportunity, in seconds. Bounded by the response time + of the authoritative servers (often 0.1s) + + D: Average number of identical outstanding queries of a resolver + (typically 1, see Section 5) + + A: Number of attempts, one for each window of opportunity + +7.2. Calculation + + The probability of spoofing a resolver is equal to the amount of fake + packets that arrive within the window of opportunity, divided by the + size of the problem space. + + When the resolver has 'D' multiple identical outstanding queries, + each fake packet has a proportionally higher chance of matching any + of these queries. This assumption only holds for small values of + 'D'. + + In symbols, if the probability of being spoofed is denoted as P_s: + + D * F + P_s = --------- + N * P * I + + It is more useful to reason not in terms of aggregate packets but to + convert to packet rate, which can easily be converted to bandwidth if + needed. + + If the window of opportunity length is 'W' and the attacker can send + 'R' packets per second, the number of fake packets 'F' that are + candidates to be accepted is: + + D * R * W + F = R * W -> P_s = --------- + N * P * I + + Finally, to calculate the combined chance 'P_cs' of spoofing over a + chosen time period 'T', it should be realized that the attacker has a + new window of opportunity each time the TTL 'TTL' of the target + domain expires. This means that the number of attempts 'A' is equal + to 'T / TTL'. + + + + + +Hubert & van Mook Standards Track [Page 11] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + To calculate the combined chance of at least one success, the + following formula holds: + + (T / TTL) + A ( D * R * W ) + P_cs = 1 - ( 1 - P_s ) = 1 - ( 1 - --------- ) + ( N * P * I ) + + When common numbers (as listed above) for D, W, N, P, and I are + inserted, this formula reduces to: + + (T / TTL) + ( R ) + P_cs = 1 - ( 1 - ------- ) + ( 1638400 ) + + From this formula, it can be seen that, if the nameserver + implementation is unchanged, only raising the TTL offers protection. + Raising N, the number of authoritative nameservers, is not feasible + beyond a small number. + + For the degenerate case of a zero-second TTL, a window of opportunity + opens for each query sent, making the effective TTL equal to 'W' + above, the response time of the authoritative server. + + This last case also holds for spoofing techniques that do not rely on + TTL expiry, but use repeated and changing queries. + +8. Discussion + + The calculations above indicate the relative ease with which DNS data + can be spoofed. For example, using the formula derived earlier on an + RRSet with a 3600 second TTL, an attacker sending 7000 fake response + packets/s (a rate of 4.5 Mbit/s), stands a 10% chance of spoofing a + record in the first 24 hours, which rises to 50% after a week. + + For an RRSet with a TTL of 60 seconds, the 10% level is hit after 24 + minutes, 50% after less than 3 hours, 90% after around 9 hours. + + For some classes of attacks, the effective TTL is near zero, as noted + above. + + Note that the attacks mentioned above can be detected by watchful + server operators - an unexpected incoming stream of 4.5 Mbit/s of + packets might be noticed. + + An important assumption however in these calculations is a known or + static destination port of the authentic response. + + + +Hubert & van Mook Standards Track [Page 12] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + If that port number is unknown and needs to be guessed as well, the + problem space expands by a factor of 64000, leading the attacker to + need in excess of 285Gb/s to achieve similar success rates. + + Such bandwidth is not generally available, nor is it expected to be + so in the foreseeable future. + + Note that some firewalls may need reconfiguring if they are currently + set up to only allow outgoing queries from a single DNS source port. + +8.1. Repetitive Spoofing Attempts for a Single Domain Name + + Techniques are available to use an effectively infinite number of + queries to achieve a desired spoofing goal. In the math above, this + reduces the effective TTL to 0. + + If such techniques are employed, using the same 7000 packets/s rate + mentioned above, and using 1 source port, the spoofing chance rises + to 50% within 7 seconds. + + If 64000 ports are used, as recommended in this document, using the + same query rate, the 50% level is reached after around 116 hours. + +9. Forgery Countermeasures + +9.1. Query Matching Rules + + A resolver implementation MUST match responses to all of the + following attributes of the query: + + o Source address against query destination address + + o Destination address against query source address + + o Destination port against query source port + + o Query ID + + o Query name + + o Query class and type + + before applying DNS trustworthiness rules (see Section 5.4.1 of + [RFC2181]). + + A mismatch and the response MUST be considered invalid. + + + + + +Hubert & van Mook Standards Track [Page 13] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +9.2. Extending the Q-ID Space by Using Ports and Addresses + + Resolver implementations MUST: + + o Use an unpredictable source port for outgoing queries from the + range of available ports (53, or 1024 and above) that is as large + as possible and practicable; + + o Use multiple different source ports simultaneously in case of + multiple outstanding queries; + + o Use an unpredictable query ID for outgoing queries, utilizing the + full range available (0-65535). + + Resolvers that have multiple IP addresses SHOULD use them in an + unpredictable manner for outgoing queries. + + Resolver implementations SHOULD provide means to avoid usage of + certain ports. + + Resolvers SHOULD favor authoritative nameservers with which a trust + relation has been established; stub-resolvers SHOULD be able to use + Transaction Signature (TSIG) ([RFC2845]) or IPsec ([RFC4301]) when + communicating with their recursive resolver. + + In case a cryptographic verification of response validity is + available (TSIG, SIG(0)), resolver implementations MAY waive above + rules, and rely on this guarantee instead. + + Proper unpredictability can be achieved by employing a high quality + (pseudo-)random generator, as described in [RFC4086]. + +9.2.1. Justification and Discussion + + Since an attacker can force a full DNS resolver to send queries to + the attacker's own nameservers, any constant or sequential state held + by such a resolver can be measured, and it must not be trivially easy + to reverse engineer the resolver's internal state in a way that + allows low-cost, high-accuracy prediction of future state. + + A full DNS resolver with only one or a small number of upstream- + facing endpoints is effectively using constants for IP source address + and UDP port number, and these are very predictable by potential + attackers, and must therefore be avoided. + + A full DNS resolver that uses a simple increment to get its next DNS + query ID is likewise very predictable and so very spoofable. + + + + +Hubert & van Mook Standards Track [Page 14] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + Finally, weak random number generators have been shown to expose + their internal state, such that an attacker who witnesses several + sequential "random" values can easily predict the next ones. A + crypto-strength random number generator is one whose output cannot be + predicted no matter how many successive values are witnessed. + +9.3. Spoof Detection and Countermeasure + + If a resolver detects that an attempt is being made to spoof it, + perhaps by discovering that many packets fail the criteria as + outlined above, it MAY abandon the UDP query and re-issue it over + TCP. TCP, by the nature of its use of sequence numbers, is far more + resilient against forgery by third parties. + +10. Security Considerations + + This document provides clarification of the DNS specification to + decrease the probability that DNS responses can be successfully + forged. Recommendations found above should be considered + complementary to possible cryptographical enhancements of the domain + name system, which protect against a larger class of attacks. + + This document recommends the use of UDP source port number + randomization to extend the effective DNS transaction ID beyond the + available 16 bits. + + A resolver that does not implement the recommendations outlined above + can easily be forced to accept spoofed responses, which in turn are + passed on to client computers -- misdirecting (user) traffic to + possibly malicious entities. + + This document directly impacts the security of the Domain Name + System, implementers are urged to follow its recommendations. + + Most security considerations can be found in Sections 4 and 5, while + proposed countermeasures are described in Section 9. + + For brevity's sake, in lieu of repeating the security considerations + references, the reader is referred to these sections. + + Nothing in this document specifies specific algorithms for operators + to use; it does specify algorithms implementations SHOULD or MUST + support. + + It should be noted that the effects of source port randomization may + be dramatically reduced by NAT devices that either serialize or limit + in volume the UDP source ports used by the querying resolver. + + + + +Hubert & van Mook Standards Track [Page 15] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + DNS recursive servers sitting behind at NAT or a statefull firewall + may consume all available NAT translation entries/ports when + operating under high query load. Port randomization will cause + translation entries to be consumed faster than with fixed query port. + + To avoid this, NAT boxes and statefull firewalls can/should purge + outgoing DNS query translation entries 10-17 seconds after the last + outgoing query on that mapping was sent. [RFC4787]-compliant devices + need to treat UDP messages with port 53 differently than most other + UDP protocols. + + To minimize the potential that port/state exhaustion attacks can be + staged from the outside, it is recommended that services that + generate a number of DNS queries for each connection should be rate + limited. This applies in particular to email servers. + +11. Acknowledgments + + Source port randomization in DNS was first implemented and possibly + invented by Dan J. Bernstein. + + Although any mistakes remain our own, the authors gratefully + acknowledge the help and contributions of: + Stephane Bortzmeyer + Alfred Hoenes + Peter Koch + Sean Leach + Norbert Sendetzky + Paul Vixie + Florian Weimer + Wouter Wijngaards + Dan Wing + +12. References + +12.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + + +Hubert & van Mook Standards Track [Page 16] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP + Source Address Spoofing", BCP 38, RFC 2827, May 2000. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + Wellington, "Secret Key Transaction Authentication for + DNS (TSIG)", RFC 2845, May 2000. + + [RFC3013] Killalea, T., "Recommended Internet Service Provider + Security Services and Procedures", BCP 46, RFC 3013, + November 2000. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, + June 2005. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + +12.2. Informative References + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, October 1989. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the + Domain Name System (DNS)", RFC 3833, August 2004. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive + Nameservers in Reflector Attacks", BCP 140, RFC 5358, + October 2008. + + [vu-457875] United States CERT, "Various DNS service implementations + generate multiple simultaneous queries for the same + resource record", VU 457875, November 2002. + + + + + + +Hubert & van Mook Standards Track [Page 17] + +RFC 5452 DNS Resilience against Forged Answers January 2009 + + +Authors' Addresses + + Bert Hubert + Netherlabs Computer Consulting BV. + Braillelaan 10 + Rijswijk (ZH) 2289 CM + The Netherlands + + EMail: bert.hubert@netherlabs.nl + + + Remco van Mook + Equinix + Auke Vleerstraat 1 + Enschede 7521 PE + The Netherlands + + EMail: remco@eu.equinix.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hubert & van Mook Standards Track [Page 18] + diff --git a/doc/rfc/rfc5507.txt b/doc/rfc/rfc5507.txt new file mode 100644 index 000000000000..a286d90854d5 --- /dev/null +++ b/doc/rfc/rfc5507.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group IAB +Request for Comments: 5507 P. Faltstrom, Ed. +Category: Informational R. Austein, Ed. + P. Koch, Ed. + April 2009 + + + Design Choices When Expanding the DNS + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + +Abstract + + This note discusses how to extend the DNS with new data for a new + application. DNS extension discussions too often focus on reuse of + the TXT Resource Record Type. This document lists different + mechanisms to extend the DNS, and concludes that the use of a new DNS + Resource Record Type is the best solution. + + + + + + + + + + + + + + + + + +IAB, et al. Informational [Page 1] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Background ......................................................4 + 3. Extension Mechanisms ............................................5 + 3.1. Place Selectors inside the RDATA of Existing + Resource Record Types ......................................5 + 3.2. Add a Prefix to the Owner Name .............................6 + 3.3. Add a Suffix to the Owner Name .............................7 + 3.4. Add a New Class ............................................8 + 3.5. Add a New Resource Record Type .............................8 + 4. Zone Boundaries are Invisible to Applications ...................9 + 5. Why Adding a New Resource Record Type Is the Preferred + Solution .......................................................10 + 6. Conclusion and Recommendation ..................................14 + 7. Creating a New Resource Record Type ............................14 + 8. Security Considerations ........................................15 + 9. Acknowledgements ...............................................15 + 10. IAB Members at the Time of This Writing .......................16 + 11. References ....................................................16 + 11.1. Normative References .....................................16 + 11.2. Informative References ...................................16 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +IAB, et al. Informational [Page 2] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + +1. Introduction + + The DNS stores multiple categories of data. The two most commonly + used categories are infrastructure data for the DNS system itself (NS + and SOA Resource Records) and data that have to do with mappings + between domain names and IP addresses (A, AAAA, and PTR Resource + Records). There are other categories as well, some of which are tied + to specific applications like email (MX Resource Records), while + others are generic Resource Record Types used to convey information + for multiple protocols (SRV and NAPTR Resource Records). + + When storing data in the DNS for a new application, the goal must be + to store data in such a way that the application can query for the + data it wants, while minimizing both the impact on existing + applications and the amount of extra data transferred to the client. + This implies that a number of design choices have to be made, where + the most important is to ensure that a precise selection of what data + to return must be made already in the query. A query consists of a + triple: {Owner (or name), Resource Record Class, Resource Record + Type}. + + Historically, extending the DNS to store application data tied to a + domain name has been done in different ways at different times. MX + Resource Records were created as a new Resource Record Type + specifically designed to support electronic mail. SRV records are a + generic type that use a prefixing scheme in combination with a base + domain name. NAPTR records add selection data inside the RDATA. It + is clear that the methods used to add new data types to the DNS have + been inconsistent, and the purpose of this document is to attempt to + clarify the implications of each of these methods, both for the + applications that use them and for the rest of the DNS. + + This document talks extensively about use of DNS wildcards. Many + people might think use of wildcards is not something that happens + today. In reality though, wildcards are in use, especially for + certain application-specific data such as MX Resource Records. + Because of this, the choice has to be made with the existence of + wildcards in mind. + + Another overall issue that must be taken into account is what the new + data in the DNS are to describe. In some cases, they might be + completely new data. In other cases, they might be metadata tied to + data that already exist in the DNS. Examples of new data are key + information for the Secure SHell (SSH) Protocol and data used for + authenticating the sender of email messages (metadata tied to MX + Resource Records). If the new data are tied to data that already + exist in the DNS, an analysis should be made as to whether having + (for example) address records and SSH key information in different + + + +IAB, et al. Informational [Page 3] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + DNS zones is a problem or if it is a bonus, and if it is a problem, + whether the specification must require all of the related data to be + in the same zone. One specific difference between having the records + in the same zone or not has to do with maintenance of the records. + If they are in the same zone, the same maintainer (from a DNS + perspective) manages the two records. Specifically, they must be + signed with the same DNSSEC keys if DNSSEC is in use. + + This document does not talk about what one should store in the DNS. + It also doesn't discuss whether the DNS should be used for service + discovery, or whether the DNS should be used for storage of data + specific to the service. In general, the DNS is a protocol that, + apart from holding metadata that makes the DNS itself function (NS, + SOA, DNSSEC Resource Record Types, etc.), only holds references to + service locations (SRV, NAPTR, A, AAAA Resource Record Types) -- + though there are exceptions, such as MX Resource Records. + +2. Background + + See RFC 5395 [RFC5395] for a brief summary of the DNS query + structure. Readers interested in the full story should start with + the base DNS specification in RFC 1035 [RFC1035] and continue with + the various documents that update, clarify, and extend the base + specification. + + When composing a DNS query, the parameters used by the protocol are a + {owner, class, type} triple. Every Resource Record matching such a + triple is said to belong to the same Resource Record Set (RRSet), and + the whole RRSet is always returned to the client that queries for it. + Splitting an RRSet is a protocol violation (sending a partial RRSet, + not truncating the DNS response), because it can result in coherency + problems with the DNS caching mechanism. See Section 5 of [RFC2181] + for more information. + + Some discussions around extensions to the DNS include arguments + around MTU size. Note that most discussions about DNS and MTU size + are about the size of the whole DNS packet, not about the size of a + single RRSet. + + Almost all DNS query traffic is carried over UDP, where a DNS message + must fit within a single UDP packet. DNS response messages are + almost always larger than DNS query messages, so message size issues + are almost always about responses, not queries. The base DNS + specification limits DNS messages over UDP to 512 octets; EDNS0 + [RFC2671] specifies a mechanism by which a client can signal its + willingness to receive larger responses, but deployment of EDNS0 is + not universal, in part because of firewalls that block fragmented UDP + packets or EDNS0. If a response message won't fit in a single + + + +IAB, et al. Informational [Page 4] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + packet, the name server returns a truncated response, at which point + the client may retry using TCP. DNS queries over TCP are not subject + to this length limitation, but TCP imposes significantly higher per- + query overhead on name servers than UDP. It is also the case that + the policies in deployed firewalls far too often are such that they + block DNS over TCP, so using TCP might not in reality be an option. + There are also risks (although possibly small) that a change of + routing while a TCP flow is open creates problems when the DNS + servers are deployed in an anycast environment. + +3. Extension Mechanisms + + The DNS protocol is intended to be extensible to support new kinds of + data. This section examines the various ways in which this sort of + extension can be accomplished. + +3.1. Place Selectors inside the RDATA of Existing Resource Record Types + + For a given query name, one might choose to have a single RRSet (all + Resource Records sharing the same {owner, class, type} triple) shared + by multiple applications, and have the different applications use + selectors within the Resource Record data (RDATA) to determine which + records are intended for which applications. This sort of selector + mechanism is usually referred to "subtyping", because it is in effect + creating an additional type subsystem within a single DNS Resource + Record Type. + + Examples of subtyping include NAPTR Resource Records [RFC3761] and + the original DNSSEC KEY Resource Record Type [RFC2535] (which was + later updated by RFC 3445 [RFC3445], and obsoleted by RFC 4033 + [RFC4033], RFC 4034 [RFC4034] and RFC 4035 [RFC4035]). + + All DNS subtyping schemes share a common weakness: with subtyping + schemes, it is impossible for a client to query for just the data it + wants. Instead, the client must fetch the entire RRSet, then select + the Resource Records in which it is interested. Furthermore, since + DNSSEC signatures operate on complete RRSets, the entire RRSet must + be re-signed if any Resource Record in it changes. As a result, each + application that uses a subtyped Resource Record incurs higher + overhead than any of the applications would have incurred had they + not been using a subtyping scheme. The fact the RRSet is always + passed around as an indivisible unit increases the risk the RRSet + will not fit in a UDP packet, which in turn increases the risk that + the client will have to retry the query with TCP, which substantially + increases the load on the name server. More precisely: having one + query fail over to TCP is not a big deal, but since the typical ratio + + + + + +IAB, et al. Informational [Page 5] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + of clients to servers in today's deployed DNS is very high, having a + substantial number of DNS messages fail over to TCP may cause the + queried name servers to be overloaded by TCP overhead. + + Because of the size limitations, using a subtyping scheme to list a + large number of services for a single domain name risks triggering + truncation and fallback to TCP, which may in turn force the zone + administrator to announce only a subset of available services. + +3.2. Add a Prefix to the Owner Name + + By adding an application-specific prefix to a domain name, we get a + different {owner, class, type} triple, and therefore a different + RRSet. One problem with adding prefixes has to do with wildcards, + especially if one has records like: + + *.example.com. IN MX 1 mail.example.com. + + and one wants records tied to those names. Suppose one creates the + prefix "_mail". One would then have to say something like: + + _mail.*.example.com. IN X-FOO A B C D + + but DNS wildcards only work with the "*" as the leftmost token in the + domain name (see also RFC 4592 [RFC4592]). + + There have been proposals to deal with the problem that DNS wildcards + are always terminal records. These proposals introduce an additional + set of trade-offs that would need to be taken into account when + assessing which extension mechanism to choose. Aspects of extra + response time needed to perform the extra queries, costs of pre- + calculation of possible answers, or the costs induced to the system + as a whole come to mind. At the time of writing, none of these + proposals has been published as Standards Track RFCs. + + Even when a specific prefix is chosen, the data will still have to be + stored in some Resource Record Type. This Resource Record Type can + be either a new Resource Record Type or an existing Resource Record + Type that has an appropriate format to store the data. One also + might need some other selection mechanism, such as the ability to + distinguish between the records in an RRSet, given they have the same + Resource Record Type. Because of this, one needs to both register a + unique prefix and define what Resource Record Type is to be used for + this specific service. + + + + + + + +IAB, et al. Informational [Page 6] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + If the record has some relationship with another record in the zone, + the fact that the two records can be in different zones might have + implications on the trust the application has in the records. For + example: + + example.com. IN MX 10 mail.example.com. + _foo.example.com. IN X-BAR "metadata for the mail service" + + In this example, the two records might be in two different zones, and + as a result might be administered by two different organizations, and + signed by two different entities when using DNSSEC. For these two + reasons, using a prefix has recently become a very interesting + solution for many protocol designers. In some cases, e.g., + DomainKeys Identified Mail Signatures [RFC4871], TXT records have + been used. In others, such as SRV, entirely new Resource Record + Types have been added. + +3.3. Add a Suffix to the Owner Name + + Adding a suffix to a domain name changes the {owner, class, type} + triple, and therefore the RRSet. In this case, since the query name + can be set to exactly the data one wants, the size of the RRSet is + minimized. The problem with adding a suffix is that it creates a + parallel tree within the IN class. Further, there is no technical + mechanism to ensure that the delegation for "example.com" and + "example.com._bar" are made to the same organization. Furthermore, + data associated with a single entity will now be stored in two + different zones, such as "example.com" and "example.com._bar", which, + depending on who controls "_bar", can create new synchronization and + update authorization issues. + + One way of solving the administrative issues is by using the DNAME + Resource Record Type specified in RFC 2672 [RFC2672]. + + Even when using a different name, the data will still have to be + stored in some Resource Record Type that has an appropriate format to + store the data. This implies that one might have to mix the prefix + based selection mechanism with some other mechanism so that the right + Resource Record can be found out of many in a potential larger RRSet. + + In RFC 2163 [RFC2163] an infix token is inserted directly below the + Top-Level Domain (TLD), but the result is equivalent to adding a + suffix to the owner name (instead of creating a TLD, one is creating + a second level domain). + + + + + + + +IAB, et al. Informational [Page 7] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + +3.4. Add a New Class + + DNS zones are class-specific in the sense that all the records in + that zone share the same class as the zone's SOA record and the + existence of a zone in one class does not guarantee the existence of + the zone in any other class. In practice, only the IN class has ever + seen widespread deployment, and the administrative overhead of + deploying an additional class would almost certainly be prohibitive. + + Nevertheless, one could, in theory, use the DNS class mechanism to + distinguish between different kinds of data. However, since the DNS + delegation tree (represented by NS Resource Records) is itself tied + to a specific class, attempting to resolve a query by crossing a + class boundary may produce unexpected results because there is no + guarantee that the name servers for the zone in the new class will be + the same as the name servers in the IN class. The MIT Hesiod system + [Dyer87] used a scheme like this for storing data in the HS class, + but only on a very small scale (within a single institution), and + with an administrative fiat requiring that the delegation trees for + the IN and HS trees be identical. The use of the HS class for such + storage of non-sensitive data was, over time, replaced by use of the + Lightweight Directory Access Protocol (LDAP) [RFC4511]. + + Even when using a different class, the data will still have to be + stored in some Resource Record Type that has an appropriate format. + +3.5. Add a New Resource Record Type + + When adding a new Resource Record Type to the system, entities in + four different roles have to be able to handle the new Type: + + 1. There must be a way to insert the new Resource Records into the + zone at the Primary Master name server. For some server + implementations, the user interface only accepts Resource Record + Types that it understands (perhaps so that the implementation can + attempt to validate the data). Other implementations allow the + zone administrator to enter an integer for the Resource Record + Type code and the RDATA in Base64 or hexadecimal encoding (or + even as raw data). RFC 3597 [RFC3597] specifies a standard + generic encoding for this purpose. + + 2. A slave authoritative name server must be able to do a zone + transfer, receive the data from some other authoritative name + server, and serve data from the zone even though the zone + includes records of unknown Resource Record Types. Historically, + some implementations have had problems parsing stored copies of + the zone file after restarting, but those problems have not been + seen for a few years. Some implementations use an alternate + + + +IAB, et al. Informational [Page 8] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + mechanism (e.g., LDAP) to transfer Resource Records in a zone, + and are primarily used within corporate environments; in this + case, name servers must be able to transfer new Resource Record + Types using whatever mechanism is used. However, today this + alternative mechanism may not support unknown Resource Record + Types. Hence, in Internet environments, unknown Resource Record + Types are supported, but in corporate environments they are + problematic. + + 3. A caching resolver (most commonly a recursive name server) will + cache the records that are responses to queries. As mentioned in + RFC 3597 [RFC3597], there are various pitfalls where a recursive + name server might end up having problems. + + 4. The application must be able to get the RRSet with a new Resource + Record Type. The application itself may understand the RDATA, + but the resolver library might not. Support for a generic + interface for retrieving arbitrary DNS Resource Record Types has + been a requirement since 1989 (see Section 6.1.4.2 of [RFC1123]). + Some stub resolver library implementations neglect to provide + this functionality and cannot handle unknown Resource Record + Types, but implementation of a new stub resolver library is not + particularly difficult, and open source libraries that already + provide this functionality are available. + + Historically, adding a new Resource Record Type has been very + problematic. The review process has been cumbersome, DNS servers + have not been able to handle new Resource Record Types, and firewalls + have dropped queries or responses with Resource Record Types that are + unknown to the firewall. This is, for example, one of the reasons + the ENUM standard reuses the NAPTR Resource Record, a decision that + today might have gone to creating a new Resource Record Type instead. + + Today, there is a requirement that DNS software handle unknown + Resource Record Types, and investigations have shown that software + that is deployed, in general, does support it, except in some + alternate mechanisms for transferring Resource Records such as LDAP, + as noted above. Also, the approval process for new Resource Record + Types has been updated [RFC5395] so the effort that is needed for + various Resource Record Types is more predictable. + +4. Zone Boundaries are Invisible to Applications + + Regardless of the possible choices above, we have seen a number of + cases where the application made assumptions about the structure of + the namespace and the location where specific information resides. + We take a small sidestep to argue against such approaches. + + + + +IAB, et al. Informational [Page 9] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + The DNS namespace is a hierarchy, technically speaking. However, + this only refers to the way names are built from multiple labels. + DNS hierarchy neither follows nor implies administrative hierarchy. + Because of that, it cannot be assumed that data attached to a node in + the DNS tree is valid for the whole subtree. Technically, there are + zone boundaries partitioning the namespace, and administrative + boundaries (or policy boundaries) may even exist elsewhere. + + The false assumption has lead to an approach called "tree climbing", + where a query that does not receive a positive response (either the + requested RRSet was missing or the name did not exist) is retried by + repeatedly stripping off the leftmost label (climbing towards the + root) until the root domain is reached. Sometimes these proposals + try to avoid the query for the root or the TLD level, but still this + approach has severe drawbacks: + + o Technically, the DNS was built as a query-response tool without + any search capability [RFC3467]. Adding the search mechanism + imposes additional burden on the technical infrastructure, in the + worst case on TLD and root name servers. + + o For reasons similar to those outlined in RFC 1535 [RFC1535], + querying for information in a domain outside the control of the + intended entity may lead to incorrect results and may also put + security at risk. Finding the exact policy boundary is impossible + without an explicit marker, which does not exist at present. At + best, software can detect zone boundaries (e.g., by looking for + SOA Resource Records), but some TLD registries register names + starting at the second level (e.g., CO.UK), and there are various + other "registry" types at second, third, or other level domains + that cannot be identified as such without policy knowledge + external to the DNS. + + To restate, the zone boundary is purely a boundary that exists in the + DNS for administrative purposes, and applications should be careful + not to draw unwarranted conclusions from zone boundaries. A + different way of stating this is that the DNS does not support + inheritance, e.g., an MX RRSet for a TLD will not be valid for any + subdomain of that particular TLD. + +5. Why Adding a New Resource Record Type Is the Preferred Solution + + By now, the astute reader might be wondering what conclusions to draw + from the issues presented so far. We will now attempt to clear up + the reader's confusion by following the thought processes of a + typical application designer who wishes to store data in the DNS. + We'll show how such a designer almost inevitably hits upon the idea + of just using a TXT Resource Record, why this is a bad thing, and why + + + +IAB, et al. Informational [Page 10] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + a new Resource Record Type should be allocated instead. We'll also + explain how the reuse of an existing Resource Record, including TXT, + can be made less harmful. + + The overall problem with most solutions has to do with two main + issues: + + o No semantics to prevent collision with other use + + o Space considerations in the DNS message + + A typical application designer is not interested in the DNS for its + own sake, but rather regards it as a distributed database in which + application data can be stored. As a result, the designer of a new + application is usually looking for the easiest way to add whatever + new data the application needs to the DNS in a way that naturally + associates the data with a DNS name and does not require major + changes to DNS servers. + + As explained in Section 3.4, using the DNS class system as an + extension mechanism is not really an option, and in fact, most users + of the system don't even realize that the mechanism exists. As a + practical matter, therefore any extension is likely to be within the + IN class. + + Adding a new Resource Record Type is the technically correct answer + from the DNS protocol standpoint (more on this below), but doing so + requires some DNS expertise, due to the issues listed in Section 3.5. + Consequently, this option is often rejected. Note that according to + RFC 5395 [RFC5395], some Types require IETF Consensus, while others + only require a specification. + + There is a drawback to defining new RR types that is worth + mentioning. The Resource Record Type (RRTYPE) is a 16-bit value and + hence is a limited resource. In order to prevent hoarding the + registry has a review-based allocation policy [RFC5395]; however, + this may not be sufficient if extension of the DNS by addition of new + RR types takes up significantly and the registry starts nearing + completion. In that case, the trade-offs with respect to choosing an + extension mechanism may need to change. + + The application designer is thus left with the prospect of reusing + some existing DNS Types within the IN class, but when the designer + looks at the existing Types, almost all of them have well-defined + semantics, none of which quite match the needs of the new + application. This has not completely prevented proposals from + + + + + +IAB, et al. Informational [Page 11] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + reusing existing Resource Record Types in ways incompatible with + their defined semantics, but it does tend to steer application + designers away from this approach. + + For example, Resource Record Type 40 was registered for the SINK + Resource Record Type. This Resource Record Type was discussed in the + DNSIND working group of the IETF, and it was decided at the 46th IETF + to not move the I-D forward to become an RFC because of the risk of + encouraging application designers to use the SINK Resource Record + Type instead of registering a new Resource Record Type, which would + result in infeasibly large SINK RRsets. + + Eliminating all of the above leaves the TXT Resource Record Type in + the IN class. The TXT RDATA format is free form text, and there are + no existing semantics to get in the way. Some attempts have been + made, for example, in [DNSEXT-DNS-SD], to specify a structured format + for TXT Resource Record Types, but no such attempt has reached RFC + status. Furthermore, the TXT Resource Record can obviously just be + used as a bucket in which to carry around data to be used by some + higher-level parser, perhaps in some human-readable programming or + markup language. Thus, for many applications, TXT Resource Records + are the "obvious" choice. Unfortunately, this conclusion, while + understandable, is also problematic, for several reasons. + + The first reason why TXT Resource Records are not well suited to such + use is precisely what makes them so attractive: the lack of pre- + defined common syntax or structure. As a result, each application + that uses them creates its own syntax/structure, and that makes it + difficult to reliably distinguish one application's record from + others, and for its parser to avoid problems when it encounters other + TXT records. + + Arguably, the TXT Resource Record is misnamed, and should have been + called the Local Container record, because a TXT Resource Record + means only what the data producer says it means. This is fine, so + long as TXT Resource Records are being used by human beings or by + private agreement between data producer and data consumer. However, + it becomes a problem once one starts using them for standardized + protocols in which there is no prior relationship between data + producer and data consumer. If TXT records are used without one of + the naming modifications discussed earlier (and in some cases even if + one uses such naming mechanisms), there is nothing to prevent + collisions with some other incompatible use of TXT Resource Records. + + This is even worse than the general subtyping problem described in + Section 3.1 because TXT Resource Records don't even have a + standardized selector field in which to store the subtype. RFC 1464 + [RFC1464] tried, but it was not a success. At best, a definition of + + + +IAB, et al. Informational [Page 12] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + a subtype is reduced to hoping that whatever scheme one has come up + with will not accidently conflict with somebody else's subtyping + scheme, and that it will not be possible to mis-parse one + application's use of TXT Resource Records as data intended for a + different application. Any attempt to impose a standardized format + within the TXT Resource Record format would be at least fifteen years + too late, even if it were put into effect immediately; at best, one + can restrict the syntax that a particular application uses within a + TXT Resource Record and accept the risk that unrelated TXT Resource + Record uses will collide with it. + + Using one of the naming modifications discussed in Section 3.2 and + Section 3.3 would address the subtyping problem, (and have been used + in combinations with reuse of TXT record, such as for the dns/txt + lookup mechanism in Domain Keys Identified Mail (DKIM)) but each of + these approaches brings in new problems of its own. The prefix + approach (that for example SRV Resource Records use) does not work + well with wildcards, which is a particular problem for mail-related + applications, since MX Resource Records are probably the most common + use of DNS wildcards. The suffix approach doesn't have wildcard + issues, but, as noted previously, it does have synchronization and + update authorization issues, since it works by creating a second + subtree in a different part of the global DNS namespace. + + The next reason why TXT Resource Records are not well suited to + protocol use has to do with the limited data space available in a DNS + message. As alluded to briefly in Section 3.1, typical DNS query + traffic patterns involve a very large number of DNS clients sending + queries to a relatively small number of DNS servers. Normal path MTU + discovery schemes do little good here because, from the server's + perspective, there isn't enough repeat traffic from any one client + for it to be worth retaining state. UDP-based DNS is an idempotent + query, whereas TCP-based DNS requires the server to keep state (in + the form of TCP connection state, usually in the server's kernel) and + roughly triples the traffic load. Thus, there's a strong incentive + to keep DNS messages short enough to fit in a UDP datagram, + preferably a UDP datagram short enough not to require IP + fragmentation. + + Subtyping schemes are therefore again problematic because they + produce larger Resource RRSets than necessary, but verbose text + encodings of data are also wasteful since the data they hold can + usually be represented more compactly in a Resource Record designed + specifically to support the application's particular data needs. If + the data that need to be carried are so large that there is no way to + make them fit comfortably into the DNS regardless of encoding, it is + probably better to move the data somewhere else, and just use the DNS + as a pointer to the data, as with NAPTR. + + + +IAB, et al. Informational [Page 13] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + +6. Conclusion and Recommendation + + Given the problems detailed in Section 5, it is worth reexamining the + oft-jumped-to conclusion that specifying a new Resource Record Type + is hard. Historically, this was indeed the case, but recent surveys + suggest that support for unknown Resource Record Types [RFC3597] is + now widespread in the public Internet, and because of that, the DNS + infrastructure can handle new Resource Record Types. The lack of + support for unknown Types remains an issue for relatively old + provisioning software and in corporate environments. + + Of all the issues detailed in Section 3.5, provisioning the data is + in some respects the most difficult. Investigations with zone + transfers show that the problem is less difficult for the + authoritative name servers themselves than the front-end systems used + to enter (and perhaps validate) the data. Hand editing does not work + well for maintenance of large zones, so some sort of tool is + necessary, and the tool may not be tightly coupled to the name server + implementation itself. Note, however, that this provisioning problem + exists to some degree with any new form of data to be stored in the + DNS, regardless of data format, Resource Record type (even if TXT + Resource Record Types are in use), or naming scheme. Adapting front- + end systems to support a new Resource Record Type may be a bit more + difficult than reusing an existing type, but this appears to be a + minor difference in degree rather than a difference in kind. + + Given the various issues described in this note, we believe that: + + o there is no magic solution that allows a completely painless + addition of new data to the DNS, but + + o on the whole, the best solution is still to use the DNS Resource + Record Type mechanism designed for precisely this purpose, + whenever possible, and + + o of all the alternate solutions, the "obvious" approach of using + TXT Resource Records for arbitrary names is almost certainly the + worst, especially for the two reasons outlined above (lack of + semantics and its implementations, and size leading to the need to + use TCP). + +7. Creating a New Resource Record Type + + The process for creating a new Resource Record Type is specified in + RFC 5395 [RFC5395]. + + + + + + +IAB, et al. Informational [Page 14] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + +8. Security Considerations + + DNS RRSets can be signed using DNSSEC. DNSSEC is almost certainly + necessary for any application mechanism that stores authorization + data in the DNS. DNSSEC signatures significantly increase the size + of the messages transported, and because of this, the DNS message + size issues discussed in Sections 3.1 and 5 are more serious than + they might at first appear. + + Adding new Resource Record Types (as discussed in Section 3.5) can + create two different kinds of problems: in the DNS software and in + applications. In the DNS software, it might conceivably trigger bugs + and other bad behavior in software that is not compliant with RFC + 3597 [RFC3597], but most such DNS software is old enough and insecure + enough that it should be updated for other reasons in any case. In + applications and provisioning software, the changes for the new + features that need the new data in the DNS can be updated to + understand the structure of the new data format (regardless of + whether a new Resource Record Type is used or some other mechanism is + chosen). Basic API support for retrieving arbitrary Resource Record + Types has been a requirement since 1989 [RFC1123]. + + Any new protocol that proposes to use the DNS to store data used to + make authorization decisions would be well advised not only to use + DNSSEC but also to encourage upgrades to DNS server software recent + enough not to be riddled with well-known exploitable bugs. + +9. Acknowledgements + + This document has been created over a number of years, with input + from many people. The question on how to expand and use the DNS is + sensitive, and a document like this can not please everyone. The + goal is instead to describe the architecture and tradeoffs, and make + some recommendations about best practices. + + People that have helped include: Dean Anderson, Mark Andrews, John + Angelmo, Roy Badami, Dan Bernstein, Alex Bligh, Nathaniel Borenstein, + Stephane Bortzmeyer, Brian Carpenter, Leslie Daigle, Elwyn Davies, + Mark Delany, Richard Draves, Martin Duerst, Donald Eastlake, Robert + Elz, Jim Fenton, Tony Finch, Jim Gilroy, Olafur Gudmundsson, Eric + Hall, Phillip Hallam-Baker, Ted Hardie, Bob Hinden, Paul Hoffman, + Geoff Houston, Christian Huitema, Johan Ihren, John Klensin, Ben + Laurie, William Leibzon, John Levine, Edward Lewis, David MacQuigg, + Allison Mankin, Bill Manning, David Meyer, Pekka Nikander, Mans + Nilsson, Masataka Ohta, Douglas Otis, Michael Patton, Jonathan + Rosenberg, Anders Rundgren, Miriam Sapiro, Carsten Strotmann, Pekka + Savola, Chip Sharp, James Snell, Michael Thomas, Paul Vixie, Sam + Weiler, Florian Weimer, Bert Wijnen, and Dan Wing. + + + +IAB, et al. Informational [Page 15] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + +10. IAB Members at the Time of This Writing + + Loa Andersson + Gonzalo Camarillo + Stuart Cheshire + Russ Housley + Olaf Kolkman + Gregory Lebovitz + Barry Leiba + Kurtis Lindqvist + Andrew Malis + Danny McPherson + David Oran + Dave Thaler + Lixia Zhang + +11. References + +11.1. Normative References + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1464] Rosenbaum, R., "Using the Domain Name System To + Store Arbitrary String Attributes", RFC 1464, + May 1993. + + [RFC2535] Eastlake, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource + Record (RR) Types", RFC 3597, September 2003. + + [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 5395, November 2008. + +11.2. Informative References + + [DNSEXT-DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", Work in Progress, September 2008. + + [Dyer87] Dyer, S. and F. Hsu, "Hesiod, Project Athena + Technical Plan - Name Service", Version 1.9, + April 1987. + + + + +IAB, et al. Informational [Page 16] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, + October 1989. + + [RFC1535] Gavron, E., "A Security Problem and Proposed + Correction With Widely Deployed DNS Software", + RFC 1535, October 1993. + + [RFC2163] Allocchio, C., "Using the Internet DNS to Distribute + MIXER Conformant Global Address Mapping (MCGAM)", + RFC 2163, January 1998. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", + RFC 2672, August 1999. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the + KEY Resource Record (RR)", RFC 3445, December 2002. + + [RFC3467] Klensin, J., "Role of the Domain Name System (DNS)", + RFC 3467, February 2003. + + [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform + Resource Identifiers (URI) Dynamic Delegation + Discovery System (DDDS) Application (ENUM)", + RFC 3761, April 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and + Requirements", RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Protocol Modifications for the DNS + Security Extensions", RFC 4035, March 2005. + + [RFC4511] Sermersheim, J., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name + System", RFC 4592, July 2006. + + + + + +IAB, et al. Informational [Page 17] + +RFC 5507 Design Choices When Expanding the DNS April 2009 + + + [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., + Fenton, J., and M. Thomas, "DomainKeys Identified + Mail (DKIM) Signatures", RFC 4871, May 2007. + +Authors' Addresses + + Internet Architecture Board + + EMail: iab@iab.org + + + Patrik Faltstrom (editor) + + EMail: paf@cisco.com + + + Rob Austein (editor) + + EMail: sra@isc.org + + + Peter Koch (editor) + + EMail: pk@denic.de + + + + + + + + + + + + + + + + + + + + + + + + + + + +IAB, et al. Informational [Page 18] + diff --git a/doc/rfc/rfc5625.txt b/doc/rfc/rfc5625.txt new file mode 100644 index 000000000000..102d7e8770ee --- /dev/null +++ b/doc/rfc/rfc5625.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group R. Bellis +Request for Comments: 5625 Nominet UK +BCP: 152 August 2009 +Category: Best Current Practice + + + DNS Proxy Implementation Guidelines + +Abstract + + This document provides guidelines for the implementation of DNS + proxies, as found in broadband gateways and other similar network + devices. + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + + + + + + + + + + + + + + + + + + + + + +Bellis Best Current Practice [Page 1] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. The Transparency Principle ......................................3 + 4. Protocol Conformance ............................................4 + 4.1. Unexpected Flags and Data ..................................4 + 4.2. Label Compression ..........................................4 + 4.3. Unknown Resource Record Types ..............................4 + 4.4. Packet Size Limits .........................................4 + 4.4.1. TCP Transport .......................................5 + 4.4.2. Extension Mechanisms for DNS (EDNS0) ................6 + 4.4.3. IP Fragmentation ....................................6 + 4.5. Secret Key Transaction Authentication for DNS (TSIG) .......7 + 5. DHCP's Interaction with DNS .....................................7 + 5.1. Domain Name Server (DHCP Option 6) .........................7 + 5.2. Domain Name (DHCP Option 15) ...............................8 + 5.3. DHCP Leases ................................................8 + 6. Security Considerations .........................................9 + 6.1. Forgery Resilience .........................................9 + 6.2. Interface Binding .........................................10 + 6.3. Packet Filtering ..........................................10 + 7. Acknowledgements ...............................................10 + 8. References .....................................................11 + 8.1. Normative References ......................................11 + 8.2. Informative References ....................................12 + +1. Introduction + + Research has found ([SAC035], [DOTSE]) that many commonly used + broadband gateways (and similar devices) contain DNS proxies that are + incompatible in various ways with current DNS standards. + + These proxies are usually simple DNS forwarders, but typically do not + have any caching capabilities. The proxy serves as a convenient + default DNS resolver for clients on the LAN, but relies on an + upstream resolver (e.g., at an ISP) to perform recursive DNS lookups. + + Note that to ensure full DNS protocol interoperability it is + preferred that client stub resolvers should communicate directly with + full-feature, upstream recursive resolvers wherever possible. + + That notwithstanding, this document describes the incompatibilities + that have been discovered and offers guidelines to implementors on + how to provide better interoperability in those cases where the + client must use the broadband gateway's DNS proxy. + + + + + +Bellis Best Current Practice [Page 2] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. The Transparency Principle + + It is not considered practical for a simple DNS proxy to implement + all current and future DNS features. + + There are several reasons why this is the case: + + o Broadband gateways usually have limited hardware resources. + + o Firmware upgrade cycles are long, and many users do not routinely + apply upgrades when they become available. + + o No one knows what those future DNS features will be or how they + might be implemented. + + o Doing so would substantially complicate the configuration user + interface (UI) of the device. + + Furthermore, some modern DNS protocol extensions (see, e.g., EDNS0 + below) are intended to be used as "hop-by-hop" mechanisms. If the + DNS proxy is considered to be such a "hop" in the resolution chain, + then for it to function correctly, it would need to be fully + compliant with all such mechanisms. + + [SAC035] shows that the more actively a proxy participates in the DNS + protocol, the more likely it is that it will somehow interfere with + the flow of messages between the DNS client and the upstream + recursive resolvers. + + The role of the proxy should therefore be no more and no less than to + receive DNS requests from clients on the LAN side, forward those + verbatim to one of the known upstream recursive resolvers on the WAN + side, and ensure that the whole response is returned verbatim to the + original client. + + It is RECOMMENDED that proxies should be as transparent as possible, + such that any "hop-by-hop" mechanisms or newly introduced protocol + extensions operate as if the proxy were not there. + + Except when required to enforce an active security or network policy + (such as maintaining a pre-authentication "walled garden"), end-users + SHOULD be able to send their DNS queries to specified upstream + + + +Bellis Best Current Practice [Page 3] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + resolvers, thereby bypassing the proxy altogether. In this case, the + gateway SHOULD NOT modify the DNS request or response packets in any + way. + +4. Protocol Conformance + +4.1. Unexpected Flags and Data + + The Transparency Principle above, when combined with Postel's + Robustness Principle [RFC0793], suggests that DNS proxies should not + arbitrarily reject or otherwise drop requests or responses based on + perceived non-compliance with standards. + + For example, some proxies have been observed to drop any packet + containing either the "Authentic Data" (AD) or "Checking Disabled" + (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035] + originally specified that these unused "Z" flag bits "MUST" be zero. + However, these flag bits were always intended to be reserved for + future use, so refusing to proxy any packet containing these flags + (now that uses for those flags have indeed been defined) is not + appropriate. + + Therefore, proxies MUST ignore any unknown DNS flags and proxy those + packets as usual. + +4.2. Label Compression + + Compression of labels as per Section 4.1.4 of [RFC1035] is optional. + + Proxies MUST forward packets regardless of the presence or absence of + compressed labels therein. + +4.3. Unknown Resource Record Types + + [RFC3597] requires that resolvers MUST handle Resource Records (RRs) + of unknown type transparently. + + All requests and responses MUST be proxied regardless of the values + of the QTYPE and QCLASS fields. + + Similarly, all responses MUST be proxied regardless of the values of + the TYPE and CLASS fields of any Resource Record therein. + +4.4. Packet Size Limits + + [RFC1035] specifies that the maximum size of the DNS payload in a UDP + packet is 512 octets. Where the required portions of a response + would not fit inside that limit, the DNS server MUST set the + + + +Bellis Best Current Practice [Page 4] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + "TrunCation" (TC) bit in the DNS response header to indicate that + truncation has occurred. There are however two standard mechanisms + (described in Sections 4.4.1 and 4.4.2) for transporting responses + larger than 512 octets. + + Many proxies have been observed to truncate all responses at 512 + octets, and others at a packet size related to the WAN MTU, in either + case doing so without correctly setting the TC bit. + + Other proxies have been observed to remove the TC bit in server + responses that correctly had the TC bit set by the server. + + If a DNS response is truncated but the TC bit is not set, then client + failures may result. In particular, a naive DNS client library might + suffer crashes due to reading beyond the end of the data actually + received. + + Since UDP packets larger than 512 octets are now expected in normal + operation, proxies SHOULD NOT truncate UDP packets that exceed that + size. See Section 4.4.3 for recommendations for packet sizes + exceeding the WAN MTU. + + If a proxy must unilaterally truncate a response, then the proxy MUST + set the TC bit. Similarly, proxies MUST NOT remove the TC bit from + responses. + +4.4.1. TCP Transport + + Should a UDP query fail because of truncation, the standard fail-over + mechanism is to retry the query using TCP, as described in Section + 6.1.3.2 of [RFC1123]. + + Whilst TCP transport is not strictly mandatory, it is supported by + the vast majority of stub resolvers and recursive servers. Lack of + support in the proxy prevents this fail-over mechanism from working. + + DNS proxies MUST therefore be prepared to receive and forward queries + over TCP. + + Note that it is unlikely that a client would send a request over TCP + unless it had already received a truncated UDP response. Some + "smart" proxies have been observed to first forward any request + received over TCP to an upstream resolver over UDP, only for the + response to be truncated, causing the proxy to retry over TCP. Such + behaviour increases network traffic and causes delay in DNS + resolution since the initial UDP request is doomed to fail. + + + + + +Bellis Best Current Practice [Page 5] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + Therefore, whenever a proxy receives a request over TCP, the proxy + SHOULD forward the query over TCP and SHOULD NOT attempt the same + query over UDP first. + +4.4.2. Extension Mechanisms for DNS (EDNS0) + + The "Extension Mechanism for DNS" [RFC2671] was introduced to allow + the transport of larger DNS packets over UDP and also to allow for + additional request and response flags. + + A client may send an OPT Resource Record (OPT RR) in the Additional + Section of a request to indicate that it supports a specific receive + buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used + by DNSSEC to indicate that DNSSEC-related RRs should be returned to + the client. + + However, some proxies have been observed to either reject (with a + FORMERR response code) or black-hole any packet containing an OPT RR. + As per Section 4.1, proxies MUST NOT refuse to proxy such packets. + +4.4.3. IP Fragmentation + + Support for UDP packet sizes exceeding the WAN MTU depends on the + gateway's algorithm for handling fragmented IP packets. Several + methods are possible: + + 1. Fragments are dropped. + + 2. Fragments are forwarded individually as they're received. + + 3. Complete packets are reassembled on the gateway and then re- + fragmented (if necessary) as they're forwarded to the client. + + Method 1 above will cause compatibility problems with EDNS0 unless + the DNS client is configured to advertise an EDNS0 buffer size + limited to the WAN MTU less the size of the IP header. Note that RFC + 2671 does recommend that the path MTU should be taken into account + when using EDNS0. + + Also, whilst the EDNS0 specification allows for a buffer size of up + to 65535 octets, most common DNS server implementations do not + support a buffer size above 4096 octets. + + Therefore (irrespective of which of the above methods is in use), + proxies SHOULD be capable of forwarding UDP packets up to a payload + size of at least 4096 octets. + + + + + +Bellis Best Current Practice [Page 6] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + NB: in theory, IP fragmentation may also occur if the LAN MTU is + smaller than the WAN MTU, although the author has not observed such a + configuration in use on any residential broadband service. + +4.5. Secret Key Transaction Authentication for DNS (TSIG) + + [RFC2845] defines TSIG, which is a mechanism for authenticating DNS + requests and responses at the packet level. + + Any modifications made to the DNS portions of a TSIG-signed query or + response packet (with the exception of the Query ID) will cause a + TSIG authentication failure. + + DNS proxies MUST implement Section 4.7 of [RFC2845] and either + forward packets unchanged (as recommended above) or fully implement + TSIG. + + As per Section 4.3, DNS proxies MUST be capable of proxying packets + containing TKEY [RFC2930] Resource Records. + + NB: any DNS proxy (such as those commonly found in WiFi hotspot + "walled gardens") that transparently intercepts all DNS queries and + that returns unsigned responses to signed queries, will also cause + TSIG authentication failures. + +5. DHCP's Interaction with DNS + + Whilst this document is primarily about DNS proxies, most consumers + rely on DHCP [RFC2131] to obtain network configuration settings. + Such settings include the client machine's IP address, subnet mask, + and default gateway, but also include DNS-related settings. + + It is therefore appropriate to examine how DHCP affects client DNS + configuration. + +5.1. Domain Name Server (DHCP Option 6) + + Most gateways default to supplying their own IP address in the DHCP + "Domain Name Server" option [RFC2132]. The net result is that + without explicit re-configuration many DNS clients will, by default, + send queries to the gateway's DNS proxy. This is understandable + behaviour given that the correct upstream settings are not usually + known at boot time. + + + + + + + + +Bellis Best Current Practice [Page 7] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + Most gateways learn their own DNS settings via values supplied by an + ISP via DHCP or PPP over the WAN interface. However, whilst many + gateways do allow the device administrator to override those values, + some gateways only use those supplied values to affect the proxy's + own forwarding function, and do not offer these values via DHCP. + + When using such a device, the only way to avoid using the DNS proxy + is to hard-code the required values in the client operating system. + This may be acceptable for a desktop system but it is inappropriate + for mobile devices that are regularly used on many different + networks. + + As per Section 3, end-users SHOULD be able to send their DNS queries + directly to specified upstream resolvers, ideally without hard-coding + those settings in their stub resolver. + + It is therefore RECOMMENDED that gateways SHOULD support device- + administrator configuration of values for the "Domain Name Server" + DHCP option. + +5.2. Domain Name (DHCP Option 15) + + A significant amount of traffic to the DNS Root Name Servers is for + invalid top-level domain names, and some of that traffic can be + attributed to particular equipment vendors whose firmware defaults + this DHCP option to specific values. + + Since no standard exists for a "local" scoped domain name suffix, it + is RECOMMENDED that the default value for this option SHOULD be + empty, and that this option MUST NOT be sent to clients when no value + is configured. + +5.3. DHCP Leases + + It is noted that some DHCP servers in broadband gateways offer, by + default, their own IP address for the "Domain Name Server" option (as + described above) but then automatically start offering the upstream + servers' addresses once they've been learnt over the WAN interface. + + In general, this behaviour is highly desirable, but the effect for + the end-user is that the settings used depend on whether the DHCP + lease was obtained before or after the WAN link was established. + + If the DHCP lease is obtained whilst the WAN link is down, then the + DHCP client (and hence the DNS client) will not receive the correct + values until the DHCP lease is renewed. + + + + + +Bellis Best Current Practice [Page 8] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + Whilst no specific recommendations are given here, vendors may wish + to give consideration to the length of DHCP leases and to whether + some mechanism for forcing a DHCP lease renewal might be appropriate. + + Another possibility is that the learnt upstream values might be + persisted in non-volatile memory such that on reboot the same values + can be automatically offered via DHCP. However, this does run the + risk that incorrect values are initially offered if the device is + moved or connected to another ISP. + + Alternatively, the DHCP server might only issue very short (i.e., 60 + second) leases while the WAN link is down, only reverting to more + typical lease lengths once the WAN link is up and the upstream DNS + servers are known. Indeed, with such a configuration it may be + possible to avoid the need to implement a DNS proxy function in the + broadband gateway at all. + +6. Security Considerations + + This document introduces no new protocols. However, there are some + security-related recommendations for vendors that are listed here. + +6.1. Forgery Resilience + + Whilst DNS proxies are not usually full-feature resolvers, they + nevertheless share some characteristics with them. + + Notwithstanding the recommendations above about transparency, many + DNS proxies are observed to pick a new Query ID for outbound requests + to ensure that responses are directed to the correct client. + + NB: changing the Query ID is acceptable and compatible with proxying + TSIG-signed packets since the TSIG signature calculation is based on + the original message ID, which is carried in the TSIG RR. + + It has been standard guidance for many years that each DNS query + should use a randomly generated Query ID. However, many proxies have + been observed picking sequential Query IDs for successive requests. + + It is strongly RECOMMENDED that DNS proxies follow the relevant + recommendations in [RFC5452], particularly those in Section 9.2 + relating to randomisation of Query IDs and source ports. This also + applies to source port selection within any NAT function. + + If a DNS proxy is running on a broadband gateway with NAT that is + compliant with [RFC4787], then it SHOULD also follow the + recommendations in Section 10 of [RFC5452] concerning how long DNS + state is kept. + + + +Bellis Best Current Practice [Page 9] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + +6.2. Interface Binding + + Some gateways have been observed to have their DNS proxy listening on + both internal (LAN) and external (WAN) interfaces. In this + configuration, it is possible for the proxy to be used to mount + reflector attacks as described in [RFC5358]. + + The DNS proxy in a gateway SHOULD NOT, by default, be accessible from + the WAN interfaces of the device. + +6.3. Packet Filtering + + The Transparency and Robustness Principles are not entirely + compatible with the deep packet-inspection features of security + appliances such as firewalls, which are intended to protect systems + on the inside of a network from rogue traffic. + + However, a clear distinction may be made between traffic that is + intrinsically malformed and that which merely contains unexpected + data. + + Examples of malformed packets that MAY be dropped include: + + o invalid compression pointers (i.e., those that point outside of + the current packet or that might cause a parsing loop) + + o incorrect counts for the Question, Answer, Authority, and + Additional Sections (although care should be taken where + truncation is a possibility) + + Dropped packets will cause the client to repeatedly retransmit the + original request, with the client only detecting the error after + several retransmit intervals. + + In these circumstances, proxies SHOULD synthesise a suitable DNS + error response to the client (i.e., SERVFAIL) instead of dropping the + packet completely. This will allow the client to detect the error + immediately. + +7. Acknowledgements + + The author would particularly like to acknowledge the assistance of + Lisa Phifer of Core Competence. In addition, the author is grateful + for the feedback from the members of the DNSEXT Working Group. + + + + + + + +Bellis Best Current Practice [Page 10] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + +8. References + +8.1. Normative References + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - Application + and Support", STD 3, RFC 1123, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", + RFC 2671, August 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive + Nameservers in Reflector Attacks", BCP 140, RFC 5358, + October 2008. + + + + + +Bellis Best Current Practice [Page 11] + +RFC 5625 DNS Proxy Implementation Guidelines August 2009 + + + [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More + Resilient against Forged Answers", RFC 5452, January 2009. + +8.2. Informative References + + [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband + Routers", February 2008, + <http://www.iis.se/docs/Routertester_en.pdf>. + + [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on + Broadband Routers and Firewalls", September 2008, + <http://www.icann.org/committees/security/sac035.pdf>. + +Author's Address + + Ray Bellis + Nominet UK + Edmund Halley Road + Oxford OX4 4DQ + United Kingdom + + Phone: +44 1865 332211 + EMail: ray.bellis@nominet.org.uk + URI: http://www.nominet.org.uk/ + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bellis Best Current Practice [Page 12] + diff --git a/doc/rfc/rfc5702.txt b/doc/rfc/rfc5702.txt new file mode 100644 index 000000000000..5155cc6440c8 --- /dev/null +++ b/doc/rfc/rfc5702.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group J. Jansen +Request for Comments: 5702 NLnet Labs +Category: Standards Track October 2009 + + + Use of SHA-2 Algorithms with RSA in + DNSKEY and RRSIG Resource Records for DNSSEC + +Abstract + + This document describes how to produce RSA/SHA-256 and RSA/SHA-512 + DNSKEY and RRSIG resource records for use in the Domain Name System + Security Extensions (RFC 4033, RFC 4034, and RFC 4035). + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the BSD License. + + + + + + + + + + + + + + + +Jansen Standards Track [Page 1] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. DNSKEY Resource Records .........................................3 + 2.1. RSA/SHA-256 DNSKEY Resource Records ........................3 + 2.2. RSA/SHA-512 DNSKEY Resource Records ........................3 + 3. RRSIG Resource Records ..........................................3 + 3.1. RSA/SHA-256 RRSIG Resource Records .........................4 + 3.2. RSA/SHA-512 RRSIG Resource Records .........................4 + 4. Deployment Considerations .......................................5 + 4.1. Key Sizes ..................................................5 + 4.2. Signature Sizes ............................................5 + 5. Implementation Considerations ...................................5 + 5.1. Support for SHA-2 Signatures ...............................5 + 5.2. Support for NSEC3 Denial of Existence ......................5 + 6. Examples ........................................................6 + 6.1. RSA/SHA-256 Key and Signature ..............................6 + 6.2. RSA/SHA-512 Key and Signature ..............................7 + 7. IANA Considerations .............................................8 + 8. Security Considerations .........................................8 + 8.1. SHA-1 versus SHA-2 Considerations for RRSIG + Resource Records ...........................................8 + 8.2. Signature Type Downgrade Attacks ...........................8 + 9. Acknowledgments .................................................9 + 10. References .....................................................9 + 10.1. Normative References ......................................9 + 10.2. Informative References ....................................9 + +1. Introduction + + The Domain Name System (DNS) is the global, hierarchical distributed + database for Internet Naming. The DNS has been extended to use + cryptographic keys and digital signatures for the verification of the + authenticity and integrity of its data. [RFC4033], [RFC4034], and + [RFC4035] describe these DNS Security Extensions, called DNSSEC. + + RFC 4034 describes how to store DNSKEY and RRSIG resource records, + and specifies a list of cryptographic algorithms to use. This + document extends that list with the algorithms RSA/SHA-256 and RSA/ + SHA-512, and specifies how to store DNSKEY data and how to produce + RRSIG resource records with these hash algorithms. + + Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family + of algorithms is assumed in this document. + + + + + + + +Jansen Standards Track [Page 2] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + + To refer to both SHA-256 and SHA-512, this document will use the name + SHA-2. This is done to improve readability. When a part of text is + specific for either SHA-256 or SHA-512, their specific names are + used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be + grouped using the name RSA/SHA-2. + + The term "SHA-2" is not officially defined but is usually used to + refer to the collection of the algorithms SHA-224, SHA-256, SHA-384, + and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2 + will only refer to SHA-256 and SHA-512 in this document. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. DNSKEY Resource Records + + The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110] + describes the use of RSA/SHA-1 for DNSSEC signatures. + +2.1. RSA/SHA-256 DNSKEY Resource Records + + RSA public keys for use with RSA/SHA-256 are stored in DNSKEY + resource records (RRs) with the algorithm number 8. + + For interoperability, as in [RFC3110], the key size of RSA/SHA-256 + keys MUST NOT be less than 512 bits and MUST NOT be more than 4096 + bits. + +2.2. RSA/SHA-512 DNSKEY Resource Records + + RSA public keys for use with RSA/SHA-512 are stored in DNSKEY + resource records (RRs) with the algorithm number 10. + + The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and + MUST NOT be more than 4096 bits. + +3. RRSIG Resource Records + + The value of the signature field in the RRSIG RR follows the RSASSA- + PKCS1-v1_5 signature scheme and is calculated as follows. The values + for the RDATA fields that precede the signature data are specified in + [RFC4034]. + + + + + + + + +Jansen Standards Track [Page 3] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + + hash = SHA-XXX(data) + + Here XXX is either 256 or 512, depending on the algorithm used, as + specified in FIPS PUB 180-3; "data" is the wire format data of the + resource record set that is signed, as specified in [RFC4034]. + + signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) + + Here "|" is concatenation; "00", "01", "FF", and "00" are fixed + octets of corresponding hexadecimal value; "e" is the private + exponent of the signing RSA key; and "n" is the public modulus of the + signing key. The FF octet MUST be repeated the exact number of times + so that the total length of the concatenated term in parentheses + equals the length of the modulus of the signer's public key ("n"). + + The "prefix" is intended to make the use of standard cryptographic + libraries easier. These specifications are taken directly from the + specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of + [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2 + of [RFC3447]). The prefixes for the different algorithms are + specified below. + +3.1. RSA/SHA-256 RRSIG Resource Records + + RSA/SHA-256 signatures are stored in the DNS using RRSIG resource + records (RRs) with algorithm number 8. + + The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as + specified in PKCS #1 v2.1 [RFC3447]: + + hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 + +3.2. RSA/SHA-512 RRSIG Resource Records + + RSA/SHA-512 signatures are stored in the DNS using RRSIG resource + records (RRs) with algorithm number 10. + + The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as + specified in PKCS #1 v2.1 [RFC3447]: + + hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 + + + + + + + + + + +Jansen Standards Track [Page 4] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + +4. Deployment Considerations + +4.1. Key Sizes + + Apart from the restrictions in Section 2, this document will not + specify what size of keys to use. That is an operational issue and + depends largely on the environment and intended use. A good starting + point for more information would be NIST SP 800-57 [NIST800-57]. + +4.2. Signature Sizes + + In this family of signing algorithms, the size of signatures is + related to the size of the key and not to the hashing algorithm used + in the signing process. Therefore, RRSIG resource records produced + with RSA/SHA-256 or RSA/SHA-512 will have the same size as those + produced with RSA/SHA-1, if the keys have the same length. + +5. Implementation Considerations + +5.1. Support for SHA-2 Signatures + + DNSSEC-aware implementations SHOULD be able to support RRSIG and + DNSKEY resource records created with the RSA/SHA-2 algorithms as + defined in this document. + +5.2. Support for NSEC3 Denial of Existence + + [RFC5155] defines new algorithm identifiers for existing signing + algorithms, to indicate that zones signed with these algorithm + identifiers can use NSEC3 as well as NSEC records to provide denial + of existence. That mechanism was chosen to protect implementations + predating RFC 5155 from encountering resource records about which + they could not know. This document does not define such algorithm + aliases. + + A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate + negative answers in the form of both NSEC and NSEC3 with hash + algorithm 1, as defined in [RFC5155]. An authoritative server that + does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 + with NSEC denial of existence. + + + + + + + + + + + +Jansen Standards Track [Page 5] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + +6. Examples + +6.1. RSA/SHA-256 Key and Signature + + Given a private key with the following values (in Base64): + + Private-key-format: v1.2 + Algorithm: 8 (RSASHA256) + Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm + idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q== + PublicExponent: AQAB + PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/ + HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ== + Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk= + Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE= + Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk= + Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE= + Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q= + + The DNSKEY record for this key would be: + + example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI + my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P + kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b} + + With this key, sign the following RRSet, consisting of 1 A record: + + www.example.net. 3600 IN A 192.0.2.91 + + If the inception date is set at 00:00 hours on January 1st, 2000, and + the expiration date at 00:00 hours on January 1st, 2030, the + following signature should be created: + + www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000 + 20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9 + l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa + cFYK/lPtPiVYP4bwg==);{id = 9033} + + + + + + + + + + + + + + +Jansen Standards Track [Page 6] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + +6.2. RSA/SHA-512 Key and Signature + + Given a private key with the following values (in Base64): + + Private-key-format: v1.2 + Algorithm: 10 (RSASHA512) + Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf + Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk + 8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V + jXZlNKdyit99waaE4s= + PublicExponent: AQAB + PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6 + AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj + yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3 + SEIAsrB043XzGrKIVE= + Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x + nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ== + Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK + Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw== + Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM + MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q== + Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J + PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w== + Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q + /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ== + + The DNSKEY record for this key would be: + + example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD + p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD + xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g + pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL + );{id = 3740 (zsk), size = 1024b} + + With this key, sign the following RRSet, consisting of 1 A record: + + www.example.net. 3600 IN A 192.0.2.91 + + If the inception date is set at 00:00 hours on January 1st, 2000, and + the expiration date at 00:00 hours on January 1st, 2030, the + following signature should be created: + + www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000 + 20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t + 6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa + eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL + DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw + =);{id = 3740} + + + +Jansen Standards Track [Page 7] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + +7. IANA Considerations + + This document updates the IANA registry "DNS SECURITY ALGORITHM + NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The + following entries are added to the registry: + + Zone Trans. + Value Description Mnemonic Signing Sec. References + 8 RSA/SHA-256 RSASHA256 Y * RFC 5702 + 10 RSA/SHA-512 RSASHA512 Y * RFC 5702 + + * There has been no determination of standardization of the use of + this algorithm with Transaction Security. + +8. Security Considerations + +8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records + + Users of DNSSEC are encouraged to deploy SHA-2 as soon as software + implementations allow for it. SHA-2 is widely believed to be more + resilient to attack than SHA-1, and confidence in SHA-1's strength is + being eroded by recently announced attacks. Regardless of whether or + not the attacks on SHA-1 will affect DNSSEC, it is believed (at the + time of this writing) that SHA-2 is the better choice for use in + DNSSEC records. + + SHA-2 is considered sufficiently strong for the immediate future, but + predictions about future development in cryptography and + cryptanalysis are beyond the scope of this document. + + The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one + used for RSA/SHA-1 signatures. This should ease implementation of + the new hashing algorithms in DNSSEC software. + +8.2. Signature Type Downgrade Attacks + + Since each RRSet MUST be signed with each algorithm present in the + DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a + malicious party cannot filter out the RSA/SHA-2 RRSIG and force the + validator to use the RSA/SHA-1 signature if both are present in the + zone. This should provide resilience against algorithm downgrade + attacks, if the validator supports RSA/SHA-2. + + + + + + + + + +Jansen Standards Track [Page 8] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + +9. Acknowledgments + + This document is a minor extension to [RFC4034]. Also, we try to + follow the documents [RFC3110] and [RFC4509] for consistency. The + authors of and contributors to these documents are gratefully + acknowledged for their hard work. + + The following people provided additional feedback and text: Jaap + Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont, + Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose, + Michael St. Johns, and Wouter Wijngaards. + +10. References + +10.1. Normative References + + [FIPS.180-3.2008] + National Institute of Standards and Technology, "Secure + Hash Standard", FIPS PUB 180-3, October 2008. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + +10.2. Informative References + + [NIST800-57] + Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, + "Recommendations for Key Management", NIST SP 800-57, + March 2007. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + + +Jansen Standards Track [Page 9] + +RFC 5702 DNSSEC RSA/SHA-2 October 2009 + + + [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer + (DS) Resource Records (RRs)", RFC 4509, May 2006. + + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + +Author's Address + + Jelte Jansen + NLnet Labs + Science Park 140 + 1098 XG Amsterdam + NL + + EMail: jelte@NLnetLabs.nl + URI: http://www.nlnetlabs.nl/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Jansen Standards Track [Page 10] + |