]> Dyn, Inc.

150 Dow St Manchester NH 03101 U.S.A. asullivan@dyn.com

Some clients on the Internet make inferences about the administrative relationships among servers on the Internet based on the domain names of those servers. Perhaps unfortunately, it is not currently possible to detect the real administrative boundaries in the DNS, and therefore such inferences can go wrong in several ways. Mitigation strategies deployed so far will not scale. The solution to this is to provide a way to make an explicit assertion about the relationships between different domain names and perhaps the services provided at them.

Many network resources are accessed primarily by name. DNS names make up the bulk of those names. As a result, DNS names have become fundamental elements in building security policies and user agent behaviour. For example, domain names are used in attempts to determine the scope for data sharing of HTTP state management cookies . The idea is to foil the attempts of attackers in (for example) attackersite.co.tld from setting cookies for everyone in co.tld. Another example policy is a user interface convention that purports to display the "real" domain name differently from other parts of the fully-qualified domain name, in an effort to decrease the success of phishing attacks. In this strategy, for instance, a domain name like "www.bank.example.com.attackersite.tld" is formatted to highlight that the name is inside "attackersite.tld", in the hope of thereby reducing the user's impression of visiting "www.bank.example.com". Issuers of X.509 certificates make judgements about administrative boundaries around domains when issuing the certificates. For some discussion of the relationship between DNS names and X.509 certificates, see . One way to build a reasonable policy is to treat each different domain name distinctly. Under this approach, foo.example.org, bar.example.org, and baz.example.org are all just different domains. Such an approach can be awkward, however, when (as is often the case) the real administrative boundary is a shared one (in this example, example.org). Therefore, clients have attempted to make more sophisticated policies. Historically, policies were sometimes based on the DNS tree. Early policies made a firm distinction between top-level domains and everything else; but this was too naive, and later attempts were based on inferences from the DNS names themselves. That did not work well, because there is no way in the DNS to discover the boundaries of administrative control around domain names. Some have attempted to use the boundary of zone cuts (i.e. the location of the zone's apex, which is at the SOA record; see and ). Unfortunately, that boundary is neither necessary nor sufficient for these purposes: it is possible for a large site to have many, administratively distinct subdomain-named sites without inserting an SOA record, and it is also possible that an administrative entity (like a company) might divide its domain up into different zones for administrative reasons unrelated to the purposes of sites named in that domain. It was also, prior to the advent of DNSSEC, difficult to find zone cuts. Regardless, the location of a zone cut is an administrative matter to do with the operation of the DNS itself, and not useful for determining relationships among services offered at names in the DNS. What appears to be needed is a mechanism to determine administrative boundaries in the DNS. That is, given services at two domain names, one needs to be able to answer whether the first and the second are under the same administrative control and same administrative policies. We may call this state of affairs "lying within the same policy realm". We may suppose that, if this information were to be available, it would be possible to make useful decisions based on the information. A particularly important distinction for security purposes is the one between names that are mostly used to contain other domains, as compared to those that are mostly used to operate services. The former are often "delegation-centric" domains, delegating parts of their name space to others, and are frequently called "public suffix" domains or "effective TLDs". The term "public suffix" comes from a site, publicsuffix.org, that publishes a list of domains (henceforth, the "public suffix list") that are used to contain other domains. Not all, but most, delegation-centric domains are public suffix domains; and not all public suffix domains need to do DNS delegation, although most of them do. The reason for the public suffix list is to make the distinction between names that must never be treated as being in the same policy realm as another, and those that might be so treated. For instance, if "com" is on the public suffix list, that means that "example.com" lies in a policy realm distinct from that of com. Unfortunately, the public suffix list has several inherent limitations. To begin with, it is a list that is separately maintained from the list of DNS delegations. As a result, the data in the public suffix list can diverge from the actual use of the DNS. Second, because its semantics are not the same as those of the DNS, it does not capture unusual features of the DNS that are a consequence of its structure (see for background on that structure). Third, as the size of the root zone grows, keeping the list both accurate and synchronized with the expanding services will become difficult and unreliable. Perhaps most importantly, it puts the power of assertion about the operational policies of a domain outside the control of the operators of that domain, and in the control of a third party possibly unrelated to those operators. There have been suggestions for improvements of the public suffix list, most notably in . It is unclear the extent to which those improvements would help, because they represent improvements on the fundamental mechanism of keeping metadata about the DNS tree apart from the DNS tree itself.

