From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11980 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 20:39:48 +0000 Message-ID: References: <20170928102854.GI15263@port70.net> <20170928165528.GA1627@brightrain.aerifal.cx> <20171004164638.4k3ozfsavcsthmhw@voyager> <20171004201850.GD1627@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="089e0824025479eca4055abe9ca1" X-Trace: blaine.gmane.org 1507149618 13450 195.159.176.226 (4 Oct 2017 20:40:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 4 Oct 2017 20:40:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-11993-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 04 22:40:10 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 1dzqSd-0002JJ-GL for gllmg-musl@m.gmane.org; Wed, 04 Oct 2017 22:40:07 +0200 Original-Received: (qmail 7799 invoked by uid 550); 4 Oct 2017 20:40:12 -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 7766 invoked from network); 4 Oct 2017 20:40:11 -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=GKdzsLE6yKAnRq+t47SVV7aF5n+05WRg4a4oQZo7vJo=; b=ldNPZGM1Y1K6mj940XSo5Ai/Fe0hIIq/8EHSuRMyhZvXNhNZkmebuRhawaka7yTZ+i 6yslMUXvAZGva5WEkNgpVOkN9x7HhuF79iiIQdgSMX7kENlfVOtumkUk6PTn+yNQOqfN 0C0aZDxgWHu6lu199ttncOnsVGAckGsOhYYN6vY/y63GbQ7VLy6JWXK+i0ercmgXn56k 7wBQk31ypsFG5IkReiQ35r570Fc4d53vEjfrE+7l8Z5dgoPjt4VWf6ZLZw3Y7vlWibBG YQhpHkQXznbA4UFN19J0Etb2EGeKAKOUZd5yq2SUyx95QqPF63dS6+aZzU2HdQFBxh3w Ou2g== 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=GKdzsLE6yKAnRq+t47SVV7aF5n+05WRg4a4oQZo7vJo=; b=tvjmeikJx82BwD0pOvK4Jo1J4ZHAepk4+VHeOZ/xC52y29oUu6+NCgvxwUyI0aU6xt 8x9TiWwHgbIUjYMqS0KSs0VhC8p4ApL0RB3x+fzEmpg7OhV//GVvwEClylsULZBqHq1i T9X/1YZOakpkacM4QOtjqXOP5PhaCt82lbspAi4zXEAAlb/QJa96mVnYntKqh6zfztb+ MdeSLL4RSHackCkb/Gj2bp0WP3boBdGtrsjOnryttNJMsWvkFEUFpiFAI0kUZR9AJRgD qd+nwiHymkQ1OF1Z0Pywni0ICJs1Ll/46rivQsgvKWfsILUM/ZRPBVgO+blSnvs07uf6 m9Gw== X-Gm-Message-State: AMCzsaWzQu1FRx7Vl1jPdSjA9lU0Y65PN/Y8zhDsuEpOn7dg89+V56tu 6aLBU8x0LXlmzzw3EV0tgUeQw/+4N03miu/twS8= X-Google-Smtp-Source: AOwi7QDHQrNvPrgypbmvEcZBF6MiLB+jMRDco+cbIfA9T/jDLTTDHFzdhYQ6SpmJBtgNSHV7RFnK/xBVxVQmDsiLZKQ= X-Received: by 10.37.188.13 with SMTP id i13mr4997024ybh.438.1507149599074; Wed, 04 Oct 2017 13:39:59 -0700 (PDT) In-Reply-To: <20171004201850.GD1627@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:11980 Archived-At: --089e0824025479eca4055abe9ca1 Content-Type: text/plain; charset="UTF-8" Hi Rich, Thanks for your time and reply. Will try to get the dns fixed. Kind Regards, R. Srinivasa Raghavan. On Thu, 5 Oct 2017 at 1:49 AM, Rich Felker wrote: > On Wed, Oct 04, 2017 at 07:28:35PM +0000, Srinivasa Raghavan wrote: > > 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? > > musl does not have any way to suppress applications' requests for IPv6 > lookups. In theory if an application used the AI_ADDRCONF option to > request "only give IPv6 results if IPv6 is supported" we could do it, > but there are multiple reasons this hasn't been implemented including > ambiguity as to how exactly it should behave, and I doubt it would > help anyway since most applications don't use this option. > > From the info you've provided so far, my best guess is that you have a > buggy nameserver that either stalls or replies with a non-conclusive > message like ServFail when it receives an AAAA query. If this is the > case, there are a few possible fixes or workarounds you could try: > > 1. If the nameserver is on a device under your control, see if there's > an upgrade/patch to fix the issue. > > 2. Switch to a different nameserver without the bug like the public > Google ones at 8.8.8.8 etc. > > 3. Run your own caching/proxy nameserver on localhost and configure it > to reply NxDomain (does not exist) for all AAAA lookups. > > 4. Use iptables to catch DNS query packets for AAAA records and > redirect them to a dummy server that just always replies with > NxDomain. > > Without knowing more about your environment I can't really guess which > ones of these options, if any, might be practical for you but > hopefully at least one is. > > Rich > > > > > 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 > > > > --089e0824025479eca4055abe9ca1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rich,
Thanks for your time= and reply.
Will try to get the dns fixed.
Kind Regards,
R. Srinivasa Raghavan.


On Thu,= 5 Oct 2017 at 1:49 AM, Rich Felker <= dalias@libc.org> wrote:
On W= ed, Oct 04, 2017 at 07:28:35PM +0000, Srinivasa Raghavan wrote:
> Hi Markus,
>
> Thanks for the reply.
>
> The problem is not only in nslookup, it is there in ping, tracert, cur= l,
> 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?

musl does not have any way to suppress applications' requests for IPv6<= br> lookups. In theory if an application used the AI_ADDRCONF option to
request "only give IPv6 results if IPv6 is supported" we could do= it,
but there are multiple reasons this hasn't been implemented including ambiguity as to how exactly it should behave, and I doubt it would
help anyway since most applications don't use this option.

>From the info you've provided so far, my best guess is that you have a<= br> buggy nameserver that either stalls or replies with a non-conclusive
message like ServFail when it receives an AAAA query. If this is the
case, there are a few possible fixes or workarounds you could try:

1. If the nameserver is on a device under your control, see if there's<= br> =C2=A0 =C2=A0an upgrade/patch to fix the issue.

2. Switch to a different nameserver without the bug like the public
=C2=A0 =C2=A0Google ones at 8.8.8.8 etc.

3. Run your own caching/proxy nameserver on localhost and configure it
=C2=A0 =C2=A0to reply NxDomain (does not exist) for all AAAA lookups.

4. Use iptables to catch DNS query packets for AAAA records and
=C2=A0 =C2=A0redirect them to a dummy server that just always replies with<= br> =C2=A0 =C2=A0NxDomain.

Without knowing more about your environment I can't really guess which<= br> ones of these options, if any, might be practical for you but
hopefully at least one is.

Rich



> 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 Raghavan wrot= e:
> > > 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 =3D = 1)
> > > Then the "nslookup" (or name resolution) does *not= * do a "AAAA" query
> > >
> >
> > That's probably because glibc's DNS resolver only generat= es AAAA queries
> > 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 &= quot;AAAA" query along with
> > > "A" query
> > >
> > > Is this intentional?
> > >
> > > Also, I was wondering if there was any way to disable AAAA q= uery 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 t= he A
> > query unless "family" is explicitly set to one of the a= ddress 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
> >
--089e0824025479eca4055abe9ca1--