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: Greg Hudson <[email-masked]>
Date: Sat, 06 Mar 2004 10:31:55 -0500

On Sat, 2004-03-06 at 09:03, Barry Desborough wrote:
>         (inclusive)

> Random number case 0 1 2 3

You appear to be computing a random integer, rather than a random real
number, as was intended.  If you choose a random real number, you'll get
the appropriate distribution (a server with weight 2 is chosen twice as
often with a server of weight 1).

I would have much preferred a statement which used random integers
(which is something you can actually do on a computer), but the working
group was having a little trouble coming up with an algorithm statement
that actually worked, so we decided to go with one which we strongly
believed was correct even if it wasn't very clear and which didn't
translate easily into code.

It's particularly galling to me that we didn't even state explicitly
what kind of number is to be chosen (integer, rational, computable,
real, complex...), and then we threw in this parenthetical note
"(inclusive)" which actually has no effect on the outcome if real
numbers are being chosen.

> are selected with equal frequency. 

Neither of these choices seems appropriate.  The TTL only applies to the
DNS data itself, not the processing of it, so it would be wrong to
choose a server once and then stick with it until the TTL expires.  It
would also be wrong to walk the list of choices when making multiple
successful contacts; the idea is to walk the list when making a single
contact until you are successful, then throw the list away.  The next
time you make a contact, you should start all over again and choose a
new contact order randomly according to the weights.

---

From: Andras Salamon <[email-masked]>
Date: Sat, 6 Mar 2004 19:08:47 +0200

>         NAME TYPE CLASS TTL RDLENGTH RDATA

RFC1035 deals with the on-the-wire encoding, while the SRV text
above seems to be related to the usual BIND-style zone file format.
The examples in RFC 2782 bear this out.  However, re-reading RFC 2782
and RFC 2052, I could not determine a definitive on-the-wire encoding
of SRV records -- this seems to be undefined.  Presumably, implementors
have just looked at how BIND returns SRV records and gone with that.

> (not specified in 2782),

The section "Usage rules" mentions QTYPE=SRV, and there is further text
    the SRV RR, whose DNS type code is 33
and
    The IANA has assigned RR type value 33 to the SRV RR
which seems to tie SRV to TYPE, although perhaps not very directly.

> directly to me to throw more light on the message format?

I tried to find an online deployment of SRV records to feed to tcpdump,
but the closest I came was an SOA record for _tcp.microsoft.com (one of
the authors of RFC 2782 was at Microsoft).  Neither vix.com or troll.no
appear to have _tcp subdomains.  Does anyone actually have a deployment
of SRV outside pseudo-DNS dynamic zones tied to DHCP servers?

I also tried to find the IANA assignments for the Service tags, as
referred to in RFC 2782, and couldn't locate any.  Have any actually
been standardized?  If so, a pointer would be appreciated!

-- Andras Salamon                   [email-masked]
-- DNS Resources Directory          http://www.dns.net/dnsrd/

---

From: Greg Hudson <[email-masked]>
Date: Sat, 06 Mar 2004 12:29:42 -0500

> of SRV outside pseudo-DNS dynamic zones tied to DHCP servers?

We appear to have:

_sip._tcp.mit.edu
_sip._udp.mit.edu
_sip._tcp.sipxchange.mit.edu
_sip._udp.sipxchange.mit.edu
_kerberos._udp.athena.mit.edu
_kerberos-master._udp.athena.mit.edu
_kerberos-adm._tcp.athena.mit.edu

---

From: Paul Vixie <[email-masked]>
Date: Sat, 06 Mar 2004 18:37:28 +0000

> ...

both.  rdlength is a protocol element describing rdata.  the <rdlength,rdata>
tuple is used to represent the rr data, which in this case is itself a tuple:
<Priority,Weight,Port,Target>.  in "dns master file" format as entered into
zone files and as displayed by utilities such as "dig", rdlength is used to
encode and decode the rr data but is never specified or displayed directly.

> and the Target field be dispensed with?

because the names of the servers capable of responding to requests may not
have names equal or similar to the name of the service.  this is analagous
to MX records, where the target name can be a service provider even though
the query name is that of a customer.

> ...

it seems reasonable to me, but i didn't write that part of the rfc and i'm
not sure i ever understood it.  greg hudson's answer was that the numbers
had to be real not integer, and this may indeed be the case.

> to different targets.

no, actually we contemplated a web-like service where an object and all of
the sub-objects (such as images) mentioned in that object should ideally be
fetched from the same server, in case that server was capable of opportunistic
pipelining or prefetching.

> 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.
> 

we contemplated making "sticky-ness" or "re-use" a protocol element but we
felt that the SRV algorythm was already beyond its complexity horizon.  the
right thing to do now is: remove that part of the spec and designate re-use
as "requestor-specific local policy".

> 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!)

;; QUESTION SECTION:
;_kerberos._udp.vix.com.                IN      SRV

;; ANSWER SECTION:
_kerberos._udp.vix.com. 3600    IN      SRV     0 1 88 kerberos-0.vix.com.
_kerberos._udp.vix.com. 3600    IN      SRV     1 0 88 kerberos-1.vix.com.
_kerberos._udp.vix.com. 3600    IN      SRV     1 0 88 kerberos-2.vix.com.

;; AUTHORITY SECTION:
vix.com.                3178    IN      NS      ns.lah1.vix.com.
vix.com.                3178    IN      NS      ns.sql1.vix.com.
vix.com.                3178    IN      NS      ns-ext.isc.org.

;; ADDITIONAL SECTION:
ns.lah1.vix.com.        2429    IN      A       204.152.188.234
ns.lah1.vix.com.        2429    IN      AAAA    2001:4f8:2::9
ns.sql1.vix.com.        2429    IN      A       204.152.184.135
ns.sql1.vix.com.        2429    IN      AAAA    2001:4f8:3::9
ns-ext.isc.org.         3055    IN      A       204.152.184.64
ns-ext.isc.org.         3057    IN      AAAA    2001:4f8:0:2::13

---

From: Paul Vixie <[email-masked]>
Date: Sat, 06 Mar 2004 18:48:11 +0000

> have just looked at how BIND returns SRV records and gone with that.

note that if BIND is shown to be wrong, we (isc) will of course fix it.

> of SRV outside pseudo-DNS dynamic zones tied to DHCP servers?

vix.com has no SRV-discovered services that use tcp as their transport.
(presumably if we were a macintosh shop or a windows shop, we would?)

_kerberos._udp.vix.com/IN/SRV has some data for you, though.

> been standardized?  If so, a pointer would be appreciated!

here's the problem.  SRV is experimental.  2052 was "snuck through" the
ietf process when iesg's attention was focused elsewhere, and they got
Really Angry about it when they found out.  i've apologized, since mostly
i was acting in ignorance and without malice, but it hasn't helped.  so,
in spite of the significant deployment of SRV in the community (like with
the service discovery protocols currently shipped by microsoft and apple),
SRV remains experimental.

and as long as it's only experimental, iana's charter does not cover it.

what we need to do is in two stages.  first, iesg has to tell me how i can
mend relations and achieve some kind of pardon for past SRV-related misdeeds.
(perhaps a public apologia at an iesg plenary would suffice?)  second, iana
should create a registry of service identifiers, by importing the BSD file
"/etc/services" and then periodically amending it for new standards -- and
new standards should allocate a service name not just a default port number.

i don't know how to do either of those things but that's the list, anyway.

---

From: Jarle Greipsland <[email-masked]>
Date: Sat, 06 Mar 2004 20:01:52 +0100 (CET)

Andras Salamon <[email-masked]> writes:
> I tried to find an online deployment of SRV records to feed to
> tcpdump, but the closest I came was an SOA record for
> _tcp.microsoft.com (one of the authors of RFC 2782 was at
> Microsoft).  Neither vix.com or troll.no appear to have _tcp
> subdomains.  Does anyone actually have a deployment of SRV
> outside pseudo-DNS dynamic zones tied to DHCP servers?

_nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV

					-jarle

---

From: Greg Hudson <[email-masked]>
Date: Sat, 06 Mar 2004 14:08:35 -0500

On Sat, 2004-03-06 at 13:48, Paul Vixie wrote:
> Really Angry about it when they found out.

Your history seems to be omitting the part where we got RFC 2782
published as a proposed standard (with you as one of the authors).  That
one certainly wasn't snuck through the IESG; we got significant feedback
about the static weighting system, among other things.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 06 Mar 2004 19:49:01 +0000

> about the static weighting system, among other things.

indeed.  i was thinking only of 2052 in my recounting.  in that case there's
nothing stopping someone from writing an rfc to immortalize /etc/services and
making that file an iana database.

---

From: David Shaw <[email-masked]>
Date: Sat, 6 Mar 2004 15:13:42 -0500

