Subject: Re: DNS SRV Clarification sought

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

> 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
> ...
> Q1) Which rfc is correct?

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.

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

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.

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

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.

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

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.
> 
> Q4) Can anyone clarify this matter?

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

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

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

--
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: Paul Vixie <[email-masked]>
Date: Sat, 06 Mar 2004 18:37:28 +0000

;; QUESTION SECTION:

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION: