Subject: DNS SRV Clarification sought

From: "Barry Desborough" <[email-masked]>
Date: Sat, 6 Mar 2004 15:03:22 +0100

Hello, being new to rfc2782, I have a number of questions.
I would be grateful for any enlightenment anyone could provide.

Regards

Barry Desborough
[email-masked]

SRV RR FORMAT

>From rfc2782 page 2

"The format of the SRV RR

   Here is the format of the SRV RR, whose DNS type code is 33:

        _Service._Proto.Name TTL Class SRV Priority Weight Port Target"

But rfc1035 page 29 describes the generic RR header as being

        NAME TYPE CLASS TTL RDLENGTH RDATA

According to 1035, and assuming that 'SRV' refers to TYPE,
(not specified in 2782), it seems that the SRV RR should be

        _Service._Proto.Name SRV Class TTL RDLENGTH 
            Priority Weight Port Target

where   _Service._Proto.Name corresponds to NAME
        SRV is the TYPE (33)
        Class, TTL and RDLENGTH are 1035 standard
        and Priority Weight, Port and Target correspond to RDATA

Q1) Which rfc is correct?

Q2) Why is _Service._Proto.Name repeated in the query _and_ in the SRV RR?
Could not the contents of Target have been be reported in the NAME field 
and the Target field be dispensed with?

TARGET SELECTION

>From page 3 of rfc2782

"        ............................................ The following
        algorithm SHOULD be used to order the SRV RRs of the same
        priority:

        To select a target to be contacted next, arrange all SRV RRs
        (that have not been ordered yet) in any order, except that all
        those with weight 0 are placed at the beginning of the list.

        Compute the sum of the weights of those RRs, and with each RR
        associate the running sum in the selected order. Then choose a
        uniform random number between 0 and the sum computed
        (inclusive), and select the RR whose running sum value is the
        first in the selected order which is greater than or equal to
        the random number selected. The target host specified in the
        selected SRV RR is the next one to be contacted by the client.
        Remove this SRV RR from the set of the unordered SRV RRs and
        apply the described algorithm to the unordered SRV RRs to select
        the next target host.  Continue the ordering process until there
        are no unordered SRV RRs.  This process is repeated for each
        Priority."

Let's say we have only two targets of the same priority, with
weights 1 and 2.

If the weights are ordered 1 then 2, then we have

Wt  Sum
-----------
1    1
2    3

Outcomes are as follows

Random number case 0 1 2 3
1st contact                 1 1 2 2
2nd contact                2 2 1 1

This gives each target equal probability of being contacted first.

If the weights are ordered 2 then 1, then we have

Wt  Sum
-----------
2    2
1    3

Outcomes are as follows

Random number case 0 1 2 3
1st contact                 2 2 2 1
2nd contact                1 1 1 2

The weight 2 target is contacted first with a probability of 3/4.

Overall the probabilities for 1st contact are 3/8 and
5/8 for target weights 1 and 2 respectively, _assuming_the_initial_
_order_is_randomly_chosen_, but this is not specified.

According to my reckoning, consistent, correct results are 
obtained if the random number is chosen to be between 
_ONE_ and the sum computed.

Q3) Does anyone agree or disagree with this?

If what is meant by 1st contact is the 1st successful attempt to 
find a Target, from whereupon this target's service is always used 
until it's TTL expiry or failure, then load sharing is only effected
by different clients choosing different 1st contacts.

On the other hand, if it means that a client which is a frequent, 
heavy user of a service client works down a sequence of targets 
to select which one provides the service next, all targets 
are selected with equal frequency. 

It seems to me that there is an assumption here that target contact
selection from any particular client is very infrequent, and that 
load sharing occurs by virtue of different clients making 1st contact
to different targets. In a system who's application makes frequent
heavy of a service, service selection should be purely probabilistic
based on the relative weights of the highest priority records 
available.

Q4) Can anyone clarify this matter?

Q5) Does anyone have any DNS SRV sniffer trace they could send
directly to me to throw more light on the message format?
(Please mail the group to say you have responded to this one, to save
me being flooded!)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: <[email-masked]>
Date: Tue, 9 Mar 2004 03:47:36 +0900

>> > iana should create a registry of service identifiers, by importing the
>> > BSD file "/etc/services" and then periodically amending it for new
>> > standards
>
>which would be different from
><http://www.iana.org/assignments/port-numbers>?

Actually, I always thought that RFC 2782's [STD 2] reference
was to the "PROTOCOL AND SERVICE NAMES" section, aka
<http://www.iana.org/assignments/service-names>, and people who looked
for the names in port-numbers were confused by the lack of strong binding
to the reference (since there's no strong requirement for a port number
assignment, just a name).

  Bill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 8 Mar 2004 13:17:05 -0800

Registies are over-rated.

Look at the number of programs there are on windows that have their own file
format. Important name collisions are pretty rare considering that it is
essentially a 3 character identifier.

All that matters here is that the identifier be unique and plentiful enough
that they do not run out.

If you try to impose any requirement that is more stringent than first come
first served we end up back with the X-Header problem.

We could adopt the hash-cash scheme that Microsoft is pushing for anti-spam
as a way of rationing code points in tables.

All code points are first come first served. To get the code point 'SPAM' in
table 'SRV' you have to provide a string s such that

	 SHA1(s) - SHA1('SPAM+SRV')  <> 0  AND
	 |SHA1(s) - SHA1('SPAM+SRV')| < 2^(160-n)

I.e. the strings must not be the same and the first n bits must match.

The value of n would increase as the code points in the registry were
exhausted.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Eric A. Hall
> Sent: Monday, March 08, 2004 11:09 AM
> To: Paul Vixie
> Cc: [email-masked]
> Subject: Re: DNS SRV Clarification sought
> 
> 
> 
> On 3/6/2004 12:48 PM, Paul Vixie wrote:
> 
> Is that really feasible? Service definitions may require 
> weighting values
> and client-selection algorithms to be useful, all of which 
> requires some
> level of agreement among implementors.
> 
> If we start with a list of defaults and then update the list 
> on-the-fly,
> how does the client know which version of the list entry is in use for
> those SRV RRs that they encounter?
> 
> The nice thing about the current model is that an entry in the list
> connotes agreement among implementors, or at least carries a footnote.
> 
> -- 
> Eric A. Hall                                        
> http://www.ehsco.com/
> Internet Core Protocols          
> http://www.oreilly.com/catalog/coreprot/
> 
> --

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 15 Mar 2004 12:42:37 -0800

however, a purely SRV-discovered service might not 
> _have_ a default
> port number, in which case 
> ftp://ftp.iana.org/assignments/service-names would
> be the better choice for an SRV's owner name.  

It seems to me that a good long term objective here would
be to stop issuing port numbers completely.

The logical extension of SRV is that you look up
the service in DNS and get back a report of the name
of the server that supports the service, the port address
to use plus any parameters that describe the use of the
port (I support SSL security with profile X).

This is where the Internet will be in a few years time.

		Phill