Marcos Sanz Internet Draft DENIC eG Document: draft-sanz-whois-srv-00.txt Gerhard Winkler NIC.AT Expires: October 2003 April 2003 Using DNS SRV records to locate whois servers Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Whois servers are used to locate administrative, technical and security contacts for given IP addresses, domain names or other network objects associated with an organisation, e.g. AS numbers. While usually Top Level Domain (TLD) registries run a whois server, there is no generic name for it and it may not even be obvious that the TLD registry's whois server is the right one to ask, since there are TLDs where registration takes place under specialised second level domains (e.g. UK, AT). The Regional Internet Registries (RIR) also provide whois service as part of their coordination task. All this can be solved by central "master" or "meta" whois servers, which keep track of all new and changing servers and refer to the DNS registries' or RIRs' whois servers. This document proposes a DNS-based approach which eliminates the need for a central master repository and works down to lower levels in the hierarchy. It is the intent to locate a whois server as close to the Sanz & Winkler Expires - October 2003 [Page 1]
SRV records to locate whois servers April 2003 target (in terms of hierarchy) as possible, while preserving the opportunity to locate higher level servers for escalation purposes. 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 [2]. Other terms used in this document are defined in the DNS specification RFC-1034 [3]. Table of Contents 1. Format.........................................................2 2. Usage..........................................................3 3. Domain search strategy.........................................3 3.1 Top-Down model.............................................3 3.2 Bottom-Up model............................................4 3.3 Conclusion.................................................4 4. Clarifications.................................................5 5. Authority......................................................5 6. Related Work at IETF...........................................6 Security Considerations...........................................6 References........................................................6 Acknowledgments...................................................7 Author's Addresses................................................7 1. Format The general format of DNS SRV records is documented in RFC 2782: _Service._Proto.Name TTL Class SRV Priority Weight Port Target Therefore the simplest format of an SRV record to locate a whois server is: _nicname._tcp IN SRV 0 0 43 whois.nic.example. The symbolic name of the service is defined as "nicname" (case insensitive) and the protocol is TCP based, as per RFC 954 [4]. Priority and Weight have a value of 0 in the example above just for readability purposes. Sanz & Winkler Expires - October 2003 [Page 2]
SRV records to locate whois servers April 2003 Target and Port (in the example "whois.nic.example." and "43") have to be substituted with the values the administrator has chosen for the whois server. 2. Usage The service record functionality is meant as an extension to the existing whois service and not as a new service. If there is a whois server running for a specific domain, such an SRV record can be defined. When used for looking up information about a domain, whois clients can do DNS lookups for SRV records, and can use the retrieved target information to point their whois queries accordingly. This kind of client is called "SRV-cognizant" or "SRV-aware" whois client. It is imaginable that this functionality could be extended for other purposes (like IP address space allocation), but this remains open for a future discussion. 3. Domain search strategy There are two different approaches in general. They both have advantages and disadvantages and will be discussed below. 3.1 Top-Down model The whois client parses the domain name to be looked up. Then the client issues a DNS query for "_nicname._tcp" (QTYPE="SRV", QCLASS="IN") in the TLD of that domain. If the answer is positive, the whois client processes the returned SRV record(s) according to the algorithm defined in RFC 2782 [5] in order to discover the whois server to be queried. The whois client targets now the original whois query to the identified whois server. Regardless of the existence/absence of SRV records at the TLD of the domain (or at any other level), the whois client SHOULD continue querying for SRV records in the subdomains of the previous original domain name, up to the point where that domain name itself is reached. Any returned SRV record does not provide any information about the existence/absence of a service with the same name on subdomains or zones above or below. For instance: If the whois client has to look up the domain "very.weird.example.", in order to locate the corresponding whois server, it CAN do following DNS queries looking for SRV records: QNAME="_nicname._tcp.example.", QTYPE="SRV", QCLASS="IN" Sanz & Winkler Expires - October 2003 [Page 3]
SRV records to locate whois servers April 2003 QNAME="_nicname._tcp.weird.example.", QTYPE="SRV", QCLASS="IN" QNAME="_nicname._tcp.very.weird.example.", QTYPE="SRV", QCLASS="IN" Regardless of the existence/absence of DNS search lists, if the Top- Down model approach is used, this search strategy should be applied. 3.2 Bottom-Up model The whois client takes the complete name, including the leaf element, and issues a DNS query for "_nicname._tcp" (QTYPE="SRV", QCLASS="IN") in the corresponding domain. If the answer is positive, the whois client processes the returned SRV record(s) according to the algorithm defined in [5] in order to discover the whois server to be queried. The whois client targets now the original whois query to the identified whois server. If the answer is not positive the client strips the leftmost element from the name and the query process is repeated; so it walks the DNS tree upwards. This process is repeated until a SRV record is found or the TLD is reached. Clients SHOULD continue the search after they have got a positive answer to look for more additional answers. To avoid unnecessary load on the DNS root servers, a client MUST NOT ask for a whois server for the root domain, i.e. it MUST NOT issue queries for an SRV at "_nicname._tcp.". For instance: If the whois client has to look up the name "www.very.weird.example.", in order to locate the corresponding whois server, it CAN do following DNS queries looking for SRV records: QNAME="_nicname._tcp.www.very.weird.example.", QTYPE="SRV", QCLASS="IN" QNAME="_nicname._tcp.very.weird.example.", QTYPE="SRV", QCLASS="IN" QNAME="_nicname._tcp.weird.example.", QTYPE="SRV", QCLASS="IN" QNAME="_nicname._tcp.example.", QTYPE="SRV", QCLASS="IN" Regardless of the existence/absence of DNS search lists, if the Bottom-Up model approach is used, this search strategy should be applied. 3.3 Conclusion Sanz & Winkler Expires - October 2003 [Page 4]
SRV records to locate whois servers April 2003 The Top-Down model follows the idea that information of domains is stored at a central place (relative within a TLD) as it is handled like a global resource. This resource is centrally managed and delegated and the delegation information is a critical element of the resource data. The Bottom-Up model follows the common idea that information should be looked up as close as possible to the requested object of the query. This goes much more for a decentralized structure of storing information (e.g. organisations could setup their internal whois server for storing local data). The strategy recommended for domain search clients is that it does not stop at the first positive answer independent of Top-Down or Bottom-Up strategy. Clients MAY allow to switch between both strategies. A general purpose client SHOULD default to the Bottom-Up model but specific clients heavily used for domain name lookups SHOULD use the Top-Down model to reduce DNS load and unnecessary lookups. 4. Clarifications The SRV-cognizant whois client MUST NOT modify the domain name to be looked up in the whois server, independently of the domain source of the SRV record. In the absence of a whois protocol whose specification calls for the use of other weighting information, the field Weight in the SRV record keeps the standard meaning specified in [5]. As defined in [5] the client SHOULD abort if it finds a record like: _nicname._tcp IN SRV 0 0 0 . This means the SRV processing SHOULD be aborted at that level, since that record is an explicit statement that the service is not supported there. But nothing avoids the client to search for other SRV records above or below that level. There is no definition of which target should be used by an SRV- cognizant whois client if no whois server could be discovered by means of SRV records. The client MAY try addressing the whois query to "whois".<domain> (cf. RFC 2219 [6]). The use of a default whois server is local dependent. 5. Authority Sanz & Winkler Expires - October 2003 [Page 5]
SRV records to locate whois servers April 2003 There is no authority which defines who should run a whois server. At present, ICANN requires the operation of whois servers by registries of gTLDs, and best practice guidelines for ccTLDs recommend the operation of such a service as well. This means, most of the SRV- cognizant whois clients would already get an SRV record after the first DNS query when following the Top-Down strategy described in this document. However, if the client decides searching for SRV records below that level, more than one whois server could be discovered. There is no authority, and obviously no algorithm, that defines which whois server or whois answer is the right one. 6. Related Work at IETF [7] describes the requirements for the directory services of Internet registries (specifically, domain name registries), which are not specific to any protocol. [7] requires these services to use DNS in order to determine the authoritative source of information about domain names. [8] describes an architectural framework for locating and retrieving information about network resources using LDAP. Although based on a different application level protocol, this document aligns with the query processing model for domains described in [8]. Security Considerations The same security considerations as defined in [5] should apply. There is no discussion on security, data protection and privacy relating to the contents of the whois server in this paper. This is a responsibility of the whois server operator and has nothing to do with a mechanism that describes how whois servers can be discovered. The strategies described in this document could allow an organisation, by means of DNS query logging, to find out who is issuing whois queries about them even without operating a whois server themselves. The strategy described in section 3.2 could allow an organisation to misdirect whois requests to their own whois server containing false information or no information at all. An SRV-cognizant whois client should always display, together with the whois data, the whois server it is getting its data from. References Sanz & Winkler Expires - October 2003 [Page 6]
SRV records to locate whois servers April 2003 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, November 1987 4 Harrenstien, K., "NICNAME/WHOIS", RFC 954, October 1985 5 Gulbrandsen, A., "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000 6 Hamilton, M., "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997 7 [ldap-whois] Hall, E., "The Internet Resource Query Service and the WHOIS Resource Schema", draft-hall-ldap-whois-02, work in progress 8 [crisp-req] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", draft-ietf-crisp-requirements-02, work in progress Acknowledgments We would like to thank Linus Corin, Kim Davies and Peter Koch among others for their useful input. Author's Addresses Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt/Main, Germany Email: sanz@denic.de Gerhard Winkler Vienna University Computer Center / NIC.AT Universitaetsstrasse 7 A-1100 Vienna, Austria Email: gerhard.winkler@univie.ac.at Sanz & Winkler Expires - October 2003 [Page 7]
