Re: SRV RRs support in Internet Explorer?
From: William Stacey [MVP] (staceywREMOVE_at_mvps.org)
Date: 03/07/04
- Next message: Adam Marx: "Re: Multihomed DNS server install problems"
- Previous message: Ace Fekay [MVP]: "Re: Multihomed DNS server install problems"
- In reply to: Rémi Després: "Re: SRV RRs support in Internet Explorer?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 7 Mar 2004 17:25:51 -0500
Ok. Have a great trip!
--
William Stacey, MVP
"Rémi Després" <remi.despres@wanadoo.fr> wrote in message
news:Oe02hT4AEHA.2352@TK2MSFTNGP12.phx.gbl...
> 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).
> > > ...
> > > ****
> > >
> > >
> > >
> >
> >
>
>
- Next message: Adam Marx: "Re: Multihomed DNS server install problems"
- Previous message: Ace Fekay [MVP]: "Re: Multihomed DNS server install problems"
- In reply to: Rémi Després: "Re: SRV RRs support in Internet Explorer?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
