RFC 3707
Cross Registry Internet Service Protocol (CRISP) Requirements
Cross Registry Internet Service Protocol (CRISP) Requirements 🎀
Who wrote it: A. Newton from VeriSign, Inc. 💅 Category: Informational 📚 (this is a "for your info" doc, not a standard!) Date: February 2004 🗓️ Stream: Network Working Group 🫶 Obsoletes or updates: The header doesn't list anything this one obsoletes or updates, so it stands on its own. 🦋
Status of This Memo ✨
Okay so this memo is here to give info to the Internet community. It is not a standard of any kind, and it doesn't specify one. Distribution is unlimited, so share it with everyone 🌸
Copyright Notice 💜
Copyright (C) The Internet Society (2004). All Rights Reserved. 🔒
Abstract 🧚
Internet registries put their admin and operational data out there through all kinds of different directory services. This doc lays out the functional requirements for the directory services of domain registries, plus the common base requirements for extending those services to other kinds of Internet registries. It's giving foundation 🏗️
Table of Contents 📖
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Scope . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements Specification . . . . . . . . . . . . . . . 3
2. Internet Registry Communities . . . . . . . . . . . . . . . . 4
2.1. Domain Name System Registries . . . . . . . . . . . . . 4
2.1.1. Domain Registries . . . . . . . . . . . . . . . 4
2.1.2. Domain Registrars . . . . . . . . . . . . . . . 5
2.2. Other Registries . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Regional Internet Registries . . . . . . . . . . 5
2.2.2. Local Internet Registries . . . . . . . . . . . 5
2.2.3. Internet Routing Registries . . . . . . . . . . 5
2.2.4. Incident Coordination Contact Registries . . . . 6
2.3. Implementers . . . . . . . . . . . . . . . . . . . . . . 6
2.4. End Users . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1. Internet Resource Registrants . . . . . . . . . 6
2.4.2. Service Providers and Network Operators . . . . 6
2.4.3. Intellectual Property Holders . . . . . . . . . 7
2.4.4. Law Enforcement . . . . . . . . . . . . . . . . 7
2.4.5. Certificate Authorities . . . . . . . . . . . . 7
2.4.6. DNS Users . . . . . . . . . . . . . . . . . . . 7
2.4.7. Abusive Users . . . . . . . . . . . . . . . . . 7
2.5. Other Actors . . . . . . . . . . . . . . . . . . . . . . 8
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 8
3.1. Base Functions . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Mining Prevention . . . . . . . . . . . . . . . 8
3.1.2. Minimal Technical Reinvention . . . . . . . . . 8
3.1.3. Standard and Extensible Schemas . . . . . . . . 9
3.1.4. Level of Access . . . . . . . . . . . . . . . . 9
3.1.5. Client Processing . . . . . . . . . . . . . . . 10
3.1.6. Entity Referencing . . . . . . . . . . . . . . . 10
3.1.7. Decentralization . . . . . . . . . . . . . . . . 10
3.1.8. Query of Access Permission . . . . . . . . . . . 11
3.1.9. Authentication Distribution . . . . . . . . . . 11
3.1.10. Base Error Responses . . . . . . . . . . . . . . 11
3.1.11. Query Distribution . . . . . . . . . . . . . . . 12
3.1.12. Protocol and Schema Versioning . . . . . . . . . 12
3.1.13. Relay Bag . . . . . . . . . . . . . . . . . . . 13
3.1.14. Privacy Labels . . . . . . . . . . . . . . . . . 14
3.2. Domain Specific Functions . . . . . . . . . . . . . . . 14
3.2.1. Lookups . . . . . . . . . . . . . . . . . . . . 14
3.2.2. Searches . . . . . . . . . . . . . . . . . . . . 15
3.2.3. Information Sets . . . . . . . . . . . . . . . . 16
3.2.4. Serialization Support . . . . . . . . . . . . . 17
3.2.5. Result Set Limits . . . . . . . . . . . . . . . 17
3.2.6. DNS Delegation Referencing . . . . . . . . . . . 17
3.2.7. Distribution for Domain Registry Types . . . . . 18
3.2.8. Data Omission . . . . . . . . . . . . . . . . . 18
3.2.9. Internationalization . . . . . . . . . . . . . . 19
4. Feature Requirements . . . . . . . . . . . . . . . . . . . . . 19
4.1. Client Authentication . . . . . . . . . . . . . . . . . 19
4.2. Referrals . . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Common Referral Mechanism . . . . . . . . . . . . . . . 20
4.4. Structured Queries and Responses . . . . . . . . . . . . 20
4.5. Existing Schema Language . . . . . . . . . . . . . . . . 20
4.6. Defined Schemas . . . . . . . . . . . . . . . . . . . . 20
5. Internationalization Considerations . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . . 21
Informative References . . . . . . . . . . . . . . . . . . . . 21
URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
B.1. Forums. . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.2. Working Group . . . . . . . . . . . . . . . . . . . . . . 24
B.3. Contributions . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property Statement. . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 261. Introduction 🌈
1.1. Background 🕰️
Okay, so the Internet grew up. What used to be one centralized, managed Network Information Center is now the job of a bunch of autonomous, functionally different, globally spread-out Internet registries 🌍 With more registries popping up, their admin directory services got used in ways nobody planned. People kept using the whois [6] protocol, but also outside the scope of its specification, with formal and informal syntax definitions and undocumented security mechanisms. Some folks used other protocols, like rwhois [5], for other needs. And there were proposals to use other tech like LDAP [4] and XML. It's a lot, bestie 😭
1.2. Requirements Scope 🎯
The requirements in this doc are about the directory services of Internet registries and their related communities (Section 2.3, Section 2.4, and Section 2.5). This scope is specifically aimed at domain name registries (Section 2.1). Requirements for other registry types will come in other memos 🦋 The requirements cover both how these directory services are used right now and what functionality people want, based on input from relevant forums (Appendix B.1). These requirements aren't tied to any one protocol 🫶 Terms used to define the requirements can be found in the glossary (Appendix A).
The requirements in this doc are also limited to accessing data from Internet registries. Requirements for modifying, adding, or provisioning data in Internet registries are out of scope here 🙅♀️
1.3. Requirements Specification 📝
The requirements in this doc are meant for designing technical specifications. The words this document uses for compliance with RFC 2119 [3] don't reference or specify policy. They only speak to the capabilities of the derived technology 💅 For example, this document may say that the protocol "MUST" support certain features. An actual service operator is always free to disable those features, and then return an error such as "permission denied." Totally fair!
Requirements that specify what the protocol needs for proper interaction between a client and a server will be written with the "MUST/SHOULD" language of RFC 2119 [3]. This doc also has language about how a client interacts with multiple servers to form one coherent, cross-network service. Those service requirements are not written using RFC 2119 language, so don't go looking for capitals there 👀
Quick reminder: individual servers or service operators might not support every feature the protocol can handle, but they still have to respect the semantics of protocol queries and responses. For example, a server should not return referrals if it doesn't have referent data. Respect the semantics, babe 💖
2. Internet Registry Communities 👑
The Internet registries are made up of different communities that give scope to the requirements in this doc. These communities can be generalized into these categories: registries, registrars, implementers, end-users, and other actors 🧚
2.1. Domain Name System Registries 🌐
2.1.1. Domain Registries 🏠
Domain registries handle the registration of domains for use with DNS [1] and forward lookups. (This does not include the .ARPA domain, fyi 🙈) These registries have usually served two main domain functions: running a gTLD registry or running a ccTLD registry. Sometimes one entity runs multiple TLD's, both gTLD and ccTLD types. A gTLD or ccTLD domain registry operator can be a governmental entity, a non-governmental entity, a non-commercial entity, or a commercial entity. It's giving variety 🌸
Some ccTLD's have second-level domain registrations that are similar in nature to gTLD's. Others have totally separate entities running second-level domain registries within the ccTLD, which are also similar in nature to gTLD's ✨
Domain registries usually follow one of two models for handling domain registrations. The "thick" model is the more traditional one. In a "thick" domain registry, the registry holds both the operational data for the domain and the contact data (Appendix A) for the domain. In this model, the registry is typically the interface to the domain registrant, but it may also interface with the domain registrant through domain registrars 🤝 The "thin" model domain registry only holds operational data for domains. In the "thin" model, contact data for the domain is maintained by a domain registrar 🫧
Domain registries not described in this section (Section 2.1.1) are not the subject of this document, and they may have requirements that are out of scope for this topic 🙃
2.1.2. Domain Registrars 📬
Domain registrars accept domain registrations from registrants on behalf of domain registries, both "thick" and "thin" 💌 In a "thin" model registry/registrar system, a domain registrar maintains the contact data of a domain, while the registry maintains the operational data of a domain. In a "thick" model registry/registrar system, a domain registrar passes both the operational data and the contact data to the registry. Registrars can also register a domain on behalf of a registrant in more than one domain registry. Multitasking queen 👑
2.2. Other Registries 🗂️
This section describes Internet registries other than the ones listed in Section 2.1. These descriptions aren't definitive, and this list isn't absolute. They're provided in this document for informational purposes only 📚 (Part 1 of 5. More parts are coming, so stay tuned 💜🦋)
2.2.1. Regional Internet Registries ✨
okay so Regional Internet Registries (RIR's) are the ones who handle giving out IP address space and autonomous system numbers 🌍 Each RIR looks after one specific geographic region, and together they cover the whole Internet 💖 They're membership-based, non-profit orgs, and they carry out global addressing policy based on what their regional community decides 🫶
2.2.2. Local Internet Registries 🏡
Local Internet Registries (LIR's) and National Internet Registries (NIR's) are sub-registries of RIR's. They do the same jobs the RIR's do, just for smaller, more specific areas: sovereign nations, localities, and so on 🌸
2.2.3. Internet Routing Registries 🛣️
Internet Routing Registries are routing policy databases 🦋 Their whole purpose is giving out info that helps run Internet routers. Often, their syntax and contents are defined by RPSL [7] 🧚
IRR's are run by academic, commercial, governmental, and other kinds of organizations, and that includes several of the RIR's 💅 What's inside each database varies, because it reflects what the people it directly serves actually need. For example, an ISP might look up route entries that their customers added, so they can decide whether to accept specific route advertisements they get. Iconic behaviour, honestly 👑
Here's the twist: unlike RIR and domain registry data, IRR data is often duplicated across separate organizations 👀 It's also super unique because it's largely available through other sources (it's advertised by the Internet routing protocols), and it usually has a common data format, which is RPSL ✨
2.2.4. Incident Coordination Contact Registries 🚨
Incident coordination contact registries let operators of network resources (like network infrastructure, network names, or network services) register their contact info. The point is to give them a way to get incident notifications 📬 With this kind of registry, an operator of network resources gets info for contacting the operator of another network resource that an incident might be coming from. Super helpful when something's going sideways 🙈
2.3. Implementers 🛠️
Implementers of client software are often either affiliated with large network operators, registry operators, or commercial entities that offer value-added services. Or they're just general citizens of the Internet 🌈 A lot of the client software for using the directory services of Internet registries is freely available, open source, or both, or it's offered as a service 💜 Implementers of server software are often affiliated with operators or with commercial entities that specialize in outsourcing development for Internet registries 💼
2.4. End Users 👩💻
This section walks through the many types of end-users. Individuals and organizations can wear multiple hats, and they may be in lots of these categories at the same time ✨
2.4.1. Internet Resource Registrants 🎀
These are entities that have authority over an Internet resource, whether they got it by purchase, lease, or grant from an Internet registry, either directly or through a registrar 💅
2.4.2. Service Providers and Network Operators 📡
Service providers and network operators provide connectivity, routing, and naming services to lots of other entities, some commercial and some not, both big and small 🫶 Their operational and administrative staff often interact with Internet registries on behalf of other end-users. These providers and operators interact with all of the Internet registry operators outlined in this document, frequently and consistently 🔥 For example, network operators use the directory services of Internet registries to find contact info for network resources that have technical problems 🛎️
2.4.3. Intellectual Property Holders ©️
A bunch of parties have some legal rights over certain alphanumeric strings, like trademark and service mark holders, intellectual property holders, individuals, governments, and other geopolitical entities 🧾
They use the directory services of Internet registries (mostly domain registries and registrars) to maintain and defend their claims to domain names, in line with applicable laws and regulations ⚖️
2.4.4. Law Enforcement 🚓
Law enforcement agencies use the directory services of Internet registries to find info they use to enforce laws within their jurisdictions 🔍
2.4.5. Certificate Authorities 🔐
Certificate authorities use the directory services of Internet registries as part of their verification process when they issue certificates for Internet named hosts 🪪
2.4.6. DNS Users 🌐
Users of the Internet have client software that resolves domain names to IP addresses, and IP addresses to domain names 🗺️ When trouble shows up in the DNS resolution process, these users often troubleshoot system problems with the help of info from the directory services of Internet registries 🕵️♀️
2.4.7. Abusive Users 🚫
The administrative directory services of Internet registries are often the target of practices by abusive users 😤 Using info from Internet registries, these users do things that go against the acceptable use of that info, as intended by a registry, registrar, or registrant. A lot of the time, these practices break the law in the jurisdiction of the user, the registry, the registrar, or the registrant ⚠️ One example is using Internet registry info to send unsolicited bulk or commercial email 📧💀
2.5. Other Actors 🌏
Requirements also have to consider the positions and policies of other actors when it comes to using Internet registry directory services 🧠 These actors include governments, non-governmental policy-setting bodies, and other non-governmental organizations 🏛️
3. Functional Requirements 📋
Functional requirements describe an overall need or process where an Internet registry uses the directory service to meet its obligations to give access to its customers, members, or other constituents 💖 This section describes requirements the way Section 1.3 specifies them 🦋
3.1. Base Functions 🧱
This section describes basic directory service protocol requirements for Internet registries. Extra requirements that are specific to domain registries are described in Domain Specific Functions (Section 3.2) 🌸
3.1.1. Mining Prevention ⛏️
To stop people from grabbing data out of an Internet registry's directory service in ways they shouldn't, many servers will limit how much data can be returned from a server to a client in a fixed amount of time 🙅♀️ This is especially likely for anonymous access (see Section 3.1.4) 👀
The limits on different types of data, or the ones applied depending on access status, will most likely differ from server to server based on policy and need 💅 Supporting these different service models to limit data and prevent data mining may or may not have a direct impact on the client-to-server protocol 🤷♀️
3.1.2. Minimal Technical Reinvention 🔁
The protocol MUST NOT employ unique technology solutions for all aspects and layers above the network and transport layers 🙅♀️ The protocol SHOULD make use of existing technology standards where that applies ✨ The protocol MUST employ the use of network and transport layer standards as defined by the Internet Engineering Task Force 🌐 And the protocol MUST define one or more congestion-aware transport mechanisms for mandatory implementation 🚦
3.1.3. Standard and Extensible Schemas 🧩
3.1.3.1. Protocol Requirement
The protocol MUST contain standard schemas for exchanging the data needed to implement the functionality in this document 📚 On top of that, there MUST be a means to allow the use of schemas that the needs of this document don't define 🙌 Both types of schemas MUST use the same schema language 💜 And the schemas MUST be able to express data elements with identifying tags, so the meaning of those tags can be localized 🌈
3.1.3.2. Service Description
The client-to-server protocol must define a standard set of data structures or schemas for exchanging info. It must also be able to support newer data structures that this specification doesn't foresee yet 🔮 In both cases, the description and specification of both types of data structures or schemas must be done the same way (i.e., using the same schema language) 🫶
The schemas must also be capable of "tagging" data with a unique identifier 🏷️ That identifier can then be used to localize the name of that type of data. For instance, a piece of data might have the value "Bob", and its type identified with the number "5.1". Client software could use that to display "Name: Bob" in an English locale, or "Nombre: Bob" in a Spanish locale 🇪🇸✨
3.1.4. Level of Access 🔑
3.1.4.1. Protocol Requirement
The protocol MUST NOT prohibit an operator from granularly assigning multiple types of access to data according to the operator's policies 🎛️ The protocol MUST provide an authentication mechanism, and MUST NOT prohibit an operator from granting types of access based on authentication 🪪
The protocol MUST provide an anonymous access mechanism that may be turned on or off based on an operator's policy 🎭
3.1.4.2. Service Description
Server operators will offer varying degrees of access depending on policy and need. Here are some examples:
- users will be allowed access only to data for which they have a relationship 💌
- unauthenticated or anonymous access status may not yield any contact information 🙈
- full access may be granted to a special group of authenticated users 👑
The types of access a server allows will most likely vary from one operator to the next 🦄
3.1.5. Client Processing 🤖
The protocol MUST be capable of allowing machine-parsable requests and responses 💻
3.1.6. Entity Referencing 🔗
There MUST be a mechanism for an entity contained within a server to be referenced uniquely by an entry in another server 🧷
3.1.7. Decentralization 🌷
3.1.7.1. Protocol Requirement
The protocol MUST NOT require the aggregation of data to a central repository, server, or entity 🙅♀️ The protocol MUST NOT require aggregation of data indexes or hints to a central repository, server, or entity either 🚫
3.1.7.2. Service Description
Some server operators may need to coordinate service in a mesh or some other framework with other server operators 🕸️ However, the ability to operate a CRISP compliant server must not require this 💖
3.1.8. Query of Access Permission 🚪
3.1.8.1. Protocol Requirement
The protocol MUST provide a mechanism that lets a client find out if a query will be denied before the query is submitted, according to the appropriate operator policies 🔍
3.1.8.2. Service Description
Usage scenarios differ depending on both policy and type of service, so some server operators may want to let a client predetermine whether it can retrieve data from a query 🧐 But some operators won't allow this, for security reasons, policy restrictions, or other reasons 🔒
3.1.9. Authentication Distribution 🪪
3.1.9.1. Protocol Requirement
The protocol MUST NOT require any Internet registry to participate in any authentication system 🙌 The protocol MUST NOT prohibit an Internet registry from taking part in federated, distributed authentication systems 🌍✨
3.1.9.2. Service Description
okay so some server operators might need to hand off authentication to another party 🎀, or be part of a setup where auth info gets distributed around 🌸. but bestie, being able to run a CRISP compliant server must not require any of that 💅
3.1.10. Base Error Responses
The protocol MUST be capable of returning the following types of non-result or error responses to all lookups and searches: 🚫
- permission denied - a response indicating that the search or lookup has failed due to insufficient authorization. 🔐
- not found - the desired results do not exist. 🫥
- insufficient resources - the search or lookup requires resources that cannot be allocated. 🪫
3.1.11. Query Distribution
3.1.11.1. Protocol Requirement
The protocol MUST NOT prohibit a server from participating in a query distribution system. 🫶
3.1.11.2. Service Description
okay, for lookups and searches that need queries to get spread out, the client has to be allowed to distribute those queries among the participants in an established mesh of server operators 🕸️✨. it's not a requirement that the protocol lets you discover servers, but cooperating servers should be able to handle distribution smartly within their established mesh 🧠. individual server operators will respond to every query they get according to their own policies for authentication, privacy, and performance 🔒.
however, running a CRISP compliant server must not require joining any query distribution system. 💖
3.1.12. Protocol and Schema Versioning
3.1.12.1. Protocol Requirements
The protocol MUST provide a means by which the end-systems can either identify or negotiate over the protocol version to be used for any query or set of queries. 🔢
All resource-specific schema MUST provide a version identifier attribute which uniquely and unambiguously identifies the version of the schema being returned in the answer set to a query. 🏷️
3.1.12.2. Service Description
the service should let end-systems using different protocol versions fall back to a mutually supported protocol version 🔄. if that's not possible, the service must give a meaningful error that says this is the specific case 🙈.
the service must suggest negotiation and/or recovery mechanisms for clients to use when an unknown schema version is received. 🛠️
3.1.13. Relay Bag
The term "bag" in this section describes a flexible container which may contain unspecified data. 🛍️
3.1.13.1. Protocol Requirement
When issuing a referral, the protocol MUST be capable of supplying a relay bag from the server to the client, and the protocol MUST be capable of allowing the client to submit this relay bag with a query to the referred server. The use of the relay bag MUST be OPTIONAL. The protocol MUST NOT make any assumptions regarding the contents of the relay bag, but the relay bag MUST be described using the schema language of the protocol. 👜
The protocol MUST provide different error messages to indicate whether the bag is of unrecognized format (permanent failure), if it contains unacceptable data (permanent failure), or if it contains data that means processing is refused at this time (transient failure). ⚠️
There MUST be no more than one bag per referral. The protocol MUST NOT make an association or linkage between successive bags in a referral chain. 🔗
The client MUST pass the bag as part of any query made to a referrant server as a result of a referral. 🎁
3.1.13.2. Service Description
in some models where service coordination among participating server operators is used, a referring server might need to pass operator-to-operator coordination data along with the referral to the referent server 🤝. things like auditing or tracking, for example 🕵️. this feature lets a server pass the client a flexible container of unspecified data ("bag") that the client should pass along to the referent server 🎒. the bag has no meaning to the client, so the client just carries it. 🫧
3.1.14. Privacy Labels
3.1.14.1. Protocol Requirement
When a value in an answer to a query is given, the protocol MUST be capable of tagging the value with the following labels: 🏷️
- do not redistribute
- special access granted
The protocol MAY define other values for this purpose, but MUST define values defined above at a minimum. The protocol MUST be capable of attaching these labels concurrently. 🌈
3.1.14.2. Service Description
internet registries have all kinds of policies about who can access their data 🌍. some registries may give certain classes of users access to data that most people wouldn't normally get 👑. in those cases, registries may want to tag the values in these entries with labels that spell out the responsibilities that come with those special user rights 📜💅.
3.2. Domain Specific Functions
these functions describe requirements that domain registries (Section 2.1.1) and domain registrars (Section 2.1.2) specifically need 🌷. requirements for other registries (Section 2.2) MUST be specified separately. no compliant server operator is required to support the functions required by every registry type 🫶.
3.2.1. Lookups
3.2.1.1. Protocol Requirement
The protocol MUST contain the following lookup functions: 🔍
- Contact lookup given a unique reference to a contact of a resource.
- Nameserver lookup given a fully-qualified host name or IP address of a nameserver.
- Domain lookup given a fully-qualified domain name.
See Section 3.2.3 for the requirements regarding the expected return values. 👀
3.2.1.2. Service Description
these lookups are all single index queries and should produce zero or only one entity 🎯.
depending on the policy and needs of an internet registry, a server operator may not allow all or any of these lookups to return part or all of the information. See Section 3.2.3. 🙅♀️
3.2.2. Searches
3.2.2.1. Protocol Requirement
The protocol MUST contain the following search functions: 🔎
- Domain name search given an exact match or reasonable subset of a name. This search SHOULD allow for parameters and qualifiers designed to allow better matching of internationalized domain names and SHOULD allow for both exact and partial matching within the limits of internationalized domain names. This search SHOULD NOT require special transformations of internationalized domain names to accommodate this search. This search MUST provide a means to narrow the search by names delegated under a particular TLD. 🌏
- Domain registrant search by either exact name or partial name match with the ability to narrow the search to registrants of a particular TLD. 🧑💼
- Domains hosted by a nameserver given the fully-qualified host name or IP address of a nameserver. 🏠
See Section 3.2.3 for the requirements regarding the expected return values. ✨
3.2.2.2. Service Description
depending on the policy and needs of an internet registry, a server operator may not allow all or any of these searches to return part or all of the information. See Section 3.1.4. Access to information resulting from these searches may also be limited, depending on policy, by quantity. Section 3.2.5 describes these types of restrictions. 📏
some internet registries may also be part of a query distribution system. See Section 3.1.11. 🕸️
3.2.3. Information Sets
3.2.3.1. Protocol Requirements
The data sets for contacts, nameservers, and domains MUST be able to express and represent the attributes and allowable values of registration requests in domain registration and provisioning protocols. 📋
The schema MUST be capable of expressing the following information for domains: 🗂️
- activation status
- registrant
- nameservers
- technical, billing or other contacts
- registry delegating the domain
- registrar for the domain
The data set for domains MUST be able to express arbitrary textual information for extensions on an individual operator basis. Examples of such information are license agreements, authorized use policies, extended status notifications, marketing/for sale notices, and URI references to other sources. 💌
3.2.3.2. Service Description
it's not expected that every internet registry supplies all of the information spelled out above 🤷♀️. however, the schemas the protocol uses must be capable of expressing this information should a registry need to provide it 🪄.
the following sections describe requirements relative to the use of schemas with respect to individual registry need and policy:
- Section 3.2.8
- Section 3.2.5
- Section 3.1.4
- Section 3.1.1
3.2.4. Serialization Support
The schemas used by the protocol SHOULD be capable of off-line serialization
off-line serialization allows for implementation independent operations such as backup and recovery, load-balancing, etc. This MAY also make possible, in whole or in part, data escrow capabilities and other usages, however such usages are out of the scope of this document. 💾🧚
3.2.5. Result Set Limits
3.2.5.1. Protocol Requirement
The protocol MUST contain a feature, used at the discretion of a server operator, to allow a server to express to a client a limit on the number of results from searches and lookups. When returning result sets, the protocol MUST be able to make the following distinctions: 🧮
- an empty result set.
- a result set truncated for the purpose of improving performance bottlenecks.
- a result set truncated to comply with Section 3.1.1
3.2.5.2. Service Description
clients work way more smoothly when they understand why a result set got cut off 🧐. some internet registries may not be able to expose their policies for limiting result sets, but when they can, clients get a better operational view 👁️. that can cut out re-queries and other repeated actions nobody wants 🙌.
3.2.6. DNS Delegation Referencing
3.2.6.1. Protocol Requirement
The protocol MUST use the delegation authority model available in DNS [1] as the primary means for determining the authoritative source for information regarding domains or any other objects when applicable. 🌐
3.2.6.2. Service Description
the goal here is for clients to use the DNS delegation model to find servers that are authoritative for resources, instead of using a master or central server full of pointer information 🧭. in other words, when DNS naturally maps a resource, the desired behavior is to ask the DNS for an authoritative server holding info about that resource 💫. for example, the authoritative server for information about example.com, according to that domain's registrant, can be found by querying the DNS zone for example.com. to find the registry information for example.com, the DNS zone for .com should be queried. 🦋
there are cases where resources won't naturally map into the DNS delegation hierarchy. this requirement is not meant to force that kind of mapping 🙏.
3.2.7. Distribution for Domain Registry Types
3.2.7.1. Protocol Requirement
The protocol MUST NOT prohibit the distribution of data to exclude any of the registry/registrar models stated in Section 2.1.1. The protocol MUST be capable of expressing referrals and entity references between the various models described in Section 2.1.1. 🍓
3.2.7.2. Service Description ✨
Okay so, depending on the domain registry/registrar model being used, the technical data for a domain might only live on one server, while the contact data for that same domain lives on a server run by a totally different entity 🏢 But lowkey, in lots of cases it's not like that at all 🤷♀️ So the service has to accommodate the various registration distribution models of domain registry types described in Section 2.1.1 while complying with Section 3.1.7 💅
3.2.8. Data Omission 🙈
3.2.8.1. Protocol Requirement
When a value in an answer to a query can't be given because of policy constraints, the protocol MUST be capable of expressing the value in one of three ways:
- complete omission of the value without explanation
- an indication that the value cannot be given due to insufficient authorization
- an indication that the value cannot be given due to privacy constraints regardless of authorization status
The protocol MAY define other values for this purpose, but MUST define the values above at a minimum. 🫶
3.2.8.2. Service Description
Internet registries have different limits on exposing certain types of data, usually the social stuff 👀 Server operators need the ability to handle this, and client software is way more useful when it gets proper explanations 🧚 So, depending on policy, a server operator gets to choose between not returning the data at all, signaling a permission error, or indicating a privacy constraint. Choices, choices! 🍓
3.2.9. Internationalization 🌈
The schema defining domain related resources MUST conform to RFC 2277 [2] regarding textual data. Like, the schema MUST be able to indicate the charset and language in use with unstructured textual data. Super important 💜
The protocol MUST be able to support multiple representations of contact data, and these representations must comply with the requirements in Section 3.2.3. The protocol MUST be able to provide contact data in UTF-8 and SHOULD be able to provide contact data in US-ASCII, other character sets, and be capable of specifying the language of the data. ✨
4. Feature Requirements 🎀
Feature requirements describe the perceived need that comes out of the functional requirements, for specific technical criteria of the directory service. This section describes requirements in the manner specified in Section 1.3. 💖
4.1. Client Authentication 🔐
Entities accessing the service (users) MUST be provided a mechanism for passing credentials to a server for the purpose of authentication. The protocol MUST provide a mechanism capable of employing many authentication types and capable of extension for future authentication types. Future-proof queen behavior 👑
4.2. Referrals 🦋
To distribute queries for search continuations and to issue entity references, the protocol MUST provide a referral mechanism. 🔁
4.3. Common Referral Mechanism 🧩
To distribute queries for search continuations and to issue entity references, the protocol MUST define a common referral scheme and syntax. Consistency is everything 💅
4.4. Structured Queries and Responses 🗂️
To provide for machine consumption as well as human consumption, the protocol MUST employ structured queries and responses. Robots and humans both get to read it, iykyk 🤖💕
4.5. Existing Schema Language 📜
To provide structured queries and responses and allow for minimal technological reinvention, the protocol MUST employ a pre-existing schema language. No need to reinvent the wheel bestie 🛞
4.6. Defined Schemas 📐
To provide for machine consumption as well as human consumption, the protocol MUST define schemas for use by the structured queries and responses. 🥰
5. Internationalization Considerations 🌸
Requirements defined in this document MUST consider the best practices spelled out in [2]. Non-negotiable, babe 🙅♀️
6. IANA Considerations 🧾
IANA consideration for any service meeting these requirements will depend upon the technologies chosen, and MUST be specified by any document describing such a service. Whatever tech you pick, the doc describing it has to spell this out 📝
7. Security Considerations 🔥
This is the serious part, so pay attention 🚨 This document contains requirements for the validation of authenticated entities, and for the access of authenticated entities compared with the access of non-authenticated entities. It does not define the mechanism for validation of authenticated entities. Requirements defined in this document MUST allow for the implementation of this mechanism according to best common practices.
The requirement in Section 3.1.4 must be weighed against other requirements specifying search or lookup capabilities. It's a balancing act 🤹♀️
This document contains requirements for referrals and entity references. Client implementations based on these requirements SHOULD take proper care in safeguarding credential information when resolving referrals or entity references, according to best common practices. Guard those credentials like your ex's phone number 🔒💀
This document contains requirements for the distribution of queries among a mesh of participating service providers. Protocols proposed to meet these requirements must be able to protect against the use of that distribution system as a vector for distributed denial of service attacks or unauthorized data mining. Do NOT let the system get weaponized, it's giving danger zone 🚫😭
Normative References 📚
[1] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.Informative References 🧠
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[5] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
June 1997.
[6] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
954, October 1985.
[7] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
Policy Specification Language (RPSL)", RFC 2622, June 1999.URIs 🔗
- [8]
<http://www.ietf.org/proceedings/00dec/00dec-41.htm> - [9]
<http://www.ietf.org/proceedings/01aug/51-40.htm> - [10]
<http://www.uwho.verisignlabs.com/Final-WhoIsPanel-Aug15-Resume.pdf> - [11]
<http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes/min_database.html> - [12]
<http://www.nanog.org/mtg-0110/lookup.html>
Appendix A. Glossary 📖
- TLD: short for "top level domain." It refers to domains in DNS [1] that sit hierarchically just beneath the root. 🌳
- ccTLD: short for "country code top level domain." TLDs that use one of the two character country codes defined by ISO. 🇺🇳
- gTLD: short for "generic top level domain." TLDs that don't use one of the two character country codes defined by ISO. 🌐
- contact data: data containing names and contact information (like postal addresses, phone numbers, and e-mail addresses) of humans or legal entities. 📇
- operational data: data needed to operate networks and network related services and items. 🛠️
- RIR: short for "regional Internet registry." 🗺️
- IRR: short for "Internet routing registry." 🛤️
- forward lookup: a DNS lookup where a domain name is resolved to an IP address. ➡️
- reverse lookup: a DNS lookup where an IP address is resolved to a domain name. ⬅️
- mining: in the context of this document, this term is specific to data mining. It's a methodical process to obtain the contents of a directory service, usually as much as possible, and not relevant to any immediate need. Data mining is often not a practice welcomed by registry operators. 🚫⛏️
Appendix B. Acknowledgements 💌
B.1. Forums 🎤
The proceedings of the following public forums were used as input to the scope and requirements for this document:
- whois BOF of the 49th IETF [8]; December 10-15, 2000; San Diego, CA, USA
- whoisfix BOF of the 51st IETF [9]; August 5-10, 2001; London, England
- First UWho Consultation [10]; August 15, 2001; Washington, DC, USA
- Second UWho Consultation; November 15, 2001; Marina del Rey, CA, USA
- Third UWho Consultation; November 19, 2001; Washington, DC, USA
- DNR WG of RIPE 40, October 1-5, 2001; Prague, Czech Republic
- Database WG of RIPE 40 [11]; October 1-5, 2001; Prague, Czech Republic
- General Session of NANOG 23 [12]; October 21-23; Oakland, CA, USA
- DNR WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
- Database WG of RIPE 41, January 14-18, 2002; Amsterdam, The Netherlands
- NANOG 24 Universal Whois BOF, February 10-12, 2002; Miami, Florida
- CENTR General Assembly, February 21-22, 2002; Rambouillet, France
- CRISP BOF of the 53rd IETF, March 17-22, 2002, Minneapolis, Minnesota, USA
B.2. Working Group 🫂
This document is a work item of the Cross-Registry Internet Service Protocol (CRISP) Working Group in the Applications Area of the IETF. Discussions for this working group happen on the email list ietf-not43@lists.verisignlabs.com. To subscribe, send email to ietf-not43-request@lists.verisignlabs.com with a subject line of "subscribe". Archives of this list can be found at http://lists.verisignlabs.com/pipermail/ietf-not43/.
B.3. Contributions 🫶
Comments, suggestions, and feedback of significant substance were provided by Leslie Daigle, Mark Kosters, Ted Hardie, Shane Kerr, Cathy Murphy, Stephane Bortzmeyer, Rick Wesson, Jaap Akkerhuis, Eric Hall, Patrick Mevzek, Marcos Sanz, Vittorio Bertola, George Michaelson, and Tim Christensen. The real MVPs 👑✨
Intellectual Property Statement ⚖️
The IETF takes no position on the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any effort to identify any such rights. Info on the IETF's procedures for rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication, and any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the IETF Secretariat. 📬
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Send that info to the IETF Executive Director 💌
Author's Address 🖊️
Andrew L. Newton
VeriSign, Inc.
21355 Ridgetop Circle
Sterling, VA 20166
USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; anewton@ecotroph.netFull Copyright Statement 💖
Okay bestie, this part is the legal stuff, so I'm keeping the actual words faithful. The Internet Society wrote it, and it only works if it says exactly what it says 🫶
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to others. Derivative works that comment on or otherwise explain it, or help with implementing it, may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, as long as the above copyright notice and this paragraph are included on all such copies and derivative works. ✨
However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or when it's required to translate it into languages other than English. 🌸
The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assignees. Forever and ever, no take-backsies 🦋
This document and the information contained herein is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 😭
Acknowledgement 🎀
Last but not least, the funding bit. The RFC Editor function is currently funded by the Internet Society. So the people keeping the whole RFC series running are supported by them right now 💅
Funding for the RFC Editor function is currently provided by the Internet Society. 🧚
📦 where this page comes from
- ietf: rfc3707 2004-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms