From Jim.Reid at nominum.com Wed Apr 24 15:26:22 2002 From: Jim.Reid at nominum.com (Jim Reid) Date: Wed, 24 Apr 2002 06:26:22 -0700 Subject: Draft on using SRV records to locate whois servers Message-ID: <18883.1019654782@shell.nominum.com> Below is a draft of the document Gerhard, Linus and Marcos have been working on. It's been circulated to the list for discussion. Marcos will be giving a presentation on this at the WG meeting next week. Please submit any comments to the authors or, better still, to the mailing list. draft-whois-srv-01.txt Linus Corin Marcos Sanz Gerhard Winkler 24 April 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 There is no common whois database where all domain objects are stored. Several TLDs run their own databases, which can be reached under different network locations and, for the user, there is no easy way to find the right whois server to answer their query by means of a simple whois client. This situation can be improved by using DNS SRV records and SRV-cognizant whois clients. 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: _whois._tcp IN SRV 0 0 43 whois.nic.example. [RFC 1700] 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. The symbolic name of the service is defined as "whois" (case insensitive), which is the most familiar name, though it is also called "nicname" in [RFC 954]. 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 [RFC 1700] or [IANA-NUM]. 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 inetnum 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: _whois._tcp IN SRV 0 0 0 . The given SRV record is valid for the zone where it appears. This means that it does not provide any information on subdomains or zones below; it is a onelevel information. Search for subdomains MUST behave like conventional DNS search algorithms. 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. 6. References [RFC 954] NICNAME/WHOIS [RFC 1034] Domain names - concepts and facilities [RFC 1700] Assigned Numbers [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 at telia.net Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt/Main, Germany sanz at denic.de Gerhard Winkler Vienna University Computer Center / NIC.AT Universitaetsstrasse 7 A-1100 Vienna, Austria gerhard.winkler at univie.ac.at From pk at TechFak.Uni-Bielefeld.DE Sun Apr 28 15:11:07 2002 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Sun, 28 Apr 2002 15:11:07 +0200 Subject: Draft on using SRV records to locate whois servers In-Reply-To: Jim Reid's message of "Wed, 24 Apr 2002 06:26:22 PDT." <18883.1019654782@shell.nominum.com> Message-ID: <200204281311.PAA24769@grimsvotn.TechFak.Uni-Bielefeld.DE> [Jim Reid wrote:] > Below is a draft of the document Gerhard, Linus and Marcos have been > working on. It's been circulated to the list for discussion. Marcos thank you folks for bringing this up. I'm sure this is a good idea and will fill a long standing gap. Find some comments, questions and suggestions below. > 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]. Here's a rough version of a longer problem statement: 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, ince there are TLDs where registration takes place under specialised second level domains (e.g. UK, AT). The Regional Internet Registries (RIR) [reference, anyone?] also provide whois service as part of their coordination task. Again, there is no easy uniform way to find out which RIR is responsible for a particular address or address range. 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 (there are also omniscient clients, like "SuperWhois"). {XXX Bill Manning also had a DNS based AS-number directory} 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. > 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: > > _whois._tcp IN SRV 0 0 43 whois.nic.example. > > > [RFC 1700] 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. RFC 1700 has been superseded by RFC 3232, so I'd suggest to cite either that or the IANA URL, as you do later [IANA-NUM]. Anyway, the whois protocol is not defined for UDP transport regardless of what "assigned numbers" says about port number assignment. The document should clearly say that it deals with the TCP case only. > The symbolic name of the service is defined as "whois" (case > insensitive), which is the most familiar name, though it is also called > "nicname" in [RFC 954]. So, did one want to allow both? I'd stick with "whois", unless there is demand to not only select the service based on the on-the-wire protocol but also based on the data format (e.g. "ripe-whois" vs. "generic-whois"). However, I doubt that this granularity would ease deployment. > 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 [RFC 1700] > or [IANA-NUM]. The document mainly talks about client behaviour, so this recommendation regarding the server's port number seems a bit out of focus to me. And, it's not needed for interoperability since one purpose of SRV RRs is giving an administrator the opportunity of using non default ports. > 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. So, does this mean the SRV RR has to be owned by the domain you are interested in or by its parent? See below for a suggestion of a hierarchical approach. > It is imaginable that this functionality could be extended for other > purposes (like inetnum or handle lookup), but this remains open for a > future discussion. See below for a suggestion for inetnum lookup. > As defined in [RFC 2782] the client SHOULD abort if it finds a record > defined like: > > _whois._tcp IN SRV 0 0 0 . While this copies the definition from RFC 2782, I do not think the client is expected to abort (i.e. terminate) should this condition be met. Instead, only the SRV processing is aborted. IIRC this case was introduced to be able to explicitly state the absence of a particular service (or all services via a wildcard) as opposed to just having no SRV RR. > The given SRV record is valid for the zone where it appears. This means > that it does not provide any information on subdomains or zones below; This may result in a contradiction: If it's valid for the zone, it is also valid for subdomains of the zone apex. And, it costs additional work to find out which zone one actually resides in. And does this mean _whois._tcp.DE leads to a whois server which has no knwledge about Uni-Bielefeld.DE (subdomain and delegated zone in this case)? > it is a onelevel information. Search for subdomains MUST behave like > conventional DNS search algorithms. "conventional" algorithms depend on local search lists, while here you want searching along the domain name subject to the later whois query. In addition, conventional DNS search should not extend beyond domain names within local control (from the queriers point of view) [RFC 1535], while that is what you explicitly want here. However, it still could be abused (see security considerations). I'd think the search is the key feature in locating the whois server and an algorithm should be described, e.g. A whois query for "www.deep.weird.example" will lead to the following DNS queries for SRV RRs: _whois._tcp.www.deep.weird.example _whois._tcp.deep.weird.example _whois._tcp.weird.example _whois._tcp.example Always ask for the complete name first, including the leaf element, then walk up the DNS tree until either a SRV RRSet is found or the TLD is reached. Clients MAY continue the search after they've found a match. However, 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 _whois._tcp. The "stop indicator" (i.e. single member RRSet "SRV 0 0 0 .") does not stop the search but makes the algorithm skip this node. The SRV RRs then could point to a (group of) whois server inside the organisation using the domain name ("weird.example"), to the registry, a registrar's whois server or a web hosters whois server. Question remains what to ask the whois server. If a match is found for _whois._tcp.example, should the server be asked for the full name www.deep.weird.example or just the smallest suffix needed for differentiation ("weird.example")? Are all whois servers capable of "closest match"? And how to deal with the fact that whois servers have no standardized way to indicate they do not know a key queried for. This scheme could be extended to cover inetnum lookups (only the IPv4 case is outlined here): For locating contacts for IPv4 addresses clients should ask in the IN-ADDR.ARPA DNS subtree, starting at the domain name representing the full address, e.g.: A whois query for 192.168.1.1 leads to DNS SRV queries for (in that order): _whois._tcp.1.1.168.192.IN-ADDR.ARPA _whois._tcp.1.168.192.IN-ADDR.ARPA _whois._tcp.168.192.IN-ADDR.ARPA _whois._tcp.192.IN-ADDR.ARPA _whois._tcp.IN-ADDR.ARPA (*) _whois._tcp.ARPA (*) The queries marked with (*) could probably be omitted, since they are not supposed to lead to an answer (there's no central inetnum whois server). Opinions? > 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. In the absence of an appropriate SRV entry, the client MAY try "whois". (see RFC 2219); However, security implications should be payed attention to. > 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. Use of the DNS search algorithm can lead to 2 problems: 1) By using DNS query logging an organisation could find out who is issuing whois queries about them even without operating a whois server themselves 2) An (malicious) organisation could use SRV RRs to misdirect whois requests. For example, a spamhaus using "spamhaus.example" could direct whois queries to their own whois server containing no or false information or even worse, innocent targets. For this reason, whois clients should be able to start the search above the leaf or particular inner nodes upon request. -Peter From pk at TechFak.Uni-Bielefeld.DE Sun Apr 28 17:16:42 2002 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Sun, 28 Apr 2002 17:16:42 +0200 Subject: Draft on using SRV records to locate whois servers In-Reply-To: Your message of "Sun, 28 Apr 2002 17:03:48 +0200." Message-ID: <200204281516.RAA05378@popocatepetl.TechFak.Uni-Bielefeld.DE> Hi Brad, thanks for your comments. Just two short clarifications (I hope :-) > Agreed. In the absence of a searchlist, the standard recursive > search algorithm should be applied. Well, the local resolver's search list would have nothing to do with what we try here, so the resolution process should be independent of it. If I have TechFak.Uni-Bielefeld.DE and Uni-Bielefeld.DE in my search list, that should not alter the way "whois deep.weird.example" is treated. > > for a whois server for the root domain, i.e. it MUST NOT issue queries > > for _whois._tcp. > > Now this I don't understand. We can query for NS records all the > way up to the root zone, and there can be a whois server for the root > zone -- it may only define delegation data for the TLDs, but this is > still valid information). I don't understand why we should never > query for this data, given that it should be the very last query in > the sequence (and first match wins). The contribution to root server load (which suffers from garbage as we will probably learn on Thursday) may indeed be marginal. And you're right, there might be a whois server for the root. But then, "_tcp" would be a TLD and I do not believe it be established, so the queries will be useless. Anyway, this is fine tuning. -Peter From brad.knowles at skynet.be Sun Apr 28 17:03:48 2002 From: brad.knowles at skynet.be (Brad Knowles) Date: Sun, 28 Apr 2002 17:03:48 +0200 Subject: Draft on using SRV records to locate whois servers In-Reply-To: <200204281311.PAA24769@grimsvotn.TechFak.Uni-Bielefeld.DE> References: <200204281311.PAA24769@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: At 3:11 PM +0200 2002/04/28, Peter Koch wrote: > Anyway, the whois protocol > is not defined for UDP transport regardless of what "assigned numbers" > says about port number assignment. The document should clearly say that > it deals with the TCP case only. Agreed. We should only talk about TCP and not mention UDP. > So, did one want to allow both? I'd stick with "whois", unless there is > demand to not only select the service based on the on-the-wire protocol > but also based on the data format (e.g. "ripe-whois" vs. "generic-whois"). > However, I doubt that this granularity would ease deployment. We could mention both "whois" and "nicname", with the observation that the latter is an older, deprecated alias, and SHOULD NOT be used. > The document mainly talks about client behaviour, so this recommendation > regarding the server's port number seems a bit out of focus to me. > And, it's not needed for interoperability since one purpose of SRV RRs is > giving an administrator the opportunity of using non default ports. I think we can mention the standard practice of running whois on port 43, but I definitely agree that one of the best things about SRV records is that they allow us to move things to other ports. > I'd think the search is the key feature in locating the whois server and > an algorithm should be described, e.g. > > A whois query for "www.deep.weird.example" will lead to the following > DNS queries for SRV RRs: > > _whois._tcp.www.deep.weird.example > _whois._tcp.deep.weird.example > _whois._tcp.weird.example > _whois._tcp.example > > Always ask for the complete name first, including the leaf element, then > walk up the DNS tree until either a SRV RRSet is found or the TLD is > reached. Agreed. In the absence of a searchlist, the standard recursive search algorithm should be applied. > Clients MAY continue the search after they've found a match. However, 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 _whois._tcp. Now this I don't understand. We can query for NS records all the way up to the root zone, and there can be a whois server for the root zone -- it may only define delegation data for the TLDs, but this is still valid information). I don't understand why we should never query for this data, given that it should be the very last query in the sequence (and first match wins). > The "stop indicator" (i.e. single member RRSet "SRV 0 0 0 .") does not > stop the search but makes the algorithm skip this node. Good. > Question remains what to ask the whois server. If a match is found for > _whois._tcp.example, should the server be asked for the full name > www.deep.weird.example or just the smallest suffix needed for differentiation > ("weird.example")? Are all whois servers capable of "closest match"? > And how to deal with the fact that whois servers have no standardized way to > indicate they do not know a key queried for. I believe that we should use a similar recursive algorithm for what is looked up in the whois server, just as we do for finding out which whois server is appropriate. So, we would first look up www.deep.weird.example, and if that's not defined we would then look up deep.weird.example, and then weird.example, etc.... > A whois query for 192.168.1.1 leads to DNS SRV queries for (in that order): > > _whois._tcp.1.1.168.192.IN-ADDR.ARPA > _whois._tcp.1.168.192.IN-ADDR.ARPA > _whois._tcp.168.192.IN-ADDR.ARPA > _whois._tcp.192.IN-ADDR.ARPA > _whois._tcp.IN-ADDR.ARPA (*) > _whois._tcp.ARPA (*) > > The queries marked with (*) could probably be omitted, since they are not > supposed to lead to an answer (there's no central inetnum whois server). The last two queries are sub-optimal, yes. We could (and should) recommend that people avoid making these queries in their clients, for obvious performance reasons. However, I would not rule them out entirely -- what if we're looking up information that is only contained within the top-level IPv4 or IPv6 registry, and therefore we really would want to query _whois._tcp.IN-ADDR.ARPA or even _whois._tcp.ARPA. > 2) An (malicious) organisation could use SRV RRs to misdirect whois requests. > For example, a spamhaus using "spamhaus.example" could direct whois > queries to their own whois server containing no or false information or > even worse, innocent targets. For this reason, whois clients should be > able to start the search above the leaf or particular inner nodes upon > request. I would go so far as to say that whois clients should query for both the level of the query as well as the level of the parent of the query, by default. We can see this behaviour on the horizon already, and we should be prepared for it now. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania.