> From: Arne Schwabe > Sent: Wednesday, September 9, 2020 5:15 PM > > 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.
Sure, I saw. RFC point of fallback was pretty valid for combined --remote for seamless migration dns->srv dns. With new --remote-srv this will be not necessary anymore, no migration here. Moreover, facing the coexisting with usual --remote, fallback becomes pretty useless additional complexity. > > > 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! Great, doing this way. > > > 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 > -- Best Regards, Vladislav Grishenko _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
