[dns-operations] rfc compliance of a radsec approach?
gilles.massen at restena.lu
Fri Oct 17 14:28:39 UTC 2008
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
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
> 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.
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
tel: (+352) 424409
fax: (+352) 422473
More information about the dns-operations