SRV RRs support in Internet Explorer?

  • Thread starter Thread starter Rémi Després
  • Start date Start date
R

Rémi Després

Hi,

Does someone know if, using Internet Explorer, advantage can be taken of
DNS SRV records (for load sharing and/or for backup when several server
hosts are available for a same resource).

If yes, how?

Thanks,

RD
 
Not really. IE uses GetHostByName(), which returns A records and aliases at
this point.
 
Thanks.

Two interests:

1. The first one, general in scope, is being able to define a backup site,
and/or mirror sites with load sharing, for a particular resource.
For this, using the (clean) DNS-SRV mechanism, seems an obvious idea.
It would logically involve just a simple extension of IE whereby if it
receives a "nonexistent domain" error code in an answer to an A or AAAA
request for domain name xxx.yyy, then it would try the standard SRV request
for such a resource, i.e. _HTTP._TCP.xxx.yyy.
(It would then receive a list of <domain name, TCP port> couples, with
possibly unequal priorities, and within each priority possible unequal
weights for load sharing. Then it would make the choice of one couple, get
from the DNS the IP address of the given domain name, and send the HTTP
request to that IP address, on the given TCP port. In the absence af an
answer it would then try a next choice of <domain name, TCP port> , and so
on and so forth if necessary.)

This looks like an easy and unbeatable way to reach the stated objective.

Unless I miss something, Microsoft should do it asap if it is not done (a
small, standard conformant, upward compatible extension offering great
return!).

Have you personnally any chance to pass the message to an appropriate
destination?

2. The second objective, more specific, and for a project of my own,
involves using the DNS-SRV capability of dynamically indicating which TCP
port has to be used on which host.
The project, confidential at this stage, concerns an innovative approach to
ease deployment of IPv6 addresses.

Regards,


Rémi Després
 
1. The first one, general in scope, is being able to define a backup site,
and/or mirror sites with load sharing, for a particular resource.
For this, using the (clean) DNS-SRV mechanism, seems an obvious idea.
It would logically involve just a simple extension of IE whereby if it
receives a "nonexistent domain" error code in an answer to an A or AAAA
request for domain name xxx.yyy, then it would try the standard SRV request
for such a resource, i.e. _HTTP._TCP.xxx.yyy.
Click to expand...

I see what your saying. However, you can do much of that today. If you
have 4 A records for the host name, then IE will try the first, second, etc.
The srv record approach does not really help here, cause in either case, you
still need to fall down to next host, which IE does today. Also, in the
case of http, dynamic ports would probably cause more issues then it fixes.
Port 80 is standard for general access. I can't think of a good reason to
change that or allow dynamic port changes. If you have 20 web servers, they
just listen on 80 - simple. I would not use srv records to get around
needing host headers either. Ports are valuable, I would not use them as an
alternative to host headers. I don't get the "nonexistent domain" reason.
If the name does not exist, then it was not setup for a reason and you don't
want another "solution" that somehow "finds" names that don't exist for a
reason. If I miss what your saying, please correct me as this is an
interesting idea. I just don't see the exact value from the text at this
point. The load balancing, IMO, is the real winner. DNS load balancing is
lacking. You can do round robin to get cheap LB, but we all know the issues
with that. That said, if you require real LB, you implement a LB
gateway/host that does that and/or use a LB dns like akadns does. I don't
see how srv records help here.
2. The second objective, more specific, and for a project of my own,
involves using the DNS-SRV capability of dynamically indicating which TCP
port has to be used on which host.
Click to expand...

Any client app can use SRV records if they need or want. You get to decide
how and why to use them.

Please post back. Cheers.
 
Thanks for your interest in the subject, which I believe is worth it.


1. The two issues of Backup and Load Balancing on one hand, innovative use
of dynamic ports on the other hand must IMO be kept completely separate.
The second subject may never come up and should better be ignored for the
time being (it only happens to be the reason why I started studying details
of the DNS).

