My comments and answers point by point:

1- TXT records, being "not efficient" are not a basis for a practical
solution.

2- With SRV records, load balancing and backup configuration can be static
(no need for an update protocol). This is simple and sufficient for many
small configurations. The point is important in my view: Yahoo, Google etc.
have so many users that the law of large numbers applies to them; they can
use crude and slowly varying parameters to balance traffic on the basis of
what they measure. But more ordinary servers cannot.

3- Even when dynamic load balancing configuration is desired, solutions that
don't depend on frequent DNS queries are preferable because more scalable
than those that do.

4- Yes IP addresses are needed with SRV records, as always. As indicated in
point 1 of the proposed spec, they can be provided to DNS clients in A RRs
contained in the same response as the SRV records.

5- In my understanding, the proposal is not a "big change" to wellknown
services. It is only a "upward compatible extension" to them (and a fairly
simple one): no DNS client is obliged to look at SRV records; no group of
servers offering a common service is obliged to have SRV records in the DNS;
but if a service server group has SRV records in the DNS (and the
corresponing name to IP address A records), then all DNS clients that are
upgraded perform weighted load balancing and/or backup without needing a
high frequency of DNS updates.

6- What is the added value? Efficient load balancing offered to small server
groups, even if they have relatively limited traffic, and no need for DNS
clients
that make frequent service accesses to also make frequent DNS queries.
Besides, the new feature is based on existing record types, the scope of
which
is only extended in a natural way.
This fits with the need for simplicity of concepts and orthogonality of
functions.

7- Exemple of application.
- A web service is offered by two servers s1 and s2, with s1 twice as
powerful as s2.
- A third server s3 is to be used only if s1 and s2 are down (backup).
- The server name used to call the service is xxx (an FQDN).
- IP addresses of servers are a1, a2 and a3 respectively.
- The DNS server for xxx is supposed to be upgraded (i.e. sends SRV records
that match the same queried name a A records, and also the A records that
match the SRV provided targets).

DNS RRs to be set are set as follows:
xxx A IN a1
xxx A IN a2
xxx A IN a3
xxx SRV IN 0 2 80 xxx1 (priority 0, weight 2)
xxx SRV IN 0 1 80 xxx2 (priority 0, weight 1)
xxx SRV IN 1 1 80 xxx3 (priority 1, weight not
significant)
xxx1 A IN a1
xxx2 A IN a2
xxx3 A IN a3

