FR 3.0 radsec : dynamic home server discovery status

Jorge Pereira jpereira at freeradius.org
Fri Mar 13 19:49:36 CET 2020


Arran,

Maybe we could use the libcares instead of parser the dig output.

e.g:

[jpereira at jorge-sugarloaf sample-c-ares.git]$ ./naptr 0.2.0.1.1.6.5.1.0.3.1.loligo.com <http://loligo.com/>.
[**] Looking for NAPTR records from 0.2.0.1.1.6.5.1.0.3.1.loligo.com <http://loligo.com/>.
[1] { .order=25, .preference=100, .flags='u', .service='E2U+sip', .regexp='!^\+13015611020$!sip:2203 at sip.fox-den.com!' <sip:2203 at sip.fox-den.com!'> }
[2] { .order=21, .preference=100, .flags='u', .service='E2U+tel', .regexp='!^\+13015611020$!tel:+14155551212!' <tel:+14155551212!'> }
[3] { .order=30, .preference=100, .flags='u', .service='E2U+sip', .regexp='!^\+*([^\*]*)!sip:\1 at sip-3.fox-den.com!' <sip:\1 at sip-3.fox-den.com!'> }
[4] { .order=26, .preference=100, .flags='u', .service='E2U+sip', .regexp='!^\+13015611020$!sip:1234 at sip-2.fox-den.com!' <sip:1234 at sip-2.fox-den.com!'> }
[5] { .order=55, .preference=100, .flags='u', .service='E2U+mailto', .regexp='!^\+13015611020$!mailto:jtodd at fox-den.com <mailto:jtodd at fox-den.com>!' }
[6] { .order=10, .preference=100, .flags='u', .service='E2U+tel', .regexp='!^\+13015611020$!tel:+12125551212!' <tel:+12125551212!'> }
[jpereira at jorge-sugarloaf sample-c-ares.git]$


Same as “dig”

[jpereira at jorge-sugarloaf sample-c-ares.git]$ dig NAPTR 0.2.0.1.1.6.5.1.0.3.1.loligo.com <http://loligo.com/>. +short
26 100 "u" "E2U+sip" "!^\\+13015611020$!sip:1234 at sip-2.fox-den.com <sip:1234 at sip-2.fox-den.com>!" .
25 100 "u" "E2U+sip" "!^\\+13015611020$!sip:2203 at sip.fox-den.com <sip:2203 at sip.fox-den.com>!" .
21 100 "u" "E2U+tel" "!^\\+13015611020$!tel:+14155551212 <tel:+14155551212>!" .
30 100 "u" "E2U+sip" "!^\\+*([^\\*]*)!sip:\\1 at sip-3.fox-den.com <sip:\\1 at sip-3.fox-den.com>!" .
10 100 "u" "E2U+tel" "!^\\+13015611020$!tel:+12125551212 <tel:+12125551212>!" .
55 100 "u" "E2U+mailto" "!^\\+13015611020$!mailto:jtodd at fox-den.com <mailto:jtodd at fox-den.com>!" .
[jpereira at jorge-sugarloaf sample-c-ares.git]$

---
Jorge Pereira
jpereira at freeradius.org




> On 13 Mar 2020, at 12:44, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
> 
> 
> 
>> On Mar 13, 2020, at 9:54 AM, Alan DeKok <aland at deployingradius.com> wrote:
>> 
>> On Mar 13, 2020, at 8:57 AM, Stefan Winter <stefan.winter at restena.lu> wrote:
>>> many hundreds of realms set NAPTR records in eduroam. Those typically
>>> point to an approximate dozen of country-level endpoints which take the
>>> traffic from there over RADIUS/UDP.
>> 
>> That makes sense.
>> 
>>> To be honest, the lack of NAPTR lookup capability is my #1 reason why
>>> I'm using Radiator and radsecproxy as the two RADIUS implementations for
>>> my own country-level servers. Both allow dynamic lookups.
> 
> Out of interest, is it a mix of UDP+DTLS and TCP+TLS?
> 
> Is there a way of specifying a preference via the NAPTR records?
> 
> -
> 
> For v3 I think poking via radmin to add new destinations might be a reasonably simple way to do this asynchronously.
> 
> Request comes in for new realm, calls exec to trigger a script to do the resolution and insert the realm info via radmin (maybe just have the ability to define new realms via config snippets?). FR doesn't responsd to the original request.
> 
> Retransmit comes in, gets forwarded to realm that's now magically appeared.
> 
> Synchronisation for the realm rbtree would be a pain, but as this is relatively low volume, maybe just add a toggle that puts a mutex around the tree?
> 
> -
> 
> For v4 the other thing that occurred to me, is that it wouldn't be *that* hard to fix the exec calls to be async.  You just need to stick the server ends of stdout/stderr into the event loop. I think kqueue also has a notification system for process exits too...
> 
> So one quick/hacky way of doing the lookups could just be calling out to dig and parsing the results.
> 
> Actually adding radsec and dynamic realm support is much much easier in v4.
> 
> -Arran
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <http://www.freeradius.org/list/users.html>


More information about the Freeradius-Users mailing list