Openconnect resolution issue

[David Woodhouse]

On Fri, 2015-09-18 at 19:14 -0400, Ronen Leibovici wrote:
> Good day,
> 
> Here is the situation.
> 
> When working on my RHEL6 host, I use AT&T dialer to connect to my
> companies intranet.
> When doing so, my resolv.conf file is updated to include the
> nameservers of my company.
> 
> Then, I use openconnect in order to connect to our customer. This also
> works and the resolv.conf file is edited by VPNC to include the
> nameservers of our customer.
> 
> The problem lies in the fact that if i try to perform any resolution,
> it fails because, for some reason, my O/S has now been told that
> recursion is not allowed and only the first name server in my
> resolv.conf file is queried.

No, 'recursion' in this context means something different.

To simplify a little... when a name server receives a request, one of
two things can happen. Either it's a request for which this server is
authoritative, and it is providing the original data to the world at
large... or it's *not*, and the server is expected to go and find out
which server *is* authoritative for the request, and ask *that* server
for the answer. The latter process is what we call recursion.

Most servers should have strict controls on which clients they will
actually do recursion for, because it can lead to being used in denial
-of-service attacks (the attacker fakes lots of DNS requests claiming
to be from the IP address that they want to attack, generating large
responses).

So when you get a refusal from one nameserver, nslookup quite
reasonably interprets that as 'recursion not allowed' and tries the
next. That's all.

I don't quite understand why non-recursing nameservers would be
advertised in the VPN connection; that seems like a misconfiguration.
Surely you should tell the VPN clients to use a nameserver that *is*
going to recurse for them?

> ex:
> [root at oc8146477318 ~]# nslookup w3.ibm.com
> Server: 96.4.1.83
> Address: 96.4.1.83#53
> 
> ** server can't find w3.ibm.com: NXDOMAIN
> 
> 
> If I connect to my AT&T dialer and then use Cisco Anyconnect Gui or
> CLI to connect to the customer, name resolution works:
> 
> ex:
>    [root at oc8146477318 cscotun0]# nslookup w3.ibm.com
> ;; Got recursion not available from 96.4.1.83, trying next server
> ;; Got recursion not available from 96.130.126.21, trying next server
> Server: 9.0.148.50
> Address: 9.0.148.50#53
> 
> w3.ibm.com canonical name = w3.ibm.eventsgslb.ibm.com.
> Name: w3.ibm.eventsgslb.ibm.com
> Address: 9.17.137.11
> 
> 
> When using openconnect, I am trying to understand why name resolution
> is not going through the entire list of name servers defined in
> resolv.conf.

OpenConnect basically has no control over the behaviour of name
resolution. All it does is set up the resolv.conf file — and in fact
OpenConnect itself doesn't even do that; vpnc-script does.

Firstly, can you show the contents of the working and non-working
resolv.conf files?

My first suspicion is that you have too many nameservers listed. I
think glibc will only use the first three before giving up. If you
happen to have a sane one in the first three then you win; if it's only
those stupid non-recursing ones then you lose. So a slight difference
in the *order* in which nameservers get listed might be causing the
failure.

> -- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20150923/66f62659/attachment-0001.bin>