Hi, we have now changed our first version and have incorporated a lot of comments which were made during/after the last RIPE meeting. Please feel free to discuss and send any comments. We will try to move this paper forward. regards, Gerhard draft-whois-srv-02.txt Linus Corin Marcos Sanz Gerhard Winkler 1 July 2002 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 an 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. This situation can be improved by using DNS SRV records and SRV-cognizant whois clients. This document deals with domain information only and it describes how DNS SRV records should be used but it does not define any search strategies (this will be discussed in a additional document). 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. [IANA-NUM] foresees the possibility of a whois service over UDP. Common use is TCP but nothing would prevent from analogously setting the _Proto field to the value _udp. Nevertheless this document deals with the TCP case only. The symbolic name of the service is defined as "nicname" (case insensitive), because it is defined in [RFC 954] in this way; though the most familiar name is "whois". Priority and Weight have a value of 0 in the example above just for readability purposes. It is RECOMMENDED to use the port number 43, as specified in [IANA-NUM]. SRV-cognizant whois clients SHOULD interoperate with traditional whois servers which are in place right now. 2. Usage 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 or handle lookup), but this remains open for a future discussion. 3. Restrictions The service record functionality is meant as an extension to the existing whois service and not as a new service. 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 defined like: _nicname._tcp IN SRV 0 0 0 . This means the SRV processing should be aborted at that level. But nothing avoids the client to search for other SRV records above or under that level. This behavior should be scope of search strategies. The given SRV record does not provide any information about the existance/absence of a service with the same name on subdomains or zones below or above. The search behavior of the client must be defined as it should be independant from conventional DNS search algorithms defined by searchlists. 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 _nicname._tcp. 4. Authority There is no authority which defines who should run a whois server, though it is usual that the TLD registry runs a whois service for the zone where it is authoritative. There is no definition of which target should be used as a default for an SRV-cognizant whois client if no whois server could be discovered by means of SRV records. The use of a default whois server is local dependent. 5. 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 the responsibility of the whois server operator and has nothing to do with a mechanism that describes how whois servers can be reached. A client developer must be aware that DNS search algorithms can lead to this problem: By using DNS query logging an organisation could find out who is issuing whois queries about them even without operating a whois server themselves. 6. 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 2782] A DNS RR for specifying the location of services (DNS SRV) [IANA-NUM] www.iana.org: Directory of General Assigned Numbers 7. 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 -- Gerhard Winkler | E-Mail: gerhard.winkler@univie.ac.at Vienna University Computer Center | Universitaetsstrasse 7 | Tel: +43 1 4277 14035 A-1010 Vienna, Austria | Fax: +43 1 4277 9140