The reader is assumed to be familiar with the DNS ( ) and DNSSEC ( ). 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. describes the mechanism in general terms, outlining two different possible approaches and outlining the compromises in each case. Definitions of the new RRTYPE is in , with two different definitions to allow for the two different approaches. There is some general discussion of the use of the RRTYPE is in . Then, offers an example portion of a DNS tree that can be used to understand the ways in which the mechanism can be used to draw inferences about administrative relationships. notes some limitations of the mechanism. outlines how the mechanism might be used securely.

This memo presents a way to assert a common administrative realm by placing a resource record (RR) at DNS names within the policy realm. The mechanism requires a new resource record type (RRTYPE) to enable these assertions, called SOPA (for Start Of Policy Authority, echoing the Start Of Authority or SOA record). While there are reported difficulties in deploying new RRTYPEs, the only RRTYPE that could be used to express all the necessary variables is the TXT record, and it is unsuitable because it can also be used for other purposes. The use of this mechanism does not require "underscore labels" to scope the interpretation of the RR, in order to make it possible to use the mechanism where the underscore label convention is already in use. The SOPA RRTYPE is class-independent. While many policies of the sort discussed in appear to be based on domain names, they are actually only partly based on them. Usually, there are implicit rules that come from the destination port or scheme (or both) in use. It is possible to make those assumptions explicit, but at the cost of expressing in the resulting record a tighter relationship between the DNS and the services offered at DNS names. There are arguments to be made for each approach. and explore the two different approaches; this memo does not make a decision about which strategy to adopt. If there are future developments of this memo, one strategy will be selected. It is worth observing that a policy realm relationship ought to be symmetric: if example.com is in the same policy realm as example.net, then example.net should be (it would seem) in the same policy realm as example.com. In principle, then, if a SOPA RR at example.com provides a target at example.net, there should be a complementary SOPA RR at example.net with a target of example.com. Because of the distributed nature of the DNS, and because the other administrative divisions need not follow the policy realms, the only way to know whether two names are in the same policy realm is to query at each name, and to correlate the responses.

The first approach provides, as the RDATA of a SOPA RR, a target name that lies in the same policy realm as the owner name in the RR. For convenience, in what follows this is sometimes called this the "names-only" strategy. Such an approach is an assertion on the part of the authoritative DNS server for the owner name in question that there is a policy relationship between that owner name and the target name. If a single name lies in the same policy realm as several other target names, an additional RR is necessary for each such relationship, with one exception. It is not uncommon for two different names to have policy relationships among all the children beneath them. Using the SOPA RR, it is possible to specify that the target is all the names beneath a name, using a wildcard target. This approach follows the traditional way that relationships are expressed in the DNS, which is historically mostly between different names. Aliases, for instance, redirect names or trees, and not names or trees for specific RRTYPEs. It has the disadvantage, however, that it may not provide enough information about the relationship between two names to make all the inferences one might need about the relationship. For instance, the relationship between two hosts might depend on the protocol, port, and scheme in use: two domains might share policy for the purposes of connections on port 80, but for no other connections. Could this be capured by using SRV or NAPTR records on both sides of the policy relationship? Too slow?

The second approach provides, as the RDATA of a SOPA RR, a target name that lies in the same policy realm as the owner name in the RR, but can identify the relationship as pertaining only to certain ports and schemes. In what follows, for convenience this is sometimes called the "port-and-scheme" stragegy. It provides a way to cover ranges of ports with a single resource record, and to cover all schemes and ports with a single resource record. It does not, however, permit arbitrary combinations of destination point and schemes without using more than one RR. This approach offers a mechanism to express relationships between services at a domain name instead of merely between names. As a disadvantage, however, it seems to step outside the usual scope of the DNS, which concerns itself with names and not services offered at those names. It might be argued that some RRTYPEs (notably SRV and NAPTR ) do relate to services; but in those cases, it is an expression of services available at an already-named host. It would be a significant innovation, perhaps in a bad direction, to attempt to express these relationships in a single RR. Since the names are under different administration, also, it is entirely possible that the operators of the two domains do not agree on the port ranges and schemas to be supported, creating an intractable comparison problem for a client.

Because of the two approaches outlined in and , this section provides two different outlines of the SOPA resource record. This arrangement is pending the decision about which strategy to adopt, at which time the discussion below will be reduced to reflect that decision.

