[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Implement SRV DNS

From: John Peacock <jpeacock_at_rowman.com>
Date: 2004-04-21 19:55:07 CEST

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 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
Received on Wed Apr 21 19:55:09 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.