2. On the contrary, the two isues of backup and LB "must be considered
together".
If the browser always picks up the first A record first, backup is achieved
but not LB (A is generic here, to be understood as A or AAAA or A6)
Even this can be defeated if the Name Server itself cycles through different
orders of the A RRs of a domain name (some BIND servers may do it, it seems,
precisely to achieve LB independently of browser behaviors).
If conversely the browser cycles through received A RRs, LB is achieved
(only with equal weights); backup becomes impossible, whatever the NS does.
In other words, with only A RRs, neither backup nor LB, event in its round
robin variant, can be safely achieved.

3. Using a gateway host do do LB, an approach of which I don't know all
consequences, doesn't seem to be the simple and clean solution that Internet
needs (and is it IETF approved, as SRV RRs are?)

4. Using the nonexistant domain (ND) response has been based based on the
following logic:
- The goal is to guarantee to Service Providers who want it e2e backup
and/or LB.
- At least initially, most servers will (quite legitimately) remain
reachable by means of A RRs.
- Browsers must therefore query for A RRs and exploit returned IP addresses
if present.
- Without a change in NS behavior the only answer without an IP adress to an
A query is an error report.
- Rcode 3 ("Name Error" in RFC 1035, aka Nonexistant Domain) should
guarantee a prompt answer by all NSs if no A RR exists for the queried
domain name. (It could be considered that rcode 3 really means Nonexisting
Domain "for this type of query".)
- Making always a SRV query after receiving an rcode 3 should not be
problem: in the absence of SRV record a new rcode 3 would be received, this
time to be user signalled; if a SRV record is present, e2e backup and LB are
achieved with existing standards and existing NSs (setting up the
appropriate records in NSs is sufficient, an significant breakthrough IMO).

5. Note: an improved efficiency of the process would be possible in the
future if NSs are permitted to answer directly with SRV records to A queries
when no A record is available. The above mechanism would still work, with no
harm, where needed (in old-fashioned NSs), while in general SRV responses
would be obtained immediately.


Rémi Després
 
Thanks for the reply. A lot of points there, so instead of addressing each
one, I will take a step back and generalize a bit. There are some
fundemental truths we can infer if we limit our thinking (at the moment) to
web access from a client to web server and, to keep things simple, also
assume ipv4 for this:
1) A client service (i.e. browser, etc.) needs to somehow resolve a name to
an IP address and port number. The port number could be implicit (i.e.
wellknown) or explicit.
2) At any point in time, a server (i.e. an IP/port endpoint ) could fail
and the client, if given multiple options, could select another endpoint in
the list.

So, before the client browser can connect to an endpoint, it needs to query
for some kind of dns RR that will return at least a single IP address and
possibly a port number. To LB, that endpoint could be a gateway that does
the LBing for many web servers "behind" it, or we need to return more then
one IP to client and let it somehow "pick" one to use via some rules for LB,
or the dns server must order the records based some LB rules. Regardless of
which IP address the client picks, that endpoint can fail at any point. So
the client also needs to walk the list to pick the next service endpoint to
try. So we have most of this already. Client can query for A record and
get back an A record list. SRV records would allow dynamic port bindings,
but not solve LB problem. In either case, we still need some help because
any server can fail, and we need to pick another one (if we have another
one) and try that one. IE implicitly tries port 80 first because that is
the wellknown port for http. smtp is 25, etc. You can override this at the
browser if you want 8080, for example. So dynamic ports, imo, does not
really help us in terms of LB or backup.

What can help us is TTL. If we don't keep the TTL low (i.e. 5-10 secs), we
can't effectively LB or backup because NSs cache the records for the TTL
time. This can "hide" any kind of LB or round-robin we try to do at the
name server as NS ns1 will return the list in the order it got the list or
may round-robin its' cached list until it needs to refresh. Not sure that
other NSs should change the order, as that presumes it "knows" what the
Owner of the domain name wanted - which would be wrong in most cases. So if
we wanted to do this ourselfs, how would we do it? We know yahoo.com and
google.com and microsoft.com do it somehow, but how? One solution is to
have a small LB applette on each web server that post Stat messages to a
dynamic DNS service on our DNS server(s) for the name. This applette
collects cpu usage, connections, memory, etc and posts the message to our
server service that changes the DNS records on our NSs based on load or any
rules it wants to use. The RRs would then have a small TTL. This assures
that client's and other NSs will not keep using the same records in the same
order and they Timeout. The dns server can remove failed servers and give
other records higher list order based on load. This can be done with A
records. I still don't see how SRV records would help backup or LB. You
would still need to do the above. It would, however, give you dynamic
ports, but still not sure of the value in that for wellknown services like
http, etc. Cheers.
 
