Hi AAAA record should be used first if present. But if there's an a A and AAAA then both should be used too , ie in client or proxy mode - we have dual stack and gave both v6 and v4 defined to give us routing resiliency Also... if the address doesn't resolve the server fails to start? Ouch. Very nasty behaviour -1 alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

On 31 May 2014, at 10:49, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:

On 31 May 2014, at 10:27, Alan Buxey <A.L.M.Buxey@LBORO.AC.UK> wrote:

...

Hi

AAAA record should be used first if present. But if there's an a A and AAAA then both should be used too

I sort of agree, but that would break any existing implementations where the home_server has A and AAAA records but is not listening on it's V6 address, so it's really not a good idea.

...

, ie in client or proxy mode - we have dual stack and gave both v6 and v4 defined to give us routing resiliency

If you want this behaviour then define a v4 and v6 home server and use ipv4addr and ipv6addr, that's exactly the sort of scenario they were added for.

Else the server would have to add both, then go through a vetting process to figure out whether there's a server listening on both the v4 and v6 addresses.

The logic we have here may not be the same for things like dynamic home servers/dynamic discovery. There's a very big difference between the system administrator hard coding the addresses of servers, and FreeRADIUS having to discover the state of the world from a realm.

...

Also... if the address doesn't resolve the server fails to start? Ouch. Very nasty behaviour -1

You've specified a remote resource which doesn't exist. It's the same with the connection pool, if it can't establish 'start' connections for a pool the server fails to start.

And to quote from the clients.conf file which has been shipped with the server for many years: # # A note on DNS: We STRONGLY recommend using IP addresses # rather than host names. Using host names means that the # server will do DNS lookups when it starts, making it # dependent on DNS. i.e. If anything goes wrong with DNS, # the server won't start! # # The server also looks up the IP address from DNS once, and # only once, when it starts. If the DNS record is later # updated, the server WILL NOT see that update. # -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On 31 May 2014, at 12:57, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:

...

...

Also... if the address doesn't resolve the server fails to start? Ouch. Very nasty behaviour -1

...

You've specified a remote resource >which doesn't exist.

For clients though? If a client doesn't exist then , shrug, they're not going to talk to me. Some installations have very dynamic upgrades/changes and a few dozen obsolete entries might easily exist. .. or those people with random VPN hookups that have all kinds of crazy dynamic hostname setups.

Then with by the same token you used to justify doing AAAA lookups by default, the response for those sites is they need to get their act together and clean the shit out of their configs. I'm generally all for holding administrators to very high standards of config cleanliness. The reason for using A records by default is because we have a policy of not introducing behavioural changes with point releases. But seeing as the code modifications have probably changed the behaviour of client <hostname> { entries anyway (from being first available record to a preference for V4), I guess we could switch to V6 first. The clients behaviour is not new and I don't see a compelling reason to change it. It is easy to monitor the validity of the server config using -C, hell setup a cron job to ping administrators if the config becomes invalid for some reason... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

There's a few updates to original RFC regarding choice of transport layer for connections. It used to be pretty much prefer IPv6 but in some systems that doesn't make sense. ... routing or address availability...which is why other things such as happy eyeballs came along RFC 6724 makes more sense in this regard Say, for example, my server only has IPv6 connectivity to the Internet and a local 192.168.x.x address (with no NAT) . A lookup of a remote server xyz.com gives me back an A and AAAA record. Will you be trying to use that v4 result and leave the server non contactable? I'd hope not (and quite a few people are now having such servers as IPv6 only....) alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Alan Dekok wrote:

Too bad. If the address doesn't resolve, then you shouldn't be listing the clients in DNS.

RADIUS depends on IP addresses.

Going way out on the limb of conjecture here, when I get back to working on DDDS, the part I haven't even begun to tackle yet is that the server is expected to dynamically determine IPs from DNS. This will require a rather extensive rewire of the internals, which gets a bit messy when you have ongoing EAP conversations during a DNS change that alters either the availability or weightings of servers in a server pool, since some sort of server affinity mechanism needs to override the DNS for existing conversations for a grace period. However, once that's done, what I wrote on the DNS side as far as the config options/functionality is not all-or-nothing DDDS, it also degrades nicely to non-DDDS uses, down to a the case of a single hostname that may change. For home servers, the conjectural behavior when DNS fails for all servers in the pool would be an empty pool would be brought up, so the server would still start, but would behave as if it had no non-dead servers in that pool. Then things would start working when DNS started working again. Also as far as AAAA/A records it would try both unless told otherwise, so worst case there is we end up load balancing needlessly between the A and AAAA sockets on the same server, or having a useless marked-dead home server hanging around for one of the address records if ipv4 or ipv6 were broken. For clients I haven't thought much into that, because validation of incoming requests in the use case for DDDS relies on PKI/realms.

Alan DeKok wrote:

...

Brian Julin wrote: For home servers, the conjectural behavior when DNS fails for all servers in the pool would be an empty pool would be brought up, so the server would still start, but would behave as if it had no non-dead servers in that pool. Then things would start working when DNS started working again.

That isn't the issue. The issue is that DNS failures can take 30s to time out. So the server will be down for 30s... potentially for each DNS lookup. That's bad.

The solution is to delay the DNS lookups until some later time. But... when?

Yes, just bring up the servers in an dead-ish state, and resolve the DNS asyncronously, then mark them alive. In DDDS you pretty much have no choice but to look up fresh domains when the request comes in, because you don't know them until then. As long as your DNS is caching and sanely configured, though, this will be the minority of requests. I would imagine in the case of literal servers in the config file, we would start up status-server immediately and this could be done during the setup of status-server requests and that would be a clean model for it.

And how long does it keep retrying? Does that go into a child thread? If so, how does it update the structures in the main thread?

The unbound library does all its interim work (calling back for recursion and DNSSec and whatnot in its own threads (or processes) which can queue callbacks in the application once it has final results, but the callback queue does not get run until explicitly told to from an application thread context. There is also a selectable socket and such to determine when callbacks are ready to run. They have to do it that way to support the optional process-based model. So we have say over whether callbacks get run from the main thread or not, and they are run sequentially, not in parallel. The example code in my fork does a stable job of delivering current DDDS results in attributes to the post-realm stages of request processing, even though that involves making multiple requests from DNS based on previous results. (I do still have to refork and adjust that code now that the experimental event loop is available, that fork is still hacking up the protocol mechanism and no doubt some freshening is needed.) At that point the actual choice of the server has not been made yet but the eligible hosts and their probability weights are known. So other than the structural layout work and how to hash/balance when your weights can change, the question boils down to what happens when we need to modify the pools themselves by adding an ad-hoc server -- how do we signal the main thread to do that work and then defer until it finishes, then do it again if that fails, then drop the request if it all takes too long and rely on the client to retry, perhaps completing the work in the meantime. When doing the lookups I have libunbound to bounce things off, but then later we need to use in-house mechanisms. Also naturally this all has to be done while allowing the worker threads enough atomic read-only access to use existing/cached connections.

...

Also as far as AAAA/A records it would try both unless told otherwise, so worst case there is we end up load balancing needlessly between the A and AAAA sockets on the same server, or having a useless marked-dead home server hanging around for one of the address records if ipv4 or ipv6 were broken.

And when some DNS admin (i.e. non-RADIUS) adds another A record without telling you... the proxy is suddenly going to be trying an address which has no RADIUS server.

In that case you end up with another dead server, and log entries to match, and I don't think it should be incumbent on FreeRADIUS to attempt to do anything other than log that problem at a reasonable rate. The potential for foot shooting when the RADIUS and DNS administrators are in different departments is indeed high.

The failure cases for DDNS lookups are many, and hard to get right.

Yup. I had a long back and forth with the RFC editor about just what to do in the various places where failures can occur and there are a few tweaks resulting from that that still need to be made to the code in my fork. That handles all the DNS-level failure scenarios but there is also the scenario of connection attempt failures and how to feed those back into the DDDS process to cause traversal into backup branches of the DDDS tree. It's a bear, but I think it is doable.