> I see your point, thank you. > Fallback is done just to conform RFC 2782 suggestion, personally I feel it's > hardly be used with controllable client profiles when it's known that > domain.tld does dns srv.
Yes. And see the point in that RFC. I would rather document that for out fallback the user has to manually specify that because I don't see a good "works for all" fallback. > Additional --remote-srv indeed has benefits: > * opens a non-conflicting syntax way to have multiple udp/tcp dns srv > requests, as you wrote in earlier mails. This will allow to sort them all by > prio/weight. > * cleaner syntax for specifying custom dns srv service name, with default > "openvpn" and protocol (if need to limit discovery to only udp or tcp) > So, in my mind syntax looks like: > --remote-srv [service] [protocol], where both args are optional, by > default service==openvpn, protocol==any Sounds good to me! > And, important thing, multiple --remote-srv still needs to be supported for: > * custom order of protocol > * different service names > * allow to reuse --remote-random with --random-srv as well to achieve > dns-srv-based lb > > Is it good enough in this form? I don't really see the need for that but it doesn't break the normal case of just one remote-srv, so fine with me. Arne
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