In this case, the SOPA resource record, type number [TBD1], includes the following fields: The owner name of the RR. The time to live for the RR. The CLASS for the RR. As of this writing, on the contemporary Internet this is almost always "IN", but the SOPA RR is class-independent. The RRTYPE field. A DNS name relative to the root that is in the same policy realm as the SOPA RR's owner name. The name MUST be a DNS name according to the rules in and , except that the left-most label of the target MAY be the wildcard character ("*"). In addition, the target may be "."; in that case, the RR asserts that there are no other names in the same policy realm. For further discussion, see . The target MUST NOT be an alias , such as the owner name of a CNAME , DNAME , or other similar such resource records. The SOPA RRTYPE's wire format is as follows: To follow if this idea (and this version of it) turns out worth pursuing. It can be derived from above, however.

In this case, the SOPA resource record, type number [TBD1], includes the following fields: The owner name of the RR. The time to live for the RR. The CLASS for the RR. As of this writing, on the contemporary Internet this is almost always "IN", but the SOPA RR is class-independent. The RRTYPE field. The port number that begins the range to which this SOPA RR applies. This is a 16 bit unsigned integer in network byte order. The range is 0-65535. The port number that ends the range for which this SOPA RR applies. This is a 16 bit unsigned integer in network byte order. The range is 0-65535. The scheme to which the SOPA RR applies. The scheme SHOULD be listed in the IANA Uniform Resource Identifier (URI) Schemes registry. This is "SHOULD" right now, but I think it should be "MUST". I can't think of a reason why not to make it MUST. Alternatively, the field may contain the special value "*", in which case the SOPA RR applies to all schemes, with a limitation: some clients use certain schemes only for internal operations, and regardless of whether those schemes are included in an SOPA RR, they MAY be ignored. A DNS name relative to the root that is in the same policy realm as the SOPA RR's owner name. The name MUST be a DNS name according to the rules in and , except that the left-most label of the target MAY be the wildcard character ("*"). In addition, the target may be "."; in that case, the RR asserts that there are no other names in the same policy realm. For further discussion, see . The target MUST NOT be an alias , such as the owner name of a CNAME , DNAME , or other similar such resource records. The SOPA RRTYPE's wire format is as follows: To follow if this idea (and this version of it) turns out worth pursuing. It can be derived from above, however.

SOPA RRs may have, in effect, three different functions. The simplest is to make an assertion that two DNS names are in the same policy realm. Under the port-and-scheme strategy, if the Starting Port is 0, the Ending Port is 65535, the Scheme is "*", and the Target is anything other than ".", then the SOPA record makes a claim that the owner name and the target name are in the same policy realm in every case. This is also the claim whenever the names-only stragey is in use, and the RDATA has a target other than ".". The second function, available only under the port-and-scheme strategy, is to make an assertion that two DNS names are in the same policy realm, but only for some subset of ports or schemes or both. There is a 1:1 port mapping presumed in the way the SOPA RR is structured, such that it is not possible to say that port N at the owner name is related to port M at the target name. This is an expedient for simplicity. For the same reasons of simplicity, the SOPA RR permits linking all schemes between names, or else one scheme; a given RR does not permit listing more than one scheme without using the wildcard selector. The third function is to make an assertion that no other name lies in the same policy realm as the owner name. If there are names beneath that owner name, this is a way for a DNS operator to assert that the owner name is a public suffix. For more details, see . There could be more than one SOPA resource record per owner name in a response. Each domain name in the RDATA is treated as a part of the same policy realm as the owner name in the original QNAME (subject to the qualifications of scheme and port contained in the SOPA RR in the port-and-scheme strategy). The QNAME from the query might not be the owner name of the SOPA RR: if the original QNAME was an alias, then the SOPA owner name will be different. There are three possible responses to a query for the SOPA RRTYPE at an owner name that are relevant to determining the policy realm. The first is Name Error (RCODE=3, also known as NXDOMAIN). In this case, the owner name itself does not exist, and no further processing is needed. The second is a No Data response of any type. The No Data response means that the owner name in the QNAME does not recognize any other name as part of a common policy realm. The final is a response with one or more SOPA resource records in the Answer section. Each SOPA resource record asserts a relationship between the owner name and the target name, according to the functions of the SOPA RRTYPE outlined above. Any other response is no different from any other sort of response from the DNS, and is not in itself meaningful for determining the policy realm of a name (though it might be meaningful for finding the SOPA record).

