idnits 2.17.1 draft-sanz-whois-srv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2004) is 7313 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 13 looks like a reference -- Missing reference section? '2' on line 56 looks like a reference -- Missing reference section? '3' on line 58 looks like a reference -- Missing reference section? '4' on line 88 looks like a reference -- Missing reference section? '5' on line 264 looks like a reference -- Missing reference section? '6' on line 234 looks like a reference -- Missing reference section? '7' on line 253 looks like a reference -- Missing reference section? '8' on line 260 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Marcos Sanz 2 Internet Draft DENIC eG 3 Document: draft-sanz-whois-srv-01.txt Gerhard Winkler 4 NIC.AT 5 Expires: October 2004 April 2004 7 Using DNS SRV records to locate whois servers 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Whois servers are used to locate administrative, technical and 32 security contacts for given IP addresses, domain names or other 33 network objects associated with an organisation, e.g. AS numbers. 34 While usually Top Level Domain (TLD) registries run a whois server, 35 there is no generic name for it and it may not even be obvious that 36 the TLD registry's whois server is the right one to ask, since there 37 are TLDs where registration takes place under specialised second 38 level domains (e.g. UK, AT). The Regional Internet Registries (RIR) 39 also provide whois service as part of their coordination task. 41 All this can be solved by central "master" or "meta" whois servers, 42 which keep track of all new and changing servers and refer to the DNS 43 registries' or RIRs' whois servers. 45 This document proposes a DNS-based approach which eliminates the need 46 for a central master repository and works down to lower levels in the 47 hierarchy. It is the intent to locate a whois server as close to the 48 target (in terms of hierarchy) as possible, while preserving the 49 opportunity to locate higher level servers for escalation purposes. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC-2119 [2]. 57 Other terms used in this document are defined in the DNS 58 specification RFC-1034 [3]. 60 Table of Contents 62 1. Format.........................................................2 63 2. Usage..........................................................3 64 3. Domain search strategy.........................................3 65 3.1 Top-Down model.............................................3 66 3.2 Bottom-Up model............................................4 67 3.3 Conclusion.................................................4 68 4. Clarifications.................................................5 69 5. Authority......................................................5 70 6. Related Work at IETF...........................................6 71 Security Considerations...........................................6 72 References........................................................6 73 Acknowledgments...................................................7 74 Author's Addresses................................................7 76 1. Format 78 The general format of DNS SRV records is documented in RFC 2782: 80 _Service._Proto.Name TTL Class SRV Priority Weight Port Target 82 Therefore the simplest format of an SRV record to locate a whois 83 server is: 85 _nicname._tcp IN SRV 0 0 43 whois.nic.example. 87 The symbolic name of the service is defined as "nicname" (case 88 insensitive) and the protocol is TCP based, as per RFC 954 [4]. 90 Priority and Weight have a value of 0 in the example above just for 91 readability purposes. 93 Target and Port (in the example "whois.nic.example." and "43") have 94 to be substituted with the values the administrator has chosen for 95 the whois server. 97 2. Usage 99 The service record functionality is meant as an extension to the 100 existing whois service and not as a new service. If there is a whois 101 server running for a specific domain, such an SRV record can be 102 defined. When used for looking up information about a domain, whois 103 clients can do DNS lookups for SRV records, and can use the retrieved 104 target information to point their whois queries accordingly. This 105 kind of client is called "SRV-cognizant" or "SRV-aware" whois client. 107 It is imaginable that this functionality could be extended for other 108 purposes (like IP address space allocation), but this remains open 109 for a future discussion. 111 3. Domain search strategy 113 There are two different approaches in general. They both have 114 advantages and disadvantages and will be discussed below. 116 3.1 Top-Down model 118 The whois client parses the domain name to be looked up. Then the 119 client issues a DNS query for "_nicname._tcp" (QTYPE="SRV", 120 QCLASS="IN") in the TLD of that domain. 122 If the answer is positive, the whois client processes the returned 123 SRV record(s) according to the algorithm defined in RFC 2782 [5] in 124 order to discover the whois server to be queried. The whois client 125 targets now the original whois query to the identified whois server. 127 Regardless of the existence/absence of SRV records at the TLD of the 128 domain (or at any other level), the whois client SHOULD continue 129 querying for SRV records in the subdomains of the previous original 130 domain name, up to the point where that domain name itself is 131 reached. Any returned SRV record does not provide any information 132 about the existence/absence of a service with the same name on 133 subdomains or zones above or below. 135 For instance: 137 If the whois client has to look up the domain "very.weird.example.", 138 in order to locate the corresponding whois server, it CAN do 139 following DNS queries looking for SRV records: 141 QNAME="_nicname._tcp.example.", QTYPE="SRV", QCLASS="IN" 142 QNAME="_nicname._tcp.weird.example.", QTYPE="SRV", QCLASS="IN" 143 QNAME="_nicname._tcp.very.weird.example.", QTYPE="SRV", QCLASS="IN" 145 Regardless of the existence/absence of DNS search lists, if the Top- 146 Down model approach is used, this search strategy should be applied. 148 3.2 Bottom-Up model 150 The whois client takes the complete name, including the leaf element, 151 and issues a DNS query for "_nicname._tcp" (QTYPE="SRV", QCLASS="IN") 152 in the corresponding domain. 154 If the answer is positive, the whois client processes the returned 155 SRV record(s) according to the algorithm defined in [5] in order to 156 discover the whois server to be queried. The whois client targets now 157 the original whois query to the identified whois server. 159 If the answer is not positive the client strips the leftmost element 160 from the name and the query process is repeated; so it walks the DNS 161 tree upwards. 163 This process is repeated until a SRV record is found or the TLD is 164 reached. 166 Clients SHOULD continue the search after they have got a positive 167 answer to look for more additional answers. 169 To avoid unnecessary load on the DNS root servers, a client MUST NOT 170 ask for a whois server for the root domain, i.e. it MUST NOT issue 171 queries for an SRV at "_nicname._tcp.". 173 For instance: 175 If the whois client has to look up the name 176 "www.very.weird.example.", in order to locate the corresponding whois 177 server, it CAN do following DNS queries looking for SRV records: 179 QNAME="_nicname._tcp.www.very.weird.example.", QTYPE="SRV", 180 QCLASS="IN" 181 QNAME="_nicname._tcp.very.weird.example.", QTYPE="SRV", QCLASS="IN" 182 QNAME="_nicname._tcp.weird.example.", QTYPE="SRV", QCLASS="IN" 183 QNAME="_nicname._tcp.example.", QTYPE="SRV", QCLASS="IN" 185 Regardless of the existence/absence of DNS search lists, if the 186 Bottom-Up model approach is used, this search strategy should be 187 applied. 189 3.3 Conclusion 190 The Top-Down model follows the idea that information of domains is 191 stored at a central place (relative within a TLD) as it is handled 192 like a global resource. This resource is centrally managed and 193 delegated and the delegation information is a critical element of the 194 resource data. 196 The Bottom-Up model follows the common idea that information should 197 be looked up as close as possible to the requested object of the 198 query. This goes much more for a decentralized structure of storing 199 information (e.g. organisations could setup their internal whois 200 server for storing local data). 202 The strategy recommended for domain search clients is that it does 203 not stop at the first positive answer independent of Top-Down or 204 Bottom-Up strategy. 206 Clients MAY allow to switch between both strategies. 208 A general purpose client SHOULD default to the Bottom-Up model but 209 specific clients heavily used for domain name lookups SHOULD use the 210 Top-Down model to reduce DNS load and unnecessary lookups. 212 4. Clarifications 214 The SRV-cognizant whois client MUST NOT modify the domain name to be 215 looked up in the whois server, independently of the domain source of 216 the SRV record. 218 In the absence of a whois protocol whose specification calls for the 219 use of other weighting information, the field Weight in the SRV 220 record keeps the standard meaning specified in [5]. 222 As defined in [5] the client SHOULD abort if it finds a record like: 224 _nicname._tcp IN SRV 0 0 0 . 226 This means the SRV processing SHOULD be aborted at that level, since 227 that record is an explicit statement that the service is not 228 supported there. But nothing avoids the client to search for other 229 SRV records above or below that level. 231 There is no definition of which target should be used by an SRV- 232 cognizant whois client if no whois server could be discovered by 233 means of SRV records. The client MAY try addressing the whois query 234 to "whois". (cf. RFC 2219 [6]). The use of a default whois 235 server is local dependent. 237 5. Authority 238 There is no authority which defines who should run a whois server. At 239 present, ICANN requires the operation of whois servers by registries 240 of gTLDs, and best practice guidelines for ccTLDs recommend the 241 operation of such a service as well. This means, most of the SRV- 242 cognizant whois clients would already get an SRV record after the 243 first DNS query when following the Top-Down strategy described in 244 this document. However, if the client decides searching for SRV 245 records below that level, more than one whois server could be 246 discovered. There is no authority, and obviously no algorithm, that 247 defines which whois server or whois answer is the right one. 249 6. Related Work at IETF 251 [7] describes the requirements for the directory services of Internet 252 registries (specifically, domain name registries), which are not 253 specific to any protocol. [7] requires these services to use DNS in 254 order to determine the authoritative source of information about 255 domain names. 257 [8] describes an architectural framework for locating and retrieving 258 information about network resources using LDAP. Although based on a 259 different application level protocol, this document aligns with the 260 query processing model for domains described in [8]. 262 Security Considerations 264 The same security considerations as defined in [5] should apply. 266 There is no discussion on security, data protection and privacy 267 relating to the contents of the whois server in this paper. This is a 268 responsibility of the whois server operator and has nothing to do 269 with a mechanism that describes how whois servers can be discovered. 271 The strategies described in this document could allow an 272 organisation, by means of DNS query logging, to find out who is 273 issuing whois queries about them even without operating a whois 274 server themselves. 276 The strategy described in section 3.2 could allow an organisation to 277 misdirect whois requests to their own whois server containing false 278 information or no information at all. 280 An SRV-cognizant whois client should always display, together with 281 the whois data, the whois server it is getting its data from. 283 References 284 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 285 9, RFC 2026, October 1996. 287 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 288 Levels", BCP 14, RFC 2119, March 1997 290 3 Mockapetris, P., "Domain names - concepts and facilities", RFC 291 1034, November 1987 293 4 Harrenstien, K., "NICNAME/WHOIS", RFC 954, October 1985 295 5 Gulbrandsen, A., "A DNS RR for specifying the location of services 296 (DNS SRV)", RFC 2782, February 2000 298 6 Hamilton, M., "Use of DNS Aliases for Network Services", BCP 17, 299 RFC 2219, October 1997 301 7 [ldap-whois] Hall, E., "The Internet Resource Query Service and 302 the WHOIS Resource Schema", draft-hall-ldap-whois-02, work in 303 progress 305 8 [crisp-req] Newton, A., "Cross Registry Internet Service Protocol 306 (CRISP) Requirements", draft-ietf-crisp-requirements-02, work in 307 progress 309 Acknowledgments 311 We would like to thank Linus Corin, Kim Davies and Peter Koch among 312 others for their useful input. 314 Author's Addresses 316 Marcos Sanz 317 DENIC eG 318 Wiesenhuettenplatz 26 319 D-60329 Frankfurt/Main, Germany 320 Email: sanz@denic.de 322 Gerhard Winkler 323 Vienna University Computer Center / NIC.AT 324 Universitaetsstrasse 7 325 A-1100 Vienna, Austria 326 Email: gerhard.winkler@univie.ac.at