Subject: Re: SRV vs. A/AAAA RR lookups

From: Bernard Aboba <[email-masked]>
Date: Mon, 27 Oct 2008 23:25:18 -0700

Stefan Winter said:

"
Appendix A currently does a NAPTR lookup for the realm, and if not found looks for

_radsec._tcp.realm IN A/AAAA

It has been brought to my attention that many DNS people frown over
using underscore service lookups with A and AAAA. Apparently, there is
an opinion that this is exactly what SRV was intended for, and I agree.

The thing is: the algorithm in Appendix A is derived from the RFC3588
dynamic lookup algorithm. I.e. there is standards-track precedence for
using _service._transport IN A. "

RFC 2782 defined SRV RRs in order to support service location.  The
goal was to enable an SRV cognizant client to discover services within
a domain.  

The format of the SRV RR is:

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

Here the "weight" parameter enables load balancing, and the "Port"
parameter enables dynamic discovery of the port on which the service
is running.  Target is the name of a server offering the service. 

In contrast, the A/AAAA record supports neither weight (e.g. uneven
load balancing), nor a "port" field.  It also does not support 
a level of indirection (e.g. it returns an address, not the name
of a server to resolve to find the address of the service). 

Given this, it would seem that the argument rests on whether these
additional parameters are useful or whether they typically just 
represent additional overhead.  The AAA WG leaned toward the 
latter, but the RADEXT WG can make its own decision. 

IMHO, the port field may occasionally be useful in
dynamic discovery scenarios. RADSEC is allocated a static port,
but it is conceivable that an operator might want to run it
on another port.  If we are commited to the idea that a
RADSEC client should be able to connect to a RADSEC server within
a domain with no configuration other than a trust anchor and a
domain name of the server, and we believe that port discovery
is necessary, then the SRV RR is the better choice.  It is harder
to make a case for the weight field, since any desired load 
balancing can be achieved by shuffling of A/AAAA RRs.  

In terms of the use of the SRV naming scheme within an A/AAAA RR,
this seems like a minor issue.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 29 Oct 2008 09:19:40 +0100

Hello,

> latter, but the RADEXT WG can make its own decision. 

I have to say I'm very much in favour of having the option to discover
the port. If a given server hosts two instances of a RadSec peer, it
will have to use different ports. There are cases where people want to
or have to deploy two separate instances. E.g. if clients do not send
the CA indication, and the server is in possession of multiple
certificates. Typical workarounds for the lack of server certificate
selection possibilities so far in our static setup were that two
instances were created, and clients configured to the instance which had
the "right" ceritificate to present.
Having the flexibility of a SRV lookup does not look like unnecessary
luxury to me.

> It is harder

I'm not even sure about that. In my experience, shuffling A's (I suspect
you mean adding multiple A's for one host name in a zone file) does not
lead to any deterministic result, since both authoritative name servers
and resolvers can autonomously re-order what they got from upstream. One
of the scenarios that can't be modelled in this case is that a deployer
has a server he considers "primary" (i.e. which should usually handle
*all* requests for a realm) and a "backup" (which shouldn't get any
requests unless the primary is down). I'm having trouble imagining how
such an intended behaviour can be put into A/AAAA semantics at all.

All in all, I would prefer SRVs very much.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

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