On Sat, Mar 06, 2004 at 07:08:47PM +0200, Andras Salamon wrote:

> subdomains.  Does anyone actually have a deployment of SRV outside
> pseudo-DNS dynamic zones tied to DHCP servers?

_hkp._tcp.pgp.net to help find PGP keyservers.

David

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Mar 2004 10:11:02 +0100

On Sat, Mar 06, 2004 at 08:01:52PM +0100,
 Jarle Greipsland <[email-masked]> wrote 

> _nicname._tcp.{at,de,dk,fr,is,lu,nl,no,si,uk}/IN/SRV

Which is documented in:

http://mailbox.univie.ac.at/~gw/draft-sanz-whois-srv-00.txt

---

From: "Barry Desborough" <[email-masked]>
Date: Mon, 8 Mar 2004 11:10:08 +0100

Thanks for your help, Greg.

There's a note below about selection using random integers.

----- Original Message ----- 
From: "Greg Hudson" <[email-masked]>
To: "Barry Desborough" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, 06 March, 2004 16:31 PM
Subject: Re: DNS SRV Clarification sought

> translate easily into code.

Demonstration of selection using random integers.
(Hope the fixed font is preserved and there's no line folding)

Item      Cumulative
(weight)  sum
----      ----- 
a         a
b         a+b
c         a+b+c
.         .
.         .
n         a+b+c+...+n  i.e.(sum(a...n))

Choosing a random integer between 1 and sum(a...n) inclusive and selecting
the first item greater than or equal to the random integer, we have -

Random integer range      1...a        a+1...a+b        a+b+1...a+b+c
Random integer frequency  a            (a+b)-(a+1)+1=b  (a+b+c)-(a+b+1)+1=c
Probability               a/sum(a...n) b/sum(a...n)     c/sum(a...n)

For any item say, i, h being the previous item,

Random integer range      sum(a...h)+1...sum(a...i)
Random integer frequency  sum(a...i)-(sum(a...h)+1)+1=i
Probability               i/sum(a...n)

Barry Desborough

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 08 Mar 2004 10:08:33 -0600

On 3/6/2004 12:48 PM, Paul Vixie wrote:

> iana should create a registry of service identifiers, by importing the
> BSD file "/etc/services" and then periodically amending it for new
> standards

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: Peter Koch <[email-masked]>
Date: Mon, 08 Mar 2004 17:25:32 +0100

> > BSD file "/etc/services" and then periodically amending it for new

which would be different from <http://www.iana.org/assignments/port-numbers>?

> Is that really feasible? Service definitions may require weighting values

What weighting values are you talking about? Those in the SRV RR are not
supposed to carry any additional meaning.

RFC 2782 is pretty clear about the service names to be used:

Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. [...]

   Service
        The symbolic name of the desired service, as defined in Assigned
        Numbers [STD 2] or locally.  An underscore (_) is prepended to
        the service identifier to avoid collisions with DNS labels that
        occur in nature.

STD 2 is obsoleted by RFC 3232, again pointing to the URL above (although
rather indirectly). What may be missing is a list of services without
portnumber. In the whois case mentioned earlier inthis thread (which, btw
uses "nicname" instead of the more prominent "whois" because of the "Service"
requirement cited above) one would sometimes like to further differentiate
the service without really using a different protocol, e.g. _ripe_whois.tcp...

-Peter

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 08 Mar 2004 12:03:05 -0600

> What weighting values are you talking about? Those in the SRV RR are
> not supposed to carry any additional meaning.

The 'priority' field is different from the 'weight' field. RFC2782 says
the following about the weight:

|       In the absence of a protocol whose specification calls for the
|       use of other weighting information, a client arranges the SRV
|       RRs of the same Priority in the order in which target hosts,
|       specified by the SRV RRs, will be contacted.

> RFC 2782 is pretty clear about the service names to be used:

Well, that's not the whole ball of wax. Service names can vary for reasosn
other than protocol (http != www). Service names are relative labels which
do not describe behavioral rules which may be associated with the service
in general (algorithm may require SRV for in-addr space, or domain-wide
space, or host-specific maps). Etc.

Really, it seems to me that it's best to leave the list of well-known
definitions for those SRV mappings and algorithms which are actually
defined by the affected community.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 9 Mar 2004 09:13:19 +0100

On Sat, 06 Mar 2004 12:29:42 -0500

> _sip._udp.sipxchange.mit.edu

Where the use of SRV for SIP is documented in RFC3263

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC