From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11978 Path: news.gmane.org!.POSTED!not-for-mail From: Srinivasa Raghavan Newsgroups: gmane.linux.lib.musl.general Subject: Re: DNS resolution happenning only after timeout Date: Wed, 04 Oct 2017 19:28:35 +0000 Message-ID: References: <20170928102854.GI15263@port70.net> <20170928165528.GA1627@brightrain.aerifal.cx> <20171004164638.4k3ozfsavcsthmhw@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114ae65acb1563055abd9d13" X-Trace: blaine.gmane.org 1507145339 14580 195.159.176.226 (4 Oct 2017 19:28:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 19:28:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11991-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 04 21:28:55 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1dzpLh-00036q-MJ for gllmg-musl@m.gmane.org; Wed, 04 Oct 2017 21:28:53 +0200 Original-Received: (qmail 1836 invoked by uid 550); 4 Oct 2017 19:28:59 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1818 invoked from network); 4 Oct 2017 19:28:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yJJgGDqsK6n3oRk18yU1CfDLcF0nUdR0K7LAfvP0xC4=; b=Sz8I03c4VFUuH/HzEO+Zmvs4cVWM51qTnn/urrPj+YTz/JvLk47FFb2I1GxnMaVy8s HOz+68YW9K2MLL6Nm0PG3WHly7AMNeqd/X6CWvSl4TQ3PIMRwkDqeq1llXd/8uX6TOtW 5IwsN7fUPtpmjAqsTdxrFPc9FtNfZkWk0ghDV5rHQioHIv1NZd5vEgspZ3e18f8GbYHt ibTuL7URad+IWeoTxAtsYxKl7qt5qbrKh11lGy/e2JUVL4t82G/ERZJ2A1fJoTHDM5Jm v9owUPaDZIfGswgPNrdgEHxVJubTKEuAkuK8trcJJlyOMyPNgV8R773yms9Jf17osem6 /FCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yJJgGDqsK6n3oRk18yU1CfDLcF0nUdR0K7LAfvP0xC4=; b=lw4DbXxGkzMV3DeMpLhCnYnSulkjQtv8pBlrweAhBRPCBkVNpRL/0ApGEGDY9tz0MF OkIOvGsA5vjE50CoylSd1hIA5UoVT5N08p0TAguGmG6HF3GW44VTb3d5USCoiS0vi0ZS LG03CovXFH3l3IOlm0yspfURMpE38wXQj05OOdahKbhMrsr2mQ26hervsBa6RPB8zFTP fuC+gM6An71MCbxu9LU0wUBnYzergBsSiTXiF9UVfGTnPkuiHd+NkNwGLhNbvYh0yDnY 5e3a2fRuRh9wjG1BNMbQf8XxHL49Z1m6b69lmbNhxqWllIjtkLyU77hy6de85CLeqsYA h8rg== X-Gm-Message-State: AHPjjUiUc3jaUyFsvRIHHSFC+D3rCjobvHGCPUiDmlMjY8rrxZC34rui HLkzIVFSqVGB9HAoUU7s/brDnuEFWeRcO6Wwwog= X-Google-Smtp-Source: AOwi7QC5WK5G/CV86g18J7stfOpbF7r1XSbRr/m7ICv8uOBQ0ESdQXSQfPyXp01dh3MFJrLqYUIsZ1uCMb6isbhcJIs= X-Received: by 10.129.169.9 with SMTP id g9mr18191078ywh.501.1507145326202; Wed, 04 Oct 2017 12:28:46 -0700 (PDT) In-Reply-To: <20171004164638.4k3ozfsavcsthmhw@voyager> Xref: news.gmane.org gmane.linux.lib.musl.general:11978 Archived-At: --001a114ae65acb1563055abd9d13 Content-Type: text/plain; charset="UTF-8" Hi Markus, Thanks for the reply. The problem is not only in nslookup, it is there in ping, tracert, curl, node.js, wget etc. :( I will debug and find the exact c api that is used for each of the scenarios. I am just wondering if there is any workaround ? Lot of folks are facing this issue (slow dns name resolution in alpine linux, with some dns servers) , and this may be the root cause? Kind Regards, Rsr On Wed, 4 Oct 2017 at 10:16 PM, Markus Wichmann wrote: > On Wed, Oct 04, 2017 at 07:18:10PM +0530, Srinivasa Raghavan wrote: > > Hi Rich, > > > > Thanks for the reply. > > > > Some updates: > > 1. Our DNS server is "Infoblox appliance". > > 2. When we had a delay, we found that there was a "AAAA" query along with > > "A" query. > > > > I did further debugging with "tcpdump" and able to narrow down on the > > difference in behavior between "debian" and "alpine" images. > > > > In debian: > > If ipv6 is disabled (net.ipv6.conf.default.disable_ipv6 = 1) > > Then the "nslookup" (or name resolution) does *not* do a "AAAA" query > > > > That's probably because glibc's DNS resolver only generates AAAA queries > if it can create an IPv6 socket. > > > In alpine: > > If ipv6 is disabled (net.ipv6.conf.default.disable_ipv6 = 1) > > Then the "nslookup" (or name resolution) does an "AAAA" query along with > > "A" query > > > > Is this intentional? > > > > Also, I was wondering if there was any way to disable AAAA query in name > > resolution? > > > > There does not appear to be a way without changing code. In musl, the > function name_from_dns() will always generate both the AAAA and the A > query unless "family" is explicitly set to one of the address families. > No input from resolv.conf or similar is used for this. And "family" > comes directly from the caller, i.e. nslookup. You'd have to change the > nslookup code to only ask for IPv4 addresses. > > > Kind Regards, > > Srinivasa Raghavan. > > Ciao, > Markus > --001a114ae65acb1563055abd9d13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Markus,

Thanks for the reply.

The problem is not only in nslookup, it is there in ping, tracert= , curl, node.js, wget etc. :(

I will debug and find the exact c api that is used for each of the sc= enarios.

I am just wonde= ring if there is any workaround ?

Lot of folks are facing this issue (slow dns name resolution in a= lpine linux, with some dns servers) , and this may be the root cause?
=

Kind Regards,
Rsr


On Wed, 4 Oct 2017 at 10:16 PM, Markus Wichmann <nullplan@gmx.net> wrote:
On Wed, Oct 04, 2017 at 07:18:10PM +0530, Srinivasa Ragha= van wrote:
> Hi Rich,
>
> Thanks for the reply.
>
> Some updates:
> 1. Our DNS server is "Infoblox appliance".
> 2. When we had a delay, we found that there was a "AAAA" que= ry along with
> "A" query.
>
> I did further debugging with "tcpdump" and able to narrow do= wn on the
> difference in behavior between "debian" and "alpine&quo= t; images.
>
> In debian:
> If ipv6 is disabled (net.ipv6.conf.default.disable_ipv6 =3D 1)
> Then the "nslookup" (or name resolution) does *not* do a &qu= ot;AAAA" query
>

That's probably because glibc's DNS resolver only generates AAAA qu= eries
if it can create an IPv6 socket.

> In alpine:
> If ipv6 is disabled (net.ipv6.conf.default.disable_ipv6 =3D 1)
> Then the "nslookup" (or name resolution) does an "AAAA&= quot; query along with
> "A" query
>
> Is this intentional?
>
> Also, I was wondering if there was any way to disable AAAA query in na= me
> resolution?
>

There does not appear to be a way without changing code. In musl, the
function name_from_dns() will always generate both the AAAA and the A
query unless "family" is explicitly set to one of the address fam= ilies.
No input from resolv.conf or similar is used for this. And "family&quo= t;
comes directly from the caller, i.e. nslookup. You'd have to change the=
nslookup code to only ask for IPv4 addresses.

> Kind Regards,
> Srinivasa Raghavan.

Ciao,
Markus
--001a114ae65acb1563055abd9d13--