From sanz at denic.de Wed May 1 01:04:20 2002 From: sanz at denic.de (Marcos Sanz/Denic) Date: Wed, 1 May 2002 01:04:20 +0200 Subject: Draft on using SRV records to locate whois servers Message-ID: Thanks for your feedback, Peter. Find comments below. On 28.04.2002 15:11 Peter Koch wrote: > Here's a rough version of a longer problem statement: Nice ellaboration! We will incorporate it (maybe partially) in the next version. > The Regional Internet Registries (RIR) [reference, anyone?] also provide whois We already searched for references on that, but did not found any. > 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. We explicitly left out such kind of remarks, since we wanted to limit the draft to locating Whois servers for domain lookups. We are already collecting ideas for an extension draft about recommended behaviour of SRV-cognizant whois clients and remarks are very welcome. > > 1. Format [...] > > [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 Overseen that, thanks. We will fix it for the next version. > The document should clearly say that it deals with the > TCP case only. We thought we should just leave it open. Any other opinions on that? > > 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. We stick with "whois", as well. One could even think of selecting the service based on the type of data to be queried ("contact-whois", "domain-whois", ?) as Gerhard once observed, but as you say, it is a compromise between hype features and ease of deployment. > > 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 you want client-server interoperability for the "thing" we call "protocol whois" nowadays, you SHOULD set the port to 43. Any other value would be correctly handled by SRV-cognizant clients, but those servers would not be reachable by conventional clients. > > 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. Actually, there might be SRV RRs at several levels, and the loose formulation tries on purpose not to address the issue at that point. > > 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. I would even add: the SRV processing should be aborted _at that level_. Nothing avoids for the client to search for SRV above (or under) that level. But we thought such refinements were out of scope at that moment and were an issue for another draft, as already mentioned. > > 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)? The formulation is indeed missleading. What about: "The SRV record does not provide any information about the existence/absence of a service with the same name on subdomains or zones below". > > 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 think this is a wording problem, as well. I will leave it to Gerhard, since he authored that line. > I'd think the search is the key feature in locating the whois server and > an algorithm should be described, e.g. That is a possible procedure. We take note. > 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")? Not asking for the full name could result in delivering an answer for a question that was not asked. > Are all whois servers capable of "closest match"? No > And how to deal with the fact that whois servers have no standardized way to > indicate they do not know a key queried for. Once the server has been reached by means of SRV, contents transmitted are not relevant the process. > This scheme could be extended to cover inetnum lookups (only the IPv4 case is > outlined here): [...] > Opinions? Fine! > > 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); Thanks for the reference, we'll take a look at it. > 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. Both are real good points. They directly depend upon the behaviour of the SRV client, which is not determined here (top to bottom? bottom to top? stop walking the tree after answer?). Nevertheless, I think 1) finds a place in our draft, as a direct effect of the interaction between Whois and DNS. Regards, Marcos From james.raftery at ucd.ie Wed May 1 16:18:46 2002 From: james.raftery at ucd.ie (James Raftery) Date: Wed, 1 May 2002 15:18:46 +0100 Subject: Draft on using SRV records to locate whois servers In-Reply-To: <18883.1019654782@shell.nominum.com> Message-ID: <20020501141846.GB2796@bender.kerna.ie> Hi, I have two points to make on the draft. They relate to the SRV owner name as envisaged by this draft and to the requirements for SRV targets. Firstly, this draft appears to use different semantics for the domain name of an SRV RR than those in RFC2782. My reading of 2782 is that the ``name'' portion of the RR owner (i.e. the name component of _service._protocol.name) is analogous to the server name the client wants to contact. Without SRV records, if I wish to use whois to talk to a server named whois.isp.net I should lookup the A record of whois.isp.net and contact that host. With SRV I should lookup the SRV of _whois._tcp.whois.isp.net and contact the host specified by the A record owned by the SRV target. If I were the operator of a whois server whose published name was ``whois.isp.net'' I might have the following in the isp.net zone to support that second scenario: $ORIGIN isp.net. _whois._tcp.whois IN SRV 10 0 43 dbserver.isp.net. IN SRV 20 0 43 dbbackup.isp.net. dbserver IN A 10.10.10.1 dbbackup IN A 10.20.20.1 SRVs are for adding indirection (amongst other features) to the names people type into browser address bars, MUA configurations and -h options to their whois clients. This draft changes the semantic meaning of the SRV ``name'' when used in a whois context to be ``a whois query string, or a domain above it in the DNS tree''. 2782 says if you want to contact host foo for service X over protocol Y, then lookup "_X._Y.foo IN SRV". This draft says if you want to send a query ABOUT foo to a whois server, lookup "_whois._tcp.foo IN SRV". The semantic meaning of ``foo'' has changed and that change is not explicitly stated. I would like it to be. Secondly, I feel a reminder that the target of an SRV must have an A RR is in order. Taking my isp.net example, above, again. If I controlled customer.com and wanted to use the mechanism in this draft to publish the fact that customer.com is in isp.net's whois server I cannot use: _whois._tcp.customer.com. IN SRV 10 0 43 whois.isp.net. as ``whois.isp.net'' does not have an A RR. I must ``undo'' the name indirection desired by isp.net and instead publish the following RRs (and keep them up to date): _whois._tcp.customer.com. IN SRV 10 0 43 dbserver.isp.net. IN SRV 20 0 43 dbbackup.isp.net. As an aside, when this was first mooted some years ago I wrote a SRV-aware whois client which implemented the mechanism is this draft. Recently I decided it made much more sense to have a SRV whois client that used SRVs in the way I think 2782 intended. My client does SRV processing on the ``server name''. Since this draft appeared I integrated both modes of operation. The support for this draft is referred to as ``wacky mode'' - no offence is intended :-) If anybody wants to play with it, it's at http://romana.now.ie/software/srv-whois Written in perl, requires Net::DNS. More testing would be great as would comments. Example: whois-srv -h whois.denic.de www.foo.de will do - SRV query for _whois._tcp.whois.denic.de and contact the target - If no SRV, do A query for whois.denic.de -- i.e. act as a normal client whois-srv -W -h whois.denic.de www.foo.de will do - SRV query for _whois._tcp.www.foo.de and contact the target - If no SRV, contact target of the _whois._tcp.foo.de SRV - If no SRV, contact target of the _whois._tcp.de SRV - If no SRV, do A query for whois.denic.de -- i.e. act as a normal client Regards, james From sanz at denic.de Wed May 1 18:20:01 2002 From: sanz at denic.de (Marcos Sanz/Denic) Date: Wed, 1 May 2002 18:20:01 +0200 Subject: Draft on using SRV records to locate whois servers Message-ID: James, thanks for your feedback. > Without SRV records, if I wish to use whois to talk to a server named > whois.isp.net I should lookup the A record of whois.isp.net and > contact that host. > > With SRV I should lookup the SRV of _whois._tcp.whois.isp.net and > contact the host specified by the A record owned by the SRV target. Let's say that isp.net (gosh, they really exist) do not know about RFC2219 and run their whois service under the alias foobar.isp.net. How should an SRV-cognizant whois client ever come to the idea of looking up an SRV of the form "_whois._tcp.blafasel.isp.net"? This is precisely the problem that we want to get rid of and with that interpretation of RFC2782 we are reintroducing it again. > Secondly, I feel a reminder that the target of an SRV must have an A RR > is in order. Taking my isp.net example, above, again. If I controlled > customer.com and wanted to use the mechanism in this draft to publish > the fact that customer.com is in isp.net's whois server I cannot use: > > _whois._tcp.customer.com. IN SRV 10 0 43 whois.isp.net. > > as ``whois.isp.net'' does not have an A RR. I must ``undo'' the > name indirection desired by isp.net and instead publish the following > RRs (and keep them up to date): Right, the reminder about the A RR is in order. On the other hand, this way of "undoing the indirection" and trying to keep it up to date is not very practical. Does somebody have any ideas on that? > referred to as ``wacky mode'' - no offence is intended :-) If anybody > wants to play with it, it's at > > http://romana.now.ie/software/srv-whois I really must be wacky, I cannot find it! :-P Regards, Marcos From pk at TechFak.Uni-Bielefeld.DE Wed May 1 18:36:46 2002 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Wed, 01 May 2002 18:36:46 +0200 Subject: Draft on using SRV records to locate whois servers In-Reply-To: Your message of "Wed, 01 May 2002 15:18:46 BST." <20020501141846.GB2796@bender.kerna.ie> Message-ID: <200205011636.SAA05940@popocatepetl.TechFak.Uni-Bielefeld.DE> James Raftery wrote: > 2782 says if you want to contact host foo for service X over protocol Y, > then lookup "_X._Y.foo IN SRV". This draft says if you want to send a > query ABOUT foo to a whois server, lookup "_whois._tcp.foo IN SRV". The > semantic meaning of ``foo'' has changed and that change is not explicitly > stated. I would like it to be. RFC 2782 says in "Overview and rationale", 3rd paragraph: Clients ask for a specific service/protocol for a specific domain (the word domain is used here in the strict RFC 1034 sense), and get back the names of any available servers. The wording in the introductory example also supports this. In the case of "whois.denic.de" you actually do not want the whois server offering info about "denic.de" but that one covering "DE" (although they happen to be the same, but you have to *know* that in advance). SRV RRs are not only meant to (re-)direct host specific services, but also domain (or organisation) based services. This is what comes to use in this case. The "whois" or maybe "finger" or even "www" cases are special since there are common DNS aliases (RFC 2219) for them. SRV avoids cluttering the "visible" part of your name space by moving services into the "_" area. > Secondly, I feel a reminder that the target of an SRV must have an A RR > is in order. Taking my isp.net example, above, again. If I controlled > customer.com and wanted to use the mechanism in this draft to publish > the fact that customer.com is in isp.net's whois server I cannot use: > > _whois._tcp.customer.com. IN SRV 10 0 43 whois.isp.net. > > as ``whois.isp.net'' does not have an A RR. I must ``undo'' the > name indirection desired by isp.net and instead publish the following > RRs (and keep them up to date): > > _whois._tcp.customer.com. IN SRV 10 0 43 dbserver.isp.net. > IN SRV 20 0 43 dbbackup.isp.net. I wonder whether this will happen very often (i.e. we'll have to discuss, what the actual problem/task is we're going to solve). This might occur in cases where the registrar (instead of the registry) keeps the whois data and each and every domain will have to point to the appropriate one. However, unless the customer is running an additional whois server on their own, you might get away with a CNAME RR instead of "unrolling" the SRV. > http://romana.now.ie/software/srv-whois Sounds interesting. I'll play wit it later. -Peter From niallm-ripe at enigma.ie Wed May 1 22:22:11 2002 From: niallm-ripe at enigma.ie (Niall Richard Murphy) Date: Wed, 1 May 2002 21:22:11 +0100 Subject: Draft on using SRV records to locate whois servers In-Reply-To: ; from sanz@denic.de on Wed, May 01, 2002 at 06:20:01PM +0200 References: Message-ID: <20020501212211.A23603@enigma.ie> On Wed, May 01, 2002 at 06:20:01PM +0200, Marcos Sanz/Denic wrote: Marcos et al, > > http://romana.now.ie/software/srv-whois > I really must be wacky, I cannot find it! :-P Try http://romana.now.ie/software/whois-srv instead Niall -- Enigma Consulting Limited: Security, UNIX and telecommunications consultants. Address: Floor 2, 45 Dawson Street, Dublin 2, Ireland. http://www.enigma.ie/ From brad.knowles at skynet.be Wed May 1 18:01:32 2002 From: brad.knowles at skynet.be (Brad Knowles) Date: Wed, 1 May 2002 18:01:32 +0200 Subject: Draft on using SRV records to locate whois servers In-Reply-To: <20020501141846.GB2796@bender.kerna.ie> References: <20020501141846.GB2796@bender.kerna.ie> Message-ID: At 3:18 PM +0100 2002/05/01, James Raftery wrote: > Firstly, this draft appears to use different semantics for the domain > name of an SRV RR than those in RFC2782. My reading of 2782 is that the > ``name'' portion of the RR owner (i.e. the name component of > _service._protocol.name) is analogous to the server name the client > wants to contact. > > Without SRV records, if I wish to use whois to talk to a server named > whois.isp.net I should lookup the A record of whois.isp.net and > contact that host. > > With SRV I should lookup the SRV of _whois._tcp.whois.isp.net and > contact the host specified by the A record owned by the SRV target. Not correct. Think about mail and the MX record. You don't want to send mail to user at a.mx.aol.com, you want to send mail to user at aol.com. So, you look up the MX records for aol.com. Likewise for whois. You don't want the whois information for the server whois.domain.example, you want the whois information for domain.example itself, which is a different question. You only fall back to using whois.domain.example in the case where no SRV record exists for the whois service. > 2782 says if you want to contact host foo for service X over protocol Y, > then lookup "_X._Y.foo IN SRV". Correct. > This draft says if you want to send a > query ABOUT foo to a whois server, lookup "_whois._tcp.foo IN SRV". Correct. Note that this is not "_whois._tcp.whois.foo IN SRV". > The > semantic meaning of ``foo'' has changed and that change is not explicitly > stated. I would like it to be. I believe that you have misunderstood, or at least you are not sufficiently explaining exactly where in the draft you are seeing this apparent change. > Secondly, I feel a reminder that the target of an SRV must have an A RR > is in order. Taking my isp.net example, above, again. If I controlled > customer.com and wanted to use the mechanism in this draft to publish > the fact that customer.com is in isp.net's whois server I cannot use: > > _whois._tcp.customer.com. IN SRV 10 0 43 whois.isp.net. > > as ``whois.isp.net'' does not have an A RR. No, you wouldn't provide the glue for it in your zone, but the owner may very well have an A record defined somewhere else, presumably within the isp.net zone. > I must ``undo'' the > name indirection desired by isp.net and instead publish the following > RRs (and keep them up to date): > > _whois._tcp.customer.com. IN SRV 10 0 43 dbserver.isp.net. > IN SRV 20 0 43 dbbackup.isp.net. I don't see how the RHS of this example is any different from the RHS of the example given above. Who says that whois.isp.net is not a perfectly valid host/domain name, which resolves to an A record, possibly among a whole host of other things? -- 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. From bruce.campbell at ripe.net Thu May 2 15:33:02 2002 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Thu, 2 May 2002 15:33:02 +0200 (CEST) Subject: Draft on using SRV records to locate whois servers In-Reply-To: Message-ID: On Wed, 1 May 2002, Brad Knowles wrote: > At 3:18 PM +0100 2002/05/01, James Raftery wrote: > > > Without SRV records, if I wish to use whois to talk to a server named > > whois.isp.net I should lookup the A record of whois.isp.net and > > contact that host. Yes. > > With SRV I should lookup the SRV of _whois._tcp.whois.isp.net and > > contact the host specified by the A record owned by the SRV target. No. > Not correct. Think about mail and the MX record. You don't want > to send mail to user at a.mx.aol.com, you want to send mail to > user at aol.com. So, you look up the MX records for aol.com. Yes and no. The main difference (as I understand it and how I feel it should work) is that a search for an MX is an one level search; you try to find MX records for the domain 'aol.com', not the parent ('.com') or any children ('www.aol.com'). Most of this is similar to the SRV-specific information in the draft below, although the idea (using SRV records for whois) has been independently suggested by a number of people. http://www.ietf.org/internet-drafts/draft-hall-ldap-whois-01.txt A search for a whois server for a given record should start at the level that you want to find, and work down to the root until a match _that makes sense_ is found. To find a whois server for the domain, foobar.example.com, you would attempt to find SRV records for the following (in order): _nicname._tcp.foobar.example.com _nicname._tcp.example.com _nicname._tcp.com ( Note qualification by Patrik in dns-wg session, the protocol name recorded by IANA is 'nicname', not 'whois'. ) When you find a match from one of the above that makes sense, you then lookup the address record for the whois server, and contact it as per normal semantics, eg: _nicname._tcp.foobar.example.com (no match) _nicname._tcp.example.com IN SRV 0 0 43 whois.example.com whois.example.com IN A 192.168.192.168 whois -h whois.example.com foobar.example.com In the case that example.com's whois service is, shall we say, less than optimum, then you could also look for a record: _nicname._tcp.com (although the only information that you'd expect to get there is registration details for 'example.com', not 'foobar.example.com') You could also apply this to the reverse, eg: _nicname._tcp.3.2.1.193.in-addr.arpa _nicname._tcp.2.1.193.in-addr.arpa _nicname._tcp.1.193.in-addr.arpa _nicname._tcp.193.in-addr.arpa IN SRV 0 0 43 whois.ripe.net ( or at any point in the chain ) -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations From pk at TechFak.Uni-Bielefeld.DE Mon May 13 11:33:31 2002 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Mon, 13 May 2002 11:33:31 +0200 Subject: DNS WG @ RIPE 42: draft minutes available Message-ID: <200205130933.LAA29499@grimsvotn.TechFak.Uni-Bielefeld.DE> Folks, the draft minutes of our working group meeting in Amsterdam are now available: http://www/ripe/wg/dns/r42-minutes.html Thanks to Olaf and Daniel for their work. Please send comments and remarks to . Also, some of the presentations can be accessed via http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/index.html#dns Anyone else who gave a presentation is invited to send a pointer to the above address. -Peter