An SOPA resource record with the single character "." (called the "root target") in the RDATA is a positive assertion that no other domain name falls inside the policy realm of the owner name. The record has a special use: it may be used to bootstrap operation. A client that has encountered the root target may remember the existence of the root target even after the expiry of the TTL on the RRset, until such time as a new query for the owner name may be made successfully. This rule permits implementations to cache positive statements of administrative isolation during disconnected periods, thereby starting a subsequent session with the values of prior affirmed policy. Apart from this bootstrapping use, and the ability of such an RR to have a TTL independent of the negative TTL value for the zone, this mechanism is semantically equivalent to a No Data response. It would be absurd for the root target for any given schema to exist with any other SOPA resource record at that owner name. An authoritative name server MAY refuse to serve a zone containing such an inconsistency, MAY refuse to load a zone containing such an inconsistency, or MAY suppress every SOPA RR at an owner name and schema except that containing the root target. The name server side of a recursive resolver MAY discard every SOPA RR at an owner name except that containing the root target. Conforming servers MUST NOT serve the root target and any other SOPA RR at the same owner name. Clients receiving a SOPA RRset that includes the root target MUST accept that RR, and discard any other RR in the RRset.

The special character "*" in the Target field is used to match any label, according to the wildcard label rules in section 4.3.3 of . Note that, because of the way wildcards work in the DNS, is it not possible to place a restriction to the left of a wildcard; so, for instance, example.*.example.com does not work. The effect is maintained in this memo. An authoritative name server MUST NOT serve an SOPA RR with erroneous wildcards, and clients receiving such an SOPA RR MUST discard the RR. If the discarded RR is the last RR in the answer section of the response, then the response is treated as a No Data response.

Use of an SOPA RR enables a site administrator to assert or deny relationships between names. By the same token, it permits a a consuming client to detect these assertions and denials. Some of these relationships are currently impossible to indicate in the DNS. For example, IDN character variants (see ) result in situations where multiple labels are sometimes intended to be treated as though they are the same. Without a mechanism for binding the names together even loosely, such a goal cannot be achieved. The use of SOPA RRs could either replace the public suffix list or (more likely due to some limitations -- see ) simplify and automate the management of the public suffix list. A client could use the responses to SOPA queries to refine its determinations about http cookie Domain attributes. In the absence of SOPA RRs at both owner names, a client might treat a Domain attribute as though it were omitted. More generally, SOPA RRs would permit additional steps similar to steps 4 and 5 in . SOPA RRs might be valuable for certificate authorities when issuing certificates, because it would allow them to check whether two names are related in the way the party requesting the certificate claims they are.

For the purposes of discussion, it will be useful to imagine a portion of the DNS, using the domain example.tld. A diagram of the tree of this portion is in . In the example, the domain example.tld includes several other names: www.example.tld, account.example.tld, cust1.example.tld, cust2.example.tld, test.example.tld, cust1.test.example.tld, and cust2.test.example.tld.

In the example, the domain tld delegates the domain example.tld. There are other possible cut points in the example, and depending on whether the cuts exist there may be implications for the use of the examples. See , below. The (admittedly artificial) example permits us to distinguish a number of different roles. To begin with, there are three parties involved in the operation of services: OperatorV, the operator of example.tld; Operator1, the operator of cust1.example.tld; Operator2, the operator of cust2.example.tld. Since there are three parties, there are likely three administrative boundaries as well; but the example contains some others. For instance, the names www.example.tld and example.tld are in this case in the same policy realm. By way of contrast, account.example.tld might be treated as completely separate, because OperatorV might wish to ensure that the accounts system is never permitted to share anything with any other name. By the same token, the names underneath test.example.tld are actually the test-instance sites for customers. So cust1.test.example.tld might be in the same policy realm as cust1.example.tld, but test.example.tld is certainly not in the same administrative realm as www.example.tld. Finally, supposing that Operator1 and Operator2 merge their operations, it seems that it would be useful for cust1.example.tld and cust2.example.tld to lie in the same policy realm, without including everything else in example.tld.

This section provides some examples of different configurations of the example tree in , above. The examples are not exhaustive, but may provide an indication of what might be done with the mechanism. This needs to have examples of using the ports and scheme added to it. Suggestions welcome. Also, I think some examples could be made longer to make them clearer. Maybe complete zone files in presentation form in an appendix?

