Arran, Maybe we could use the libcares instead of parser the dig output. e.g: [jpereira@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@sip.fox-den.com!' <sip:2203@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@sip-3.fox-den.com!' <sip:\1@sip-3.fox-den.com!'> } [4] { .order=26, .preference=100, .flags='u', .service='E2U+sip', .regexp='!^\+13015611020$!sip:1234@sip-2.fox-den.com!' <sip:1234@sip-2.fox-den.com!'> } [5] { .order=55, .preference=100, .flags='u', .service='E2U+mailto', .regexp='!^\+13015611020$!mailto:jtodd@fox-den.com <mailto:jtodd@fox-den.com>!' } [6] { .order=10, .preference=100, .flags='u', .service='E2U+tel', .regexp='!^\+13015611020$!tel:+12125551212!' <tel:+12125551212!'> } [jpereira@jorge-sugarloaf sample-c-ares.git]$ Same as “dig” [jpereira@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@sip-2.fox-den.com <sip:1234@sip-2.fox-den.com>!" . 25 100 "u" "E2U+sip" "!^\\+13015611020$!sip:2203@sip.fox-den.com <sip:2203@sip.fox-den.com>!" . 21 100 "u" "E2U+tel" "!^\\+13015611020$!tel:+14155551212 <tel:+14155551212>!" . 30 100 "u" "E2U+sip" "!^\\+*([^\\*]*)!sip:\\1@sip-3.fox-den.com <sip:\\1@sip-3.fox-den.com>!" . 10 100 "u" "E2U+tel" "!^\\+13015611020$!tel:+12125551212 <tel:+12125551212>!" . 55 100 "u" "E2U+mailto" "!^\\+13015611020$!mailto:jtodd@fox-den.com <mailto:jtodd@fox-den.com>!" . [jpereira@jorge-sugarloaf sample-c-ares.git]$ --- Jorge Pereira jpereira@freeradius.org
On 13 Mar 2020, at 12:44, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Mar 13, 2020, at 9:54 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 13, 2020, at 8:57 AM, Stefan Winter <stefan.winter@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>