[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".<domain> (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