draft-whois-srv-07.txt Linus Corin Marcos Sanz Gerhard Winkler 7 January 2003 Using DNS SRV records to locate whois servers Status of this Memo This document is a draft on the usage of the DNS SRV RR for the location of whois servers. 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 target (in terms of hierarchy) as possible, while preserving the opportunity to locate higher level servers for escalation purposes. 0. Definitions The key words "MUST", "SHOULD", and "RECOMMENDED" in this document are to be interpreted as described in [RFC 2119]. Other terms used in this document are defined in the DNS specification [RFC 1034]. 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]. Priority and Weight have a value of 0 in the example above just for readability purposes. 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. 2.1 Domain search strategy The strategy recommended for domain search follows a top-down model. This model is best suited for searches about global resources which are centrally managed and delegated, and where delegation information is a critical element of the resource data. 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] 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 can 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. 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 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" 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 this search strategy should be applied. 2.2 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 [RFC 2782]. As defined in [RFC 2782] 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". (cf. [RFC 2219]). The use of a default whois server is local dependent. 3. Authority 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 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. 4. Security Considerations The same security considerations as defined in [RFC 2782] 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 strategy described in section 2.1 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. An SRV-cognizant whois client should always display, together with the whois data, the whois server it is getting its data from. 5. Related Work at IETF [crisp-req] describes the requirements for the directory services of Internet registries (specifically, domain name registries), which are not specific to any protocol. [crisp-req] requires these services to use DNS in order to determine the authoritative source of information about domain names. [ldap-whois] 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 [ldap-whois]. 6. Acknowledgements We would like to thank Kim Davies and Peter Koch among others for their useful input. 7. References [RFC 954] NICNAME/WHOIS [RFC 1034] Domain names - concepts and facilities [RFC 2119] Key words for use in RFCs to Indicate Requirement Levels [RFC 2219] Use of DNS Aliases for Network Services [RFC 2782] A DNS RR for specifying the location of services (DNS SRV) [IANA-NUM] www.iana.org: Directory of General Assigned Numbers [ldap-whois] draft-hall-ldap-whois-02, work in progress [crisp-req] draft-ietf-crisp-requirements-02, work in progress 8. Authors' Addresses Linus Corin Telia International Carrier 4th Floor, 330 High Holborn WC1V 7QY London, United Kingdom linus@telia.net Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt/Main, Germany sanz@denic.de Gerhard Winkler Vienna University Computer Center / NIC.AT Universitaetsstrasse 7 A-1100 Vienna, Austria gerhard.winkler@univie.ac.at