[dns-operations] rfc compliance of a radsec approach?

[Joe Abley]

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.


Joe