In this scenario, the example portion of the DNS name space contains all and only the following SOPA records for the names-only strategy: example.tld 86400 IN SOPA www.example.tld www.example.tld 86400 IN SOPA example.tld For the scheme-and-port strategy, these are the records instead: example.tld 86400 IN SOPA 0 65535 * www.example.tld www.example.tld 86400 IN SOPA 0 65535 * example.tld Tld is the top-level domain, and has delegated example.tld. The operator of example.tld makes no delegations. There are four operators involved: the operator of tld; OperatorV; Operator1, the operator of the services at cust1.example.tld and cust1.test.example.tld; and Operator2, the operator of the services at cust2.example.tld and cust2.test.example.tld. In this arrangement, example.tld and www.example.tld positively claim to be within the same policy realm. Every other name stands alone. A query for an SOPA record at any of those other names will result in a No Data response, which means that none of them include any other name in the same policy realm. As a result, there are eight separate policy realms in this case: tld, {example.tld and www.example.tld}, test.example.tld, cust1.test.example.tld, cust2.test.example.tld, account.example.tld, cust1.example.tld, and cust2.example.tld.

This example mostly works the same way as the one in Section , but there is a slight difference. In this case, in addition to the records listed in , both tld and test.example.tld publish root targets in their SOPA records. For names-only: tld 86400 IN SOPA . test.example.tld 86400 IN SOPA . For scheme-and-port: tld 86400 IN SOPA 0 65535 * . test.example.tld 86400 IN SOPA 0 65535 * . The practical effect of this is largely the same as the previous example, except that these expressions of policy last 86,400 seconds instead of the length of time on the negative TTL in the relevant SOA for the zone. Many zones have short negative TTLs because of expectations that newly-added records will show up quickly. This mechanism permits such names to express their administrative isolation for predictable periods of time. Moreover, because clients are permitted to retain these records during periods when DNS service is not available, a client could go offline for several weeks, and return to service with the presumption that test.example.tld is still not in any policy realm with any other name.

In this scenario, example.tld delegates the name test.example.tld. In this case, in addition to the SOPA record at test.example.tld, there is an SOA record for test.example.tld. So, there are the same SOPA records as in . The addition of the SOA record for test.example.tld does not affect the relationship between test.example.tld and example.tld. At this point, there are eight policy realms. Next, the Operator1 determines that it is safe to treat the test instance and production instance as being in the same policy realm. To begin with, Operator1 asks OperatorV to add the following record to the test.example.tld zone for the names-only case: cust1.test.example.tld 86400 IN SOPA cust1.example.tld And for the scheme-and-port case: cust1.test.example.tld 86400 IN SOPA 0 65535 * cust1.example.tld This arrangement is not complete yet. Until a record is also added at cust1.example.tld, Operator1's intention is only half fulfilled. The service at cust1.test.example.tld treats cust1.example.tld as part of a common policy realm, but the converse is not the case. I can't decide whether there's anything useful in this configuration. Thoughts? I also can't decide whether this is still 8 admin realms, 7 admin realms but broken, or 7 admin realms from one perspective and 8 from another. To complete the process, Operator1 asks OperatorV to add the following record to the example.tld zone in the names-only case: cust1.example.tld 86400 IN SOPA cust1.test.example.tld In the scheme-and-port case: cust1.example.tld 86400 IN SOPA 0 65535 * cust1.test.example.tld Once this is complete, both names treat the other as part of the same policy realm. In the end, the example segment of the DNS expresses the following seven policy realms: tld, {example.tld, www.example.tld}, test.example.tld, {cust1.test.example.tld, cust1.example.tld}, cust2.example.tld, account.example.tld, cust2.test.example.tld.

