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

[Gilles Massen]

Disclaimer: I'm not the implementor, nor the writer of the radsec specs...

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

My instincts suggested that approach.

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

May I ask why the NAPTR records are confusing (I'm not extensively familiar 
with NAPTR...)

I'll throw one more aspect in: the destination realm (example.com) could host 
several radsec servers for different services (e.g. one for eduroam, one for 
dial-up, ...). I believe the idea for using NAPTR records was to be able to 
see in the answer what service authenticated by which radsec server.

Another way to solve this would be to say that if "user at example.com" is an 
eduroam user, go find the radsec server 
through "_radsec._tcp.eduroam.example.com IN SRV". 

Personally, I'm attracted by the apparent beauty of NAPTR, and the simplicity 
of SRV.

> Confusion seems like the thing you want to avoid, rather than "RFC
> compliance" being the thing you want to achieve, in this case. 

Definitely. But as I said, I'm not the one making the call. Just trying to 
gather sound advice.

Thanks,
Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473