[dns-operations] rfc compliance of a radsec approach?
jabley at hopcount.ca
Fri Oct 17 11:04:33 UTC 2008
On 17 Oct 2008, at 05:58, Gilles Massen wrote:
> The scenario:
> A radius software implementing radsec (radius over TLS) receives an
> authentication request for "user at example.com". Having no authority
> over the
> realm "example.com", it makes first a DNS query to find if there is an
> (appropriate) NAPTR record for "example.com". The result should be the
> hostname of the authoritative radius server. So far, so good.
> If no NAPTR record is found, the implementation queries for an A/
> AAAA record for "_radsec._tcp.example.com", and if it receives a
> result, connects to that IP address.
> The question: is that behaviour (A-query to _radsec._tcp)
> acceptable? Is it wise?
It would be more conventional for the querying server you describe
above to send a single query "IN SRV _radsec._tcp.example.com. ?" and
parse any RDATA received in response to identify the server names and
ports it should use to send subsequent radsec queries to. Subsequent
lookups would presumably be necessary to resolve addresses for the
names extracted from the SRV RDATA. See RFC 2782.
Using underscore labels to index records other than SRV seems like it
has high potential for confusion, but perhaps not as much confusion as
the use of NAPTR records in the forward namespace.
Confusion seems like the thing you want to avoid, rather than "RFC
compliance" being the thing you want to achieve, in this case. I know
of no standard naive enough to try and suggest that the use of
particular resource records for particular purposes is prohibited.
More information about the dns-operations