(1) A non upgraded DNS client queries for xxx (it has a web request to serve
and it has in its cache no information about xxx with an unexpired TTL).
(2) It receives all the above RRs.
(3) It interprets only the first ones, the only ones it recognizes, and acts
as
though there would be no SRV records. Note that the three xxx A records
can be ordered according to whatever feature applies to them (the
new feature doesn't conflict with existing such a features. They continue to
apply for DNS clients that don't interpret SRV records in responses to their
A queries.

(4) An upgraded DNS client queries for xxx .
(5) It receives all the above RRs.
(6) It sees that there ares SRV records in the response.
It also sees that no additional DNS query is necessary for getting the IP
addresses of targets xxx1, xxx2 and xxx3 (their IP adresses are provided).
(7) Its successive accesses to the xx service are then preformed such that
a1 is used twice as frequently as a2, the first one being chosen randomly.
If for one access neither a1 nor a2 answers, an access to a3is attempted.
All accesses are performed on the indicated port 80 (the usual one).

Clearer?

Rémi Després


----- Original Message -----
From: "Rémi Després" <remi.despres@wanadoo.fr>
Newsgroups: microsoft.public.win2000.dns
Sent: Saturday, March 06, 2004 3:10 PM
Subject: Re: SRV RRs support in Internet Explorer?


> I will be absent for 18 days.
> Will annswer when returned.
>
> Rémi
>
> "William Stacey" <staceywREMOVE@mvps.org> a écrit dans le message de
> news:unRHtDwAEHA.2484@TK2MSFTNGP12.phx.gbl...
> > I am not saying (and hope have not implied) that you can not or should
not
> > use SRV for LB and/or backup. As you have said, it can be done, and
> > probably has been implemented by someone. My point is this: There is
> > nothing magical about SRV records. Although not effecient, you could
use
> > TXT records to do the same thing and stuff the right bytes in the RDATA.
> > SRV records provide a convienient message format for us, but other
records
> > could be used as well.
> >
> > Regardless of what record type you use, you still need some
process/logic
> > that updates the record(s) on the DNS server to reflect current state of
> the
> > records. So my questions and thoughts are pretty much still the same:
> > 1) You still need some process that updates A, SRV or other records to
> > reflect some explict or implicit order based on dynamic server loading
and
> > availability. This is not an optional step regardless of record type.
> >
> > 2) I agree that SRV records could help by giving us explicit priority
and
> > weight, but we still need IP addresses.
> >
> > 3) As we both agree this could be done, the question is; should it be
done
> > and could we get the same effect without changing every client out there
> to
> > get the same behavior? If you can do it with A records (as this is done
> > today, such as yahoo and google, etc) today, does SRV records provide
> > enouph increase in value to warrant such a big change for wellknown
> services
> > like web and ftp? At this point, I don't see it.
> >
> > 4) In your lb and backup example, what value do you get from SRV records
> > that you can't get with A records - assuming in both cases we have some
> > ordering process that changes the SRV or A records on the DNS server.
> >
> > 5) Maybe it would be helpfull to step through exactly what you are
> proposing
> > using steps (i.e. 1) Client makes query. 2) Server does x,y,z, etc.)
This
> > should help clarify exactly what you are thinking. Maybe I am missing
> > something.
> >
> > Cheers!
> >
> > --
> > William Stacey, MS MVP
> >
> > "Rémi Després" <remi.despres@wanadoo.fr> wrote in message
> > news:%23dF2TbpAEHA.212@TK2MSFTNGP12.phx.gbl...
> > > At this stage of the discussion the best is probably to formalize the
> > > proposal, as it evolved during our dialogue, and to see were we are.
> > >
> > > Rationale:
> > > ------------
> > > - It is assumed that the need for Static Load Distribution and/or
> Backup,
> > or
> > > SLD&BU, is reasonably typical. (SLD differs from dynamic load sharing
in
> > > that times between DNS parameter updates are generally much longer
than
> RR
> > > TTLs, and in that no real time protocol is needed between application
> > > servers and
> > > DNS servers.)
> > > - Within IETF, one tool is explicitly intended for SLD&BU, and is
> > > particularly clean and simple for that, namely SRV RRs (a relevant
> extract
> > > of RFC2052 is copied below). (SRV RRs were also designed for a
different
> > > purpose, namely facilitating new service deployments by suppressing
the
> > need
> > > for host updates when new application ports are assigned, an
interesting
> > > progress, but there is no need to be concerned with it in the use of
SRV
> > RRs
> > > for SLD&BU as specified below).
> > > - A natural question is therefore: can a design be found such that SRV
> RRs
> > > become a practical tool for SLD&BU, subject to the requirement that
> upward
> > > compatibility is ensured in both DNS Name Servers and DNS Clients, in
> > > particular in Web Browsers?
> > > - The answer appears to be YES with the APSDR proposal below ("A plus
> SRV
> > > DNS
> > > Responses"), where A is taken as generic, meaning also AAAA and A6.
> > >
> > > APSDR Specification
> > > --------------------------
> > > 1. To become APSDR compatible, a Name Server has, when it returns a
> > response
> > > with A type RRs, to include in the Additional Data section of the
> response
> > > the SRV records that, in its data base, match the same domain name, if
> > any.
> > > 2. To be APSDR compatible, a DNS Client (e.g. a Web Browser) has, when
> it
> > > receives SRV RRs in a response to one of its A queries, to memorize
the
> > > Priorities and Weights of hosts listed in SRV RRs, and to comply with
> > their
> > > SLD&BU implications (a simple piece of code).
> > >
> > > Upward compatibility of APSDR
> > > ---------------------------------------
> > > a. If a DNS Client which is APSDR compatible queries Name Server which
> is
> > > not, the Name server will return A records only. The DNS Client works
as
> > > before.
> > > b. If a DNS Client which is not APSDR compatible queries a Name Server
> > which
> > > is APSDR compatible, it will simply ignore SRV RRs, as it does for any
> > > unknown type RR. The DNS Client works as before.
> > > c. If both a DNS Client and a queried Name Server are APSDR
compatible,
> > and
> > > if there is no SRV RR concerning the queried Domain name in the data
> base
> > of
> > > the server, no SRV RR is returned. Both the Name Server and the DNS
> Client
> > > work as before.
> > > d. If both DNS Client and the queried Name Server are APSDR
compatible,
> > and
> > > if there are SRV RRs concerning the queried Domain name in the data
> base,
> > > SLD&BU will apply as specified by SRV RRs. (This is the raison d'etre
> of
> > > the APSDR compatible extension in DNS Clients and Name Servers).
> > >
> > > Now that things are much clearer, I believe it would be useful to
submit
> > the
> > > subject to a wider forum than just both of us.
> > > You may of course feel differently (it seems you are more interested
in
> > > schemes that involve Name Servers alone, and that therefore work with
> > > existing DNS Clients, but both approaches have their own application
> > scopes
> > > and can in my view usefully coexist).
> > >
> > > I look forward to your views?
> > >
> > >
> > > Rémi Després
> > >
> > >
> > > ****
> > > Extract from RFC 2052 - A DNS RR for specifying the location of
services
> > > (DNS SRV)
> > > ...
> > > The SRV RR allows administrators to use several servers for a single
> > > domain, to move services from host to host with little fuss, and to
> > > designate some hosts as primary servers for a service and others as
> > > backups.
> > > ...
> > > Priority
> > > As for MX, the priority of this target host. A client MUST
> > > attempt to contact the target host with the lowest-numbered
> > > priority it can reach; target hosts with the same priority
> > > SHOULD be tried in pseudorandom order. The range is 0-65535.
> > > ...
> > >
> > > Weight
> > > Load balancing mechanism. When selecting a target host among
> > > those that have the same priority, the chance of trying this
> > > one first SHOULD be proportional to its weight. The range of
> > > this number is 1-65535. Domain administrators are urged to use
> > > Weight 0 when there isn't any load balancing to do, to make the
> > > RR easier to read for humans (less noisy).
> > > ...
> > > ****
> > >
> > >
> > >
> >
> >
>
>