You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Pierre THIERRY <pi...@moine-fou.org> on 2004/04/21 11:36:08 UTC
Implement SRV DNS
I post this feature request after having created an issue. Having not
read carefully the subversion issue tracker guidelines, I did not ask on
the list before (issue 1839). Here is my issue's content:
> The RFC 2782 describes DNS Resources Records providing information
> about location of services (like the deprecated WKS RR). Subversion
> should implement this feature.
>
> Thus when accessing the following URL:
>
> svn://domain.tld/repos
>
> the client would retrieve the SRV RR for _svn._tcp.domain.tld, that
> would be of the form
>
> 1 0 3690 main-svn-server.domain.tld
> 2 0 13690 backup-svn-server.domain.tld
>
> And the client would contact main-svn-server on its port 3690. If
> connection is not possible, the client would try backup-svn-server on
> port 13690...
The SRV RR is really a very interesting feature of the DNS, as it allows
great flexibility, and even load-balancing. There is also a library to
deal with it, libsrv <http://libsrv.sourceforge.net/>.
Quickly,
le Moine Fou
--
pierre.thierry@moine-fou.org
OpenPGP 0xD9D50D8A
Re: Implement SRV DNS
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-04-21 at 13:55, John Peacock wrote:
> > The ultimate output of a SRV resolution is the same as the output of an
> > A resolution: a list of IP addresses. (In the SRV case the order of
> > those addresses is well-defined, while in the A case it is not, but from
> > the application's point of view that doesn't matter.) It would be no
> > worse to try only the first address we see from the SRV lookup than it
> > is to try only the first address we see from the A lookup.
> With the proviso that SRV queries return multiple values (Priority, Weight,
> Port, and Target) in each answer, whereas A queries return only a list of
> addresses. A quick reading of RFC2782 seems to suggest that the client should
> perform the sorting by Priority/Weight (the server doesn't apparently have to
> return the records in any given order). This does complicate the client
> interface for (I would argue) very little benefit.
I said "the ultimate output of a SRV resolution." After you parse the
SRV records, you sort them according to priorities and randomize them
within identical priorities according to weights. Then you resolve the
resulting A records (or you do that lazily, but that might mean more
complexity from the application's point of view, and glue records mean
that you'll generally do just as well to resolve all the A records right
away) and you have a list of IP addresses, just like I said.
Just because the client has to take care of the work doesn't mean the
application has to. We certainly wouldn't want to have our own code to
parse the SRV record format, so there's no reason to believe we would
want to have our own code to worry about priorities and weights either.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Implement SRV DNS
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> But their use of SRV records has nothing to do with any sin they might
> have committed in this area. A bogus SRV lookup consumes no more
> resources than a bogus A lookup. I can understand the temptation to
> criticize Microsoft for their sins, but it really does derail the
> discussion.
It was meant as an aside; he was referring to Microsoft's usage of SRV as
evidence of SRV's general utility. I was just suggesting that it isn't a
particularly good example. Your two (SIP and non-Microsoft Kerberos) are better
examples. I'm sorry I let my biases show. ;)
> The ultimate output of a SRV resolution is the same as the output of an
> A resolution: a list of IP addresses. (In the SRV case the order of
> those addresses is well-defined, while in the A case it is not, but from
> the application's point of view that doesn't matter.) It would be no
> worse to try only the first address we see from the SRV lookup than it
> is to try only the first address we see from the A lookup.
With the proviso that SRV queries return multiple values (Priority, Weight,
Port, and Target) in each answer, whereas A queries return only a list of
addresses. A quick reading of RFC2782 seems to suggest that the client should
perform the sorting by Priority/Weight (the server doesn't apparently have to
return the records in any given order). This does complicate the client
interface for (I would argue) very little benefit.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Implement SRV DNS
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-04-21 at 13:18, John Peacock wrote:
> I meant the larger issue of how Active Directory attempts to turn DNS into
> something like a general purpose database protocol. The number of queries
> required to resolve AD records is quite obnoxious.
But their use of SRV records has nothing to do with any sin they might
have committed in this area. A bogus SRV lookup consumes no more
resources than a bogus A lookup. I can understand the temptation to
criticize Microsoft for their sins, but it really does derail the
discussion.
> > SRV records don't form a chain.
>
> Poor choice of words on my part. I meant that the Subversion client would need
> to track all possible answers and try them in order (after suitable timeouts if
> necessary). It is a much more complicated process than simply requesting an
> address from a name and trying the connection.
The ultimate output of a SRV resolution is the same as the output of an
A resolution: a list of IP addresses. (In the SRV case the order of
those addresses is well-defined, while in the A case it is not, but from
the application's point of view that doesn't matter.) It would be no
worse to try only the first address we see from the SRV lookup than it
is to try only the first address we see from the A lookup.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Implement SRV DNS
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
>>OK, that's one then (and yes I was already aware of it). I also happen to
>>believe that M$loth's implementation of DNS records in this instance is an abuse
>>of the core protocol.
>
>
> And why is this an abuse of "the core protocol?"
I meant the larger issue of how Active Directory attempts to turn DNS into
something like a general purpose database protocol. The number of queries
required to resolve AD records is quite obnoxious.
There have been several studies in the media that suggest that up to 20% of all
query hits to the root nameservers are bogus, of which a lot were misplaced AD
queries. Sure, those hits all came from misconfigured clients and networks, but
it was M$loth's great implementation that is ultimately at fault.
>>In addition, the Subversion client would be required to link to a resolver
>>library to make use of this feature. Right now, the client merely requests the
>>IP address associated with a name, then opens a connection to the requested port
>>on that address. Implementing SRV would require yet another platform
>>independent library to resolve the chain of SRV records.
>
>
> SRV records don't form a chain.
Poor choice of words on my part. I meant that the Subversion client would need
to track all possible answers and try them in order (after suitable timeouts if
necessary). It is a much more complicated process than simply requesting an
address from a name and trying the connection.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Implement SRV DNS
Posted by Pierre THIERRY <pi...@moine-fou.org>.
> > > there's already some SRV code in the GNOME CVS.
> For what?
This is part of Zeroconf integration, if I understood correctly:
http://lists.gnome.org/archives/desktop-devel-list/2004-March/msg00458.html
> SRV's primary usefulness is replicating a service among multiple
> servers.
It's only one of the main goals of SRV records.
> You can replicate an SVN server for read-only access, but it's kind of
> hackish and I doubt many people do it.
You can at least use hooks to re-commit everything you do in a
repository in another one. Then, if the first SVN fall down, the second
can be used as fallback. When the master is up again, it just has to
refuse connections as long as it is not synced back.
<disclaimer>
I don't want to start a flaming discussion about replication. Let's say
it remains a possible use of SRV RR with SVN.
</disclaimer>
> SRV is also useful for redirecting a service to a different domain (in
> the same way that MX allows you to have mail service and web service
> at the same domain without running an SMTP and HTTP server on the same
> machine), but that's kind of a marginal justification; people just
> aren't going to mind advertising svn://svn.foo.bar/ instead of
> svn://foo.bar/ for version control access.
But this feature of SRV has one another very interesting use: you don't
have to know where lives the SVN server (host AND port), and the
administrator can arbitrarily move it without telling anyone he's doing
this. If he modifies the SRV records, everyone will contact the new
server when it's moved...
It also provide a mean to host many SVN server, at different ports.So
svn://foo.bar/ can lead to dedicatedhost.bigcompany.com:12345, and
svn://bigcompany.com/ to dedicatedhost.bigcompany.com:3690...
So SRV records DO provide interesting features for Subversion, IMHO.
Quickly,
le Moine Fou
--
pierre.thierry@moine-fou.org
OpenPGP 0xD9D50D8A
Re: Implement SRV DNS
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-04-21 at 12:05, John Peacock wrote:
> That text I quoted points to a specific problematic implementation; the current
> RFC2782 (Feb 2000) _prohibits compression_ of SRV records, RFC2052 (Oct 1996)
> _mandated_ it, and some servers following that earlier specification are still
> in use.
This is not a practical issue.
The history of this situation is: during part of the 1990s, a number of
new record types were specified as containing possibly-compressed domain
names, which isn't compatible with old resolvers. RP, AFSDB, RT, SIG,
PX, NXT, NAPTR, and SRV were affected by this error. AXFR
implementations also tended to blow out when they saw unrecognized RR
types.
In the past few years, more attention has been paid to this problem, and
new record types are barred from compressing domain names. When SRV was
respecified, it reflected the new discipline. Because there exist
implementations of the old experimental SRV specification, RFC 3597
recommends that resolvers know how to uncompress domain names in SRV
records. And they all do.
> > And about the widelyness, I know Windows 2000 uses SRV records
> > everytime it can...
>
> OK, that's one then (and yes I was already aware of it). I also happen to
> believe that M$loth's implementation of DNS records in this instance is an abuse
> of the core protocol.
Both of these statements confuse me. What does it mean to use SRV
records "every time you can?" And why is this an abuse of "the core
protocol?"
> > The SRV implementation is also in the TODO list of
> > projects like KDE and Mozilla, and there's already some SRV code in the
> > GNOME CVS.
For what?
> And that's zero more. There are plans, there are TODO entries, but there aren't
> other large projects which support it today (some 8 years after the RFC was
> ratified). It was a good idea which failed the test of actual usage in the wild.
There are several problems here, beyond your folding of Pierre's
comments into "plans [and] TODO entries" when there appears to also be
mainline code.
First, RFC 2052 is experimental; that is not a "ratification". RFC 2782
(four years old) is a Proposed Standard, which is more or less a
ratification.
Second, independent of the time frame, your usage expectations are
overblown. The point of SRV is to allow protocols to have an MX-like
record without a new type code for each protocol. The intent is not to
have implementations of existing protocols (like HTTP) suddenly start
using SRV, unless the protocol community wants to specify that.
A handful of protocols use SRV records. None of them are going to look
impressive because no new protocols have developed a great deal of
mindshare ever since firewalls became de rigeur. SIP and Kerberos are
the best examples I know of.
> In addition, the Subversion client would be required to link to a resolver
> library to make use of this feature. Right now, the client merely requests the
> IP address associated with a name, then opens a connection to the requested port
> on that address. Implementing SRV would require yet another platform
> independent library to resolve the chain of SRV records.
SRV records don't form a chain.
I'm also a bit skeptical that SRV support could be implemented in a
manner acceptable to us, but I wouldn't totally rule it out.
I'm also skeptical that many people would find SRV support useful at
this time. SRV's primary usefulness is replicating a service among
multiple servers. You can replicate an SVN server for read-only access,
but it's kind of hackish and I doubt many people do it. SRV is also
useful for redirecting a service to a different domain (in the same way
that MX allows you to have mail service and web service at the same
domain without running an SMTP and HTTP server on the same machine), but
that's kind of a marginal justification; people just aren't going to
mind advertising svn://svn.foo.bar/ instead of svn://foo.bar/ for
version control access.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Implement SRV DNS
Posted by John Peacock <jp...@rowman.com>.
Pierre THIERRY wrote:
> Where did you see that? I never heard about problematic implementations
> of SRV.
That text I quoted points to a specific problematic implementation; the current
RFC2782 (Feb 2000) _prohibits compression_ of SRV records, RFC2052 (Oct 1996)
_mandated_ it, and some servers following that earlier specification are still
in use.
> And about the widelyness, I know Windows 2000 uses SRV records
> everytime it can...
OK, that's one then (and yes I was already aware of it). I also happen to
believe that M$loth's implementation of DNS records in this instance is an abuse
of the core protocol.
> The SRV implementation is also in the TODO list of
> projects like KDE and Mozilla, and there's already some SRV code in the
> GNOME CVS.
And that's zero more. There are plans, there are TODO entries, but there aren't
other large projects which support it today (some 8 years after the RFC was
ratified). It was a good idea which failed the test of actual usage in the wild.
For example, it would be ideal for a web client to support it, so that web
servers could be easily and automatically load balanced. That is not possible
now since there are /no/ browsers which support it, and I don't think that it
will be implemented anytime soon. It's not the way that the industry has moved
in any case (rather they have used distributed caching, ala Akamai).
> I don't see why /one/ implementation, limited because designed to be
> very simple, should prevent anyone to use SRV records...
My concerns don't merely come from my use of DJBDNS (which does support SRV
records if so required). They arise from my perception that this is not a
widely utilized feature (similar to LOC records).
In addition, the Subversion client would be required to link to a resolver
library to make use of this feature. Right now, the client merely requests the
IP address associated with a name, then opens a connection to the requested port
on that address. Implementing SRV would require yet another platform
independent library to resolve the chain of SRV records.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Implement SRV DNS
Posted by Pierre THIERRY <pi...@moine-fou.org>.
> It's also not widely supported (at least not in a consistent fashion).
Where did you see that? I never heard about problematic implementations
of SRV. And about the widelyness, I know Windows 2000 uses SRV records
everytime it can... The SRV implementation is also in the TODO list of
projects like KDE and Mozilla, and there's already some SRV code in the
GNOME CVS.
> I also read the libsrv page, specifically the Limitations section; I'm
> not impressed that SRV is ever going to be widely supported
I don't see why /one/ implementation, limited because designed to be
very simple, should prevent anyone to use SRV records...
And the only real limitation of libsrv is when you use it for a server.
As a client library, it seems to me it would be perfect for SVN.
Server-side, you don't need an SRV library. Just take the ports to
listen to in the server's configuration.
And if you still don't want to hear anything about libsrv, feel free to
use another library, or write your own piece of code dealing with SRV
records.
Quickly,
le Moine Fou
PS: please don't CC me, I'm a subscriber of the list, and don't want the
mails N times...
--
pierre.thierry@moine-fou.org
OpenPGP 0xD9D50D8A
Re: Implement SRV DNS
Posted by John Peacock <jp...@rowman.com>.
Pierre THIERRY wrote:
> The SRV RR is really a very interesting feature of the DNS, as it allows
> great flexibility, and even load-balancing. There is also a library to deal
> with it, libsrv <http://libsrv.sourceforge.net/>.
It's also not widely supported (at least not in a consistent fashion). I found
this comment at
http://cr.yp.to/djbdns/notes.html
> (BIND versions 4.9.* through 8.1.2 compress names in new record types, such
> as RP and SRV, in blatant violation of RFC 1035. The names are not
> decompressed by caches that do not know about the new types. This is an
> interoperability disaster.)
I also read the libsrv page, specifically the Limitations section; I'm not
impressed that SRV is ever going to be widely supported, no matter how much the
author of srvlib wants it to be...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org