> This is the right place to submit bug reports. Thanks.
> Having said that, your bug report seems more like a feature request since > routing commands/APIs generally do not support DNS A-record expansion > as a standard feature. I understand that it's halfway between feature request and bugreport. The current code does explicitly allow FQDN in route commands and its implementation just happens to choose one (randomly) one IP rather than to select all of them. This basically means that such route commands only work reliably for FQDNs that have only one IP. This is a restriction that iseems to come just from the implementation rather than from a design choice: the FQDN-to-IP mapping is done by reusing the code used elsewhere, but that "elsewhere" is when we want to connect to that FQDN, so in that case selecting all IPs is nonsenscal and we need to choose one (tho we may want to cycle in case of connection failure). So I do think it's a bug, but I understand that it can be considered as a feature to extend route commands to support multiple-IP FQDNs. In either case, I'd love to hear comments about my patch (and even more so to have it be included, since I rely heavily on this feature). > It's an interesting idea though, and one that makes sense, but I haven't > seen any other requests for it. I use it for example to let clients connect to portal.acm.org (which has 2 IPs) via the VPN so as to benefit from the site-wide digital-library access we have. Without this feature, either the redirection works unreliably (half the times, the connection is done via the VPN the other half it's done directly), or I'd have to redirect all traffic (causing a significant load increase on the VPN server, increase of bandwidth use, and general slowdown for the clients), or hard-code the IPs and try and detect when they change. Stefan