There are four significant problems with this proposal, all of which are related to using DNS to deliver the data. The first is that new DNS RRTYPEs are difficult to deploy. While adding a new RRTYPE is straightforward, many provisioning systems do not have the necessary support and some firewalls and other edge systems continue to filter RRTYPEs they do not know. The second is that it is difficult for an application to obtain data from the DNS. The TTL on an RRset, in particular, is usually not available to an application, even if the application uses the facilities of the operating system to deliver other parts of an unknown RRTYPE. The third, which is mostly a consequence of the above two, is that there is a significant barrier to adoption: until browsers have mostly all implemented this, operations need to proceed as though nobody has. But browsers will need to support two mechanisms for some period of time if they are to implement this mechanism at all, and they are unlikely to want to do that. This may mean that there is no reason to implement, which also means no reason to deploy. This is made worse because, to be safe, the mechanism really needs DNSSEC, and performing DNSSEC validation at end points is still an unusual thing to do. This limitation may not be as severe for use-cases that are directed higher in the network (such as using this mechanism as an automatic feed to keep the public suffix list updated, or for the use of CAs when issuing certificates. Finally, in many environments the system hosting the application has only proxied access to the Internet, and cannot query the DNS directly. It is not clear how such clients could ever possibly retrieve the SOPA record for a name.

It is possible to put enough SOPA records into a zone such that the resulting response will exceed DNS or UDP protocol limits. This is especially true in the case where one wishes to take advantage of the scheme-and-port approach, and one expresses many different such relationship. In such cases, a UDP DNS response will arrive with the TC (truncation) bit set. An SOPA response with the TC bit must be queried again in order to retrieve a complete response, in order to ensure that there is no missing root target (see ), generally using TCP. This increases the cost of the query, increases the time to being able to use the answer, and may not work at all in networks where administrators mistakenly block port 53 using TCP.

This mechanism enables publication of assertions about administrative relationships of different DNS-named systems on the Internet. If such assertions are accepted without checking that both sides agree to the assertion, it would be possible for one site to become an illegitimate source for data to be consumed in some other site. In general, assertions about another name should never be accepted without querying the other name for agreement. Undertaking any of the inferences suggested in this draft without the use of the DNS Security Extensions exposes the user to the possibility of forged DNS responses.

IANA will be requested to register the SOPA RRTYPE if this proceeds.

The author thanks Adam Barth, Dave Crocker, Jeff Hodges, John Klensin, Murray Kucherawy, Gervase Markham, Patrick McManus, Henrik Nordstrom, Yngve N. Pettersen, Eric Rescorla, Thomas Roessler, Peter Saint-Andre, and Maciej Stachowiak for helpful comments.

Information Sciences Institute (ISI) USC/ISI

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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. Note that the force of these words is modified by the requirement level of the document in which they are used. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This document defines the term "Public Suffix domain" as meaning a domain under which multiple parties that are unaffiliated with the owner of the Public Suffix domain may register subdomains. Examples of Public Suffix domains include "org", "co.uk", "k12.wa.us" and "uk.com". It also defines a file format that can be used to distribute information about such Public Suffix domains to relying parties. As an example, this information is then used to limit which domains an Internet service can set HTTP cookies for, strengthening the rules already defined by the cookie specification. This specification updates RFC 6265 [RFC6265] by defining the term "Public Suffix domain". Computer Science

Parkville Victoria 3052 Australia. kre@munnari.OZ.AU e

RGnet, Inc.

5147 Crystal Springs Drive Bainbridge Island Washington 98110 United States. NE randy@psg.com

Applications DNS domain name system CSIRO - Mathematical and Information Sciences

Locked Bag 17 North Ryde NSW 2113 AUSTRALIA +61 2 9325 3148 Mark.Andrews@cmis.csiro.au

Applications domain name system DNS [RFC1034] provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section 4.3.4]. Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name. Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver. Troll Tech

Waldemar Thranes gate 98B Oslo N-0175 NO +47 22 806390 +47 22 806380 arnt@troll.no

Internet Software Consortium

950 Charter Street Redwood City CA 94063 US +1 650 779 7001

Microsoft Corporation

One Microsoft Way Redmond WA 98052 US levone@microsoft.com

This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others. [STANDARDS-TRACK] This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar-looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed for Chinese, Japanese, and Korean domain names. This memo provides information for the Internet community. This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK] This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK] This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.</t><t> This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]

This Internet-Draft is discussed on the applications area working group mailing list: apps-discuss@ietf.org.

Changed the mnemonic from BOUND to AREALM Added ports and scheme to the RRTYPE Added some motivating text and suggestions about what can be done with the new RRTYPE Removed use of "origin" term, because it was confusing. The document filename preserves "origin" in the name in order that the tracker doesn't lose the change history, but that's just a vestige. Removed references to cross-document information sharing and ECMAScript. I don't understand the issues there, but Maciej Stachowiak convinced me that they're different enough that this mechanism probably won't work. Attempted to respond to all comments received. Thanks to the commenters; omissions and errors are mine. Changed mnemonic again, from AREALM to SOPA. This in response to observation by John Klensin that anything using "administrative" risks confusion with the standard administrative boundary language of zone cuts. Add discussion of two strategies: name-only or scheme-and-port. Increase prominence of utility to CAs. This use emerged in last IETF meeting.