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