blob: 4e6d2bcd531b4fad155075a65e752eb205ca25ba (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
|
Mail[1] to the radsecproxy mailing list Wed, 14 Apr 2010 from Stefan
Winter explaining the radsec-dynsrv.sh and naptr-eduroam.sh scripts.
------------------------------------------------------------
Hi,
the radsec-dynsrv.sh script right now looks up _radsec._tcp.$REALM. For
eduroam, the production discovery will rely on S-NAPTRs of "s" type and
subsequent SRVs.
I have attached a preliminary version of the discovery script which
takes this logic into account. It could use some public scrutiny (where
"public" might very well evaluate to Kolbjørn Barmen, who wrote the SRV
script and knows much more about bash scripting than I do *cough cough*).
As with the other script, you call
naptr-eduroam.sh <realm>
If you need a test case, the DNS domain restena.lu has the NAPTR and the
SRV record live in place. On my system, you get:
> ./naptr-eduroam.sh restena.lu
server dynamic_radsec.restena.lu {
host radius-1.restena.lu:2083
type TLS
}
with our live DNS data (radius-1.restena.lu isn't really
production-ready yet though).
If you're curious, the S-NAPTR for eduroam right now is
x-eduroam:radius.tls
with a possibility of a later IETF allocation of either
aaa:radius.tls (probable)
eduroam:radius.tls (wishful thinking)
, in which case changing the script to use the new ones is trivial.
Greetings,
Stefan Winter
------------------------------------------------------------
[1] https://postlister.uninett.no/sympa/arc/radsecproxy/2010-04/msg00011.html
|
