From owner-freebsd-net@FreeBSD.ORG Sun Apr 19 07:30:32 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57FA1338 for ; Sun, 19 Apr 2015 07:30:32 +0000 (UTC) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtp003.mac.com [17.172.81.2]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F831258 for ; Sun, 19 Apr 2015 07:30:32 +0000 (UTC) Received: from akita.localnet (c-73-162-13-215.hsd1.ca.comcast.net [73.162.13.215]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Dec 4 2014)) with ESMTPSA id <0NN100M6SM6O4D20@st11p00mm-asmtp003.mac.com> for freebsd-net@freebsd.org; Sun, 19 Apr 2015 07:30:25 +0000 (GMT) From: Rui Paulo To: freebsd-net@freebsd.org Cc: Yuri Subject: Re: resolvconf(8) always leaves original DNS server in the list, allowing DNS requests to leak Date: Sun, 19 Apr 2015 00:30:23 -0700 Message-id: <4525101.OcnIUfWoXM@akita> User-Agent: KMail/4.14.3 (FreeBSD/11.0-CURRENT; KDE/4.14.3; amd64; ; ) In-reply-to: <5532F439.8070506@rawbw.com> References: <5532F439.8070506@rawbw.com> MIME-version: 1.0 Content-transfer-encoding: 7Bit Content-type: text/plain; charset=us-ascii X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.33,0.0.0000 definitions=2015-04-19_01:2015-04-17,2015-04-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=4 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1504190067 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 07:30:32 -0000 On Saturday 18 April 2015 17:18:01 Yuri wrote: > I am looking at this typical situation: the VPN app creates and sets up > tap0 interface meant to be the new default route. > > Then it calls this command: > > echo " > > nameserver > > domain > > " | resolvconf -a tap0 > > Problem: > > /etc/resolv.conf now looks like this: > > nameserver > > nameserver > > The old DNS server is left at the last position. This means that in > cases when the new server fails, DNS resolution falls back on the old > server, therefore allowing DNS requests to leak. > > I looked through the resolvconf man page, and can't find any way that > application can replace the old DNS server there. It can only add the > new one for some interface, and in the end remove it. The new server > "overrides" the old one, but still leaves the old one there. This > creates the situation when DNS leaks to the old server. > > I would like to suggest the new option: > > -x Make the new DNS server exclusive. > > With this option resolvconf(8) will replace the old server with the new one. What you want requires scoped routing and scoped DNS, meaning that the network stack must have knowledge of what domain names a specific VPN DNS server resolves. The resolv.conf file is completely unsuitable for this purpose. The solution you offer is just a hack to avoid the "leak" of DNS domain names and doesn't really solve the bigger problem. What if the VPN DNS server doesn't resolve google.com? -- Rui Paulo