Subject: [dnsext] Use of DNS SRV records for host selection

From: "Greg Daley" <[email-masked]>
Date: Mon, 11 Jan 2010 12:01:07 +1100

A new draft has been submitted which attempts to provide the 
priority and load balancing control of SRV (and MX) records to
host lookups, without explicit service specification.

This is an early phase experimental mechanism based on SRV RR,
with modified client semantics. Details are listed below:

Authors:

  Greg Daley 
  Raymond Ng

Title:   
   Use of DNS SRV records for host selection

URL:
   http://tools.ietf.org/html/draft-daley-dnsext-host-srv-00

Abstract:

   Where multiple application servers are able to receive inbound
   connections from clients, it is desirable provide some policy control
   over client behaviour.  This specification allows application service
   providers to provide addresses of multiple servers in response to DNS
   queries, while specifying failover and load balancing behaviours.

   Multiple servers are specified using existing protocol mechanisms for
   DNS Service records (SRV).  An experimental record definition is
   described, which can be implemented on existing systems.

Greg Daley
NetStar Australia Pty Ltd

E-mail: gdaley _at_ netstarnetworks.com
Mobile: +61 401 772 770
Direct: +61 3 8532 4042

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 11 Jan 2010 23:35:02 +0000

Replying off list was not intentional, bringing this back on-list :-)

2010/1/11 Greg Daley <[email-masked]>:
> Hi Colm,
>
> You didn't respond on the list.  Was this intentional?
>
> If not, could you please make any responses to the list,
> so that there's a record of why changes were made.
>
> Answers inline below:
>
>> -----Original Message-----
>> From: Colm MacCárthaigh [mailto:[email-masked]]
>> Sent: Tuesday, 12 January 2010 2:49 AM
>> To: Greg Daley
>> Subject: Re: [dnsext] Use of DNS SRV records for host selection
>>
>> On Mon, Jan 11, 2010 at 1:01 AM, Greg Daley
>> <[email-masked]> wrote:
>> > URL:
>> The underscore effectively subtracts one byte from the maximum
>> hostname length. Is there really a need for an underscore? In section
>> 4, what's a negative response? Is a CNAME/DNAME ok (and then the usual
>> following ) ? Negative response should probably be defined as a zero
>> number of answers, or similar.
>
> I will note that the underscore effectively reduces the length of the
> hostname due to the label length constraint.
>
> I do not know if there is a strict need for an underscore, but for
> this version of the draft wanted to be able to operate without
> modification to the SRV RFC 2782.  The obsoleted RFC 2052 had no
> underscores required, and that behaviour was explicitly changed in the
> revision.
>
> For hosts (rather than services), one could possibly implement SRV
> records to have the same name component as the A or AAAA record, but
> some implementations have an explicit (Service,Proto) tuple when
> creating SRV records (for example Windows Server 2008).
>
> I'm trying to determine the utility of the system first and foremost
> (rather than requiring server modifications).
>
> The SRV record contains only a Target field, which is required to
> have a host lookup (such as A or AAAA), not allowed to be an alias
> (CNAME or DNAME).

I merely meant if this pattern was valid;

question;      _foo._host.example.com IN SRV
answer:        _foo._host.example.com IN CNAME _bar._host.example.com

...

_bar._host.example.com IN SRV

I think it should be, with regular CNAME/DNAME behaviour applying ...
but it's why I wondered if "negative response" should imply "zero
answers". It was just illustrative.

> You are right with regard to the Negative response, I will clarify
> this as 0 Answer RRs.
>
>
>> Labels can contain dots (see RFC1035 5.1). It feels like the hostname
>> should be the first label, and as simple as that. Dot-splitting is
>> more complicated.
>
> Thanks, as you point out, the description for \X states that "\." can
> be placed in a label.
>
> I was using the preferred syntax from S2.3.1 which indicates
> alphanumeric and hyphens compose labels:
>
> <domain> ::= <subdomain> | " "
> <subdomain> ::= <label> | <subdomain> "." <label>
> <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
> <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
> <let-dig-hyp> ::= <let-dig> | "-"
>
> I will try to stick to hostname/domainname in descriptions.
>
> There would seem to be a divergence then from having short unstructured
> Service labels, as are currently defined for SRV, and the hostname (label)
> element which could contain embedded "."
>
> This only matters where the host SRV record is required to take a
> particular structure with underscores for the _Protocol element.

I just think it will be easier for implementors if when passed;

   "foo\.bar.example.com"

that the the lookup is for;

  _foo\.bar._host.example.com

rather than

  _foo._host.bar.example.com

it's one boundary case with the existing language. DNS resolvers and
clients can typically avoid text processing, but as-defined, the
language of the I-D would require string manipulation.

>> Lastly, I'm not sure of the usefulness of the example records
>> section, the rest of the document is fairly explanatory.
>
> Thanks for that.  I'm currently showing the idea to int-area people to see
> if this meets some of their provider aggregatable addressing requirements
> for IPv4/IPv6 transition.  If the sections are seen as extraneous to their
> understanding, I will remove them.
>
> Thanks for your feedback,

Thanks for the reply!

-- 
Colm

---

From: "Greg Daley" <[email-masked]>
Date: Tue, 12 Jan 2010 14:28:38 +1100

Hi Colm, 

> answers". It was just illustrative.

I believe for the initial response it would be possible to use
CNAME/DNAME, but would there then be a (restarted) SRV lookup on
the canonical name?

S5.1 of DNAME-bis specification identifies that the DNAME substitution
occurs before specific (MX,SRV,PTR) records:

http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-18

For CNAME RFC2181 S10.3 is more explicit about this, where it discusses
MX and NS  records.  CNAME is included in the response with no additional
section processing, with the query potentially being restarted (with the
same QTYPE, and the CNAME substituted).

I don't think that these issues have been widely examined because for service
(not host) SRV records your would not typically have a (non-SRV) CNAME response.

I would guess that this CNAME behaviour is valid as well, although in
absence of guidance (other than that for the Target field of RFC2782),
people have been assuming that no CNAME record can be used in response to SRV
queries:

https://issues.asterisk.org/view.php?id=6314

>> Thanks, as you point out, the description for \X states  that "\." 
>> can be placed in a label.
>>
>> There would seem to be a divergence then from having short 
>> unstructured Service labels, as are currently defined for SRV, and the 
>> hostname (label) element which could contain embedded "."
>>

I will make sure that the text is updated.

Greg