From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4312 Path: news.gmane.org!not-for-mail From: Justin Cormack Newsgroups: gmane.linux.lib.musl.general Subject: Re: IPv4 and IPv6 addresses in resolv.conf Date: Sat, 30 Nov 2013 17:23:22 +0000 Message-ID: References: <761df492-c2ee-41d5-84f8-faef313164bf@email.android.com> <20131129174410.GD24286@brightrain.aerifal.cx> <20131130003704.GL24286@brightrain.aerifal.cx> <20131130031744.GM24286@brightrain.aerifal.cx> <20131130035116.GO24286@brightrain.aerifal.cx> <20131130035912.GP24286@brightrain.aerifal.cx> <20131130170112.GR24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1385832210 21004 80.91.229.3 (30 Nov 2013 17:23:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Nov 2013 17:23:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4316-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 30 18:23:36 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VmoGW-0001uV-0t for gllmg-musl@plane.gmane.org; Sat, 30 Nov 2013 18:23:36 +0100 Original-Received: (qmail 14111 invoked by uid 550); 30 Nov 2013 17:23:35 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 14103 invoked from network); 30 Nov 2013 17:23:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=specialbusservice.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kd614IC0r4dXTAYg1QopGmGMirBBPMjRFfsd3wkihgM=; b=V1amlM4h86h6N1fe2FuEBNsfd4SgPrkhjQYoN3cQofT9E7MwAVcmGRFMsBrL4Lxk95 7sRnKhGME/+iNomd9APEaX7CJLCJLdF0L3O1TEjH29vHz2annE6zenZqIwm+hhKQO4ZX isEbVXbi8eUXgr3ESGDzuffOiiswvI2jrVie8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kd614IC0r4dXTAYg1QopGmGMirBBPMjRFfsd3wkihgM=; b=gA8ozPMvN3dCYL4+j8MEMKfTkBSIPE5p6+5ajCCw5vkTGcI7VCYYpbVLqy/VYlkqlH niroaqifDI9QZAjzODzJTLtn7W7/rK6WPPXePyUSsKjJcerZFEdIuezERzfus0IC09eR bX8wsYt2H+RkxE2ecRgExxxY89ea9b5DcH4lhLwaHPpraz9epWjKYF3DYLwXmEV8x8Eb XJJ/iGlNDGa1j7D6Q/XCVOWsfFjPgtplhCYaZpMFGlpPHkm8IPHSYf4vDFuaqX7gcJ2R MkohTRkhw8DIXpo+tC54MB1T1EKLrcpQp8BAuz4o8KWAONb9sXmoyAKnKoAhqT6Mxjea uW9Q== X-Gm-Message-State: ALoCoQl2ai3qVRxrFeroQ6Eb1FBGN5ibmRHWRa0DmREPZZc861qobFoJcqrMXCfsaqMeB0dG4xtR X-Received: by 10.68.172.196 with SMTP id be4mr22350108pbc.12.1385832202590; Sat, 30 Nov 2013 09:23:22 -0800 (PST) In-Reply-To: <20131130170112.GR24286@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:4312 Archived-At: On Sat, Nov 30, 2013 at 5:01 PM, Rich Felker wrote: > On Sat, Nov 30, 2013 at 09:16:54AM +0000, Justin Cormack wrote: >> On 30 Nov 2013 03:59, "Rich Felker" wrote: >> > >> > On Fri, Nov 29, 2013 at 10:51:16PM -0500, Rich Felker wrote: >> > > On Fri, Nov 29, 2013 at 10:45:26PM -0500, Strake wrote: >> > > > On 29/11/2013, Rich Felker wrote: >> > > > > But that would mean complete unconditional DNS failure on systems >> > > > > lacking IPv6. >> > > > >> > > > We could do so iff system has IPv6. Switching on whether system has >> > > > IPv6 rather than whether resolv.conf has any IPv6 nameservers means >> > > > * no check whether resolv.conf includes v6 server >> > > > * that adding a v6 server to resolv.conf can not break DNS even on >> > > > systems lacking v6 >> > > > which seems saner. >> > > >> > > OK, so how do we detect if the system "has IPv6"? I don't think it's >> > >> > BTW, short of an answer to this question, I think the approach I >> > already suggested is rather safe. I can't imagine how an IPv6 >> > nameserver address would end up in resolv.conf on a system completely >> > lacking IPv6 support at the kernel level. >> >> I can imagine how it got there eg if you have a standard config or you >> compile a new kernel and omit ipv6... > > Indeed, this is conceivable. However, if the system is intended to be > used on an IPv6 network and you compile without IPv6 in the kernel, > lots of things will break and you probably just need to fix the > kernel. Still I'd like to avoid more breakage here than necessary. > > Can you (or anyone) fill me in on how things fail on a system built > without IPv6 support or with broken IPv6 configuration? I assume the > original socket() call will fail (with what errno?) if IPv6 support is > not even compiled into the kernel, but are there other cases where > socket() might succeed but then sending to a v4-mapped address would > fail (where sending to the same v4 address with a v4 socket would > work)? It is EAFNOSUPPORT if no kernel support at all. Actually I don't think there can be any cases where sending to the v4-mapped address (ie ::ffff:1.2.3.4) can fail where an ipv4 socket will succeed because those are basically ipv4 sockets with just ipv6 notation, those addresses can't be routed by the ipv6 stack. So it should be safe to try to open a v6 socket, then if that succeeds, convert all ipv4 addresses to v4-mapped and use that, else fall back to v4 socket and drop any v6 addresses. Which is what you have below... > The fallback scheme I'm thinking of using is something like: > > if (have_any_v6_nameservers) { > if (socket(PF_INET6, ...) && errno=EAFNOSUPPORT) { > disable any v6 nameservers > open and use v4 socket > } > v4-map all v4 nameservers > use v6 socket > } else { > open and use v4 socket > } > > Does this look reasonable? > > Rich