I believe you are right in being unsatisfied by my proposal as it was.
It had a remaining dynamic port bias, which it shouldn't have had, and was
as a consequence incomplete concerning the Load Balancing & BackUp problem.

Yet SRV records have a great potential for the LB&BU problem.
They tell explicitely:
. which host names may normally be used
. how LB must be tuned up among them (for cases where servers have
different CPU powers and/or access link bandwidths)
. which hosts may be used for backup, and if used with which LB
frequencies.

Using just short TTLs one would still miss differentiation between normal
host that are intended forLB and BU one.
Differentiated LB frequencies would also be missed.

The significant step forward for LB&BU that I see for future versions of IE
and MS DNS Server could then be as follows:
- MSDNS when it responds with A RRs also provides all SRV records that
match the same query name (if any).
- IE exploits SRV records rather than A ones when it receives both.

Looking forward to what you think.

Rémi Després
 
Sorry for the delayed reply.
. how LB must be tuned up among them (for cases where servers have
different CPU powers and/or access link bandwidths)
Click to expand...

This can be done in either case. Some server process still needs to order
the records dynamically based on some logic we have that orders the records
based on load.
. which hosts may be used for backup, and if used with which LB
frequencies.
Click to expand...

I am not sure BU needs to be handled as a special case, all records/hosts
can potentially be BU hosts if the first record does not reply. We just
walk the list in order or walk the list in order of priority in the case or
srv records.
Using just short TTLs one would still miss differentiation between normal
host that are intended forLB and BU one.
Differentiated LB frequencies would also be missed.
Click to expand...

Not sure it matters. The goal is to find a server that is up. The current
priority is handled by record ordering. You still have to order the records
(either srv or a ) somehow. Lets look at how we might implement both
assuming no caching and direct queries to auth dns server (for simplisity):

Using A Records:
------------------
- Client makes A record query for www.mydomain.com.
- Server builds and sends reply from auth data. It dynamically orders the
records based on LB input from various hosts using some external process.
- Client gets list. Implicit order is first record is highest priority and
so on. Client tries first record and gets no reply. Client then tries
second record and so on until a connection is made.

Using SRV Records:
---------------------
- Client makes SRV record query for www.mydomain.com.
- Server builds and sends reply from auth data. Priority and Weight values
are dynamically set with another process that receives statistics
notifications from the hosts. Records are ordered based on Priority and
then Weight.
- Client gets list. Explicit order is defined by lowest Priority value and
if multiple records with same Priority, then use record with highest Weight.
The list is walked in this manner until a connection is made.

In both cases, you still need some server based logic that either orders A
records or changes the priority and weight values for given SRV RRs. In the
case of a downed host, we probably want to remove the record in both cases
and not just put it at the bottom of the list as not client could ever
connect to it anyway, so no need to list it. One is explicit, the other is
implicit based on order (I guess that could be explicit order also depending
on how you think about it.) In both cases, the client really just wants an
IP address to connect to. If that fails, it walks the list to get next one
in respective order. As far a LB goes, I still don't see the advantage to
srv records. You do have the notion of explicit priority and weight which
could remove any ambiguity and would not rely on intermediate dns servers
keeping the List in exact order in the case of A records in first example -
so I see some value there. Not sure it has enough marginal value to warrant
a change to all client resolvers - but ya never know. I guess the point is,
we can get the same effect using A records if that is what you are after.
 
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).
....
****
 
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!